After several coding jams the Log service is starting to have sparkles.  I wanted to make it "better" than eclipse's console to quickly see status and diagnose issues.  Having a good logging system is the cornerstone of workyness :)

 

I want to make the webgui Log service more capable and easier to use than eclipses ...
It's a work in progress at the moment, but some nice features will include, directional sorting, logging selection, client filtering, class filtering, thread filtering, and any more bells and whistles I can think of.
Good Logging is the cornerstone of Worky ... heh at the moment though I have not solved the log level = debug go supernova problem ... but I'm pretty confident I'll figure it out 

2019.10.28 - Arduino webgui oscope "mostly" worky again ...  besides being completely borked with the (pin is a string) change - it never has done screen blitting rolling of traces.  Which I'll try to do.

Now anywhere error(), warn() or info() are used - status appears, is counted and can be dismissed.

There have been many bug fixes to the webgui ui.  Examples and new files are now "downloadable" to your local file system.

Polly now has a simple working ui - with "set keys" which sends the keys to the security service

 


 

2019.10.19 - Easier to understand security


2019.10.13  New Command and Status boxes - you can use the MRL Cli to quickly send commands and see results even without the Python service.

call any function /{name}/{method}/{p0}/{p1}...  
some additional "helper" methods pwd ls cd

tooltips now on some of the input fields


2019.10.05  New "Virtualize" button in service menu

A new virtualize button exists in the service menu.  For me its very handy to be able to switch certain services into "virtual" mode.   When you click on Runtime it sets all services and all new services created thereafter to virtual mode.  Other services can be set individually.  Runtime is like a big switch.

I broke and manage to repair the list methods and show json functions.  Both of which can be very helpful looking at the current state or viewing the capabilities of a service.

Likely, I'll be moving on to Arduino next ... I noticed it was pretty bork'd up ...


Hello,
I wanted to show what direction I'm heading in with my latest updates.  There is considerable amount of changes under the hood that affect the framework of MRL.  
In Summary :

  • Any MRL can potentially be connected to another instance of mrl without additional services
  • Multiple MRLs can all be connected together in a large complex network, and messages from one will get routed to correctly to the other (ie routing is working)
  • TimeEncoders are a real thing - they work like physical encoders, but use time estimations to guess where positions are.

There are some UI updates too.  The webgui now behaves similarly to the swing gui, in that there are no more "little frustrating boxes".  Instead its much more similar to the SwingGui.  You can quickly search for your service, and when the tab is selected - the service specific UI appears (like the SwingGui)

The InMoov composite services will have easy to use sliders for positioning, and they can toggle between control mode and read mode - allowing quick positioning and checking of angles

I'm busy trying to get all the parts in to make a pleasurable switch from the SwingGui to the WebGui.  The major integration test will be how well I can create gestures and run simulations on virtual inmoov.  During this time it would be helpful to try to understand how configuration is currently done and what would be the optimal configuration routine(s)

I think some of the current ini files were generated by a web app @ inmoov.fr -  I'd like the same concept, but the local instance should be capable of running through a calabration routine and generating the resultant configuration in the form of a configuration.py script.

 - Cheers

hairygael

4 years 5 months ago

Nice looking UI !

It is SOOO nice to see a graphical step forward with the webui. I have never been able to use the webui because it was full with little bugs which would frustrate me. Another reason for not using the webui, was that it would take too much space on the screen to work properly, not giving enough room for other apps.

Thinking design, I think it should be good to be able to have access mainly with mouse control because a keyboard on a robot is not always connected to the PC. We mostly have a screen and a big finger to toggle. Maybe some shades under the various blocks for easier viewing on a small screen? I can create icons or buttons if you want, it would be a pleasure.

The current ini files were never generated by a web app @ inmoov.fr, it was a step we thought of doing with Sebastien to have a good graphical environment for users, but we never got to finish it because it seemed to be too far from MyRobotLab software. I think Sebastien had sent you what it looked like, here is the link to the first layers https://www.inmoov.fr/gui

So because it was never finished, currently the users edit the ini file in a text editor to change their configs. Not very user friendly for the look, but really less scary for users than a big overwhelming script. Also much easier for me to give direction and help them through various steps.

So, idealy would be a graphical viewing for the various config files, it doesn't matter to me if they are .ini or .py as long as the editing (if necessary in a editor) is not a long a scary script. What Moz4r had done was a good step forward. Here is some of the current ini. files https://github.com/MyRobotLab/inmoov/tree/develop/InMoov/config