Ideas for InMoov2 Gui


Gael supplied some great graphics for the new UI.  I have been working to get the variouis "sub-panels" working for each of the buttons.  I'm waiting or Gael to send some html so I can have the buttons high-lighted when activated. In the interim I'm using the bottom buttons to mock the click events.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
hairygael's picture

Hello Grog, Having a

Hello Grog,

Having a graphical GUI for introduction to MyRobotLab would be really great.

Last night I designed a UI for the InMoov front webgui, making simple and clear icons.

Each icon could direct to a sub class with more UI accessories.

It would be great if the webgui can integrate the buttons where I designed the icons.




GroG's picture

Perfect ! ...  it would be

Perfect ! ...  it would be great if we're a team on this. 
I can start a mock-up with the one you supplied here, I think perhaps it might be useful to additionally have the buttons saved seperately, as a quick indicator in the sub-menu.  Can you send them as pngs too ?

WOOHOO - excited :)

GroG's picture

Do you have PRESSED vs NOT

Do you have PRESSED vs NOT PRESSED versions ?

GroG's picture

I think it looks great ! ...

I think it looks great ! ... it takes some real estate, so square dimensions might work better.
You select a button and the highlighted section changes on the right depending on context.
I need to know what the different parts you were thinking of ..
top brain then,
settings / configuration ?
legs - uh is there code for this ? :)
Pir ?

GroG's picture

There are several different

There are several different ways to make images activate like buttons in javascript/css/html.

  • image maps - old tech where problems can occur with invisible regions :(
  • css absolute/relative background-image positions - difficult to maintain, buttons and images can become mis-aligned
  • slicing the elements into pieces and putting them back together in a table

I would prefer the 3rd choice, its simple, clear to see what is going on, less prone to alignment issues, and is lower maintenance and more portable.

This means you need to slice up image into a grid similar to this.  One set of non-active buttons and one set of activated buttons.  The cut lines must be horizontal or vertical, and you don't want the buttons to overlap the lines.

Gareth's picture

Hit Boxes

Quite a while back I used a system that displayed a whole single graphic  in a window (e.g. 1000,1000)

Each Icon x,y position was located in a lookup table (eg. icon 1 @ 100,80   , icon 2 @ 500,323)

On mouse press over the window (aka button screen graphic)...its x,y coord is noted and then walked through the table using a kind of bounding box approach.....

i.e.    if mouse was 90,88       ... lookup would check it to see if it was between 90 +10 and 90 -10  & 88 +10 and 88 -10 etc... (bounding box of +/- 10 around the cursor position.)

In my case I was lazy and replaced the whole graphic with its button pressed equivalent (yes the whole screen , not exactly efficient however it worked).

GroG's picture

html map The lookup table

html map

The lookup table your describing sounds similar to html image maps  

Its become legacy, I believe because of the challenges and lack of embedded tools to manage or maintain the tables and coordinates.

css absolute background-image magic

This is a more modern technique(s), but still can be a challenge because of individual pieces, classes, or ids being mapped with a coordinate system.

slice dat image !!!

Slicing images into components makes programming substantially easier.  There is no hidden layer, no coordinates (absolute, or relative) to manage.  The sliced piece of image "is" the button.  No guessing, tweaking, or frustrating aligning...  goodtimes !


hairygael's picture

Hello Grog, That sounds

Hello Grog,

That sounds really cool!

I will prepare the buttons seperately with a highlighted and non highlighted.

Hopefully I can prepare them tonight, tomorrow I am living for a sort of Makerfaire in Bretagne.

Sébastien certainly could help us a lot on this because he already had been working an a html version a while back as you know.

I think what we need in sub UI are all the configs we currently set in the config files of InMoov.

Each of these files contains the current necessary configurations.

I will design some sub UI looking like this for the servo mappings and servo configuration of each skeleton part:


GroG's picture

I'm using some buttons at the

I'm using some buttons at the bottom, in order for me to work on programming, but when the highlights come and when the image is segmented, I'll remove the bottom white buttons.

If this is the "Settings" icon I envision a list of "sets" of configuration.  Each one of these will be a folder in the
data/InMoov2/config directory.

InMoov2 will come with a "default" set of configuration, but at any time a user can save a new set with a different name.

The configuration files will be python.  They will be clean, small, and documented with comments.

The files will be ordered in (mostly) how they were started .. this depends on how we choose to group them.
The above could be an example.

Configuration is and will be one of the more difficult things to manage.  So, we would benefit in having some structure.  Potentially, the structure can provide the user to save many configuration "sets" at any time through their experimentation, and the user would be able to re-load this config and expect the same state that they left off.

MRL needs some general rules on how to export config and how to load it.  This starts by defining some general rules.  For example :

  • When asked to export, MRL will make a new directory of config with the name provided by the user.
  • It will export service types in order they were created
  • Perhaps they should export in order by grouped by type, but use parent/peer relationships.
    I'll need to think/experiment a little more to show what that might mean



hairygael's picture

The icon with the gears and +

The icon with the gears and + is for all the extra things that need to be configured, like the Neopixel, the kinect, and stuff to come in the future.


I think we need to configure each part in a seperate Ui which relates to a specified config file.

For example we could configure each servo for the arms and set them as activated via a UI like this:

Ray.Edgley's picture

More on configuration

It would be handy if how the servos are connected could be more easily configured as well.
They my be connected to PCA9685 instead of an Arduino Mega 2560, and in some setups there may not even be an Arduino installed at all....
Running a Raspberry Pi with the I2C bus to 1 or more of the PCA9685.

Just a thought having not long ago seen someone else looking at a similar setup in the forums...


GroG's picture

Hi Ray, Great to see your

Hi Ray,
Great to see your input. 
Absolutely.   I know this is of interest to many people ... including myself.   Its more complex than the general "switching on/off" services and will take more work to do it satisfactorily.

On a very high level I suspect it will be a series of dialogs that defines a process to create your servo controllers.  This would probably start showing a list of possible servo controllers available (running or waiting to be created).   The user would select the desired one and continue the dialogs to associate and configure the servo controller they desired.

In the end - there should be a "save" button which saves all this to one of the settings/configurations, so the process would not need to be done again.  Instead it could be quickly loaded the next time on startup. 

Ray.Edgley's picture

Hello Grog, I Keep lurking

Hello Grog,

I Keep lurking around, more than you know :-)
MRL is one of my startup pages in Chrome :-)

Ithink I had mentioned the controller support in Inmoov2once before,butas they say, the squeeky hing get the  oil :-)


GroG's picture

The picture slicing worked

The picture slicing worked great ! ... I think this will be very good way to go.
I suspect the output of this process also generated an html file.  If you happen to find it, could you send it too?
Otherwise its a jigsaw puzzle for me.

astro's picture

Awesome! It's looking very

It's looking very good. I don't know if it's too much to ask, but maybe thinking ahead can be easier later.
Could it be done so that you can change the skin like winamp?
is that possible?

Thinking that you can modify the buttons, colors, background and styles, changing the PNG of a folder and you could choose different skin that suits the style of your robot, dark, light, scary, minimalist, etc.
Then using the same filename of the buttons, you would only need to modify the PNG in another folder


It's just an idea.

GroG's picture

Changing the css/color would

Changing the css/color would be pretty easy, changing any graphics/pngs would be out of scope for us, but that doesn't mean anyone could substitute their own pictures.

The location of the pictures would be in the mrl directory/resource/InMoov2/*.png

astro's picture


Sorry if my English was not well understood. I did not pretend for you to change any graphics/pngs, I only thought of an option so that you can select the folder where the PNGs are located. But for me it is enough with what you explained.
If you or Gael need help with the graphics, let me know. I would love to help you guys.


GroG's picture

Cracked !

Cracked !

astro's picture

Hello friends. Maybe this

Hello friends.
Maybe this can be helpful.




hairygael's picture

Nice, this seems to work

Nice, this seems to work better than the slicing I have done for Greg.

Did you use a special app to do it?

astro's picture

Hi Gael I only used

Hi Gael
I only used photoshop to crop the buttons of a capture of your design and make the individual effects of the 3 states.

Then I found the code to distribute in a circular way:

No special soft, just html, javascript and css for the style.

You can change the number of buttons in the field above and they are rearranged. I have to do some cleaning in the code, I did it quickly to see if it was useful for you.

GroG's picture

Cool Astro ! Do you mind if I

Cool Astro !

Do you mind if I take your pieces ?
Interesting idea on the dialog/shadow box.
It does save screen real estate, but it took me a little bit to figure out, so I think we will switch dialogs to the right of the menu selector.

Thanks for jumping into this ;)

astro's picture

Hello Grog. In reality, is

Hello Grog.

In reality, is not saving anything, it's only one page, the code never makes a submit, I left the code to you, use whatever you want. I have a finished version but I don't have access to my work's server again until Wednesday (Carnival holiday here). I have a rar file but I don't see an option to attach a file here.


astro's picture

This is my dynamic ip. So

This is my dynamic ip. So these links will work for now.

Here you can see the latest version with style improvements,

All the fields would have to be processed in a FORM with just one SUBMIT
But if you have already solved it in another way,  and you would like to use it only as an interface of buttons if I understood correctly, here you have a simple version with only the buttons and you can add the action on line 140




GroG's picture

Thanks Astro, The pictures

Thanks Astro,
The pictures are great - thanks for making them in 3 states.

I'm making progress making it all work in the webgui.

I was curious if you have used the new webgui on the develop branch ?

My plan is after I get the main menu working satisfactorily, I'll go back and see how you designed your sub-menus.   You're web design skillz are very honorable.


Just a little background if your interested.  The webgui is coded currently in AngularJS (at some point we'll switch to React but not before the Nixie release).  

The webgui sends messages over websockets to update data, form posts are not used.

I have limited time but would welcome any input you might afford us.


astro's picture

I never used webgui. I'm

I never used webgui. I'm still with the Manticore version.
I don't know how to use the develop version, I didn't have time to investigate how it is compiled and all that. I am waiting for the Nixie version to see if the framegrabber part works, because I am using the camera on the nose of the Terminator that is on a raspberry streaming with UV4L. So for now he is sleeping.

I'm just being guided by the images you post here about how webgui looks.
I will try to follow some tutorial to see how to open the develop version.

About the menu, I cleaned the code a bit and updated the first version if you are interested in seeing how the design structure is, you can see it in my first post. And download the updated .rar again. It's basic HTML and CSS.

I'm going to do some research on Angular and websockets, maybe I can help with something.

I can't see this picture:

GroG's picture

Don't worry about the

Don't worry about the picture, not a big deal.

The latest "checked in" develop myrobotlab.jar should be downloadable here.

But the latest I still need to push the changes i'm working on locally.
My next steps are  :

  • figure out servo-palsy and fix it
  • make configuration savable in a nice neat python script(s)
  • make servo controllers configurable
  • work on the sub-menu panels (something that it looks like you've designed a little)

I'm certainly interested in any input you might have.

GroG's picture

  The working buttons are


The working buttons are spiraling into position.
Need to do another local transform rotate and center their rotation around a single point :)

GroG's picture

closer ...   I'll finish it

closer ...   I'll finish it up tomorrow ... getting late here now ..

After that I have servo palsy to take care of ... and after that I'll start looking into config.

hairygael's picture

Hello Grog, Astro,I just

Hello Grog, Astro,

I just installed the latest from the developp but unfortunately all img are missing in the resource/InMoov2/

I tried to access the InMoov2 developp branch on Github, but it seems the directory is locked.

Well, at least I can't access it, I am sure you have access.

I wanted to see how the files were configured in order to make them clean under Photoshop, because I suspect, they must be a bit damaged after being cut off from my original image.

By the way I have pulled some requests on Github for the InMoov2, can you accept them and push them in the next developp release?

Here is a tree to explain how I envision the sub menus for the InMoov2 webgui.

For the hands, Arms, Head,Torso, Legs I will create new img which will guide to the sub ui functions:

Any suggestions is helpful...

GroG's picture

Looks pretty awesome

Looks pretty awesome Gael.

Pretty cool for mouth, as an example, I already have what you have working ...
I'll have to check on the others ..

Your "extras" I assumed were "settings" ... but we need something to manage CONFIG
This will be pretty important - I want something for which I can tweak all these things and configuration is saved.  I shutdown everything ... start up the InMoov2 service and load a config and all the config will be loaded, and it will be worky as I expect it.  You have Extra -> NeoPixel, if you want that to stay we need another config button on the front.

I don't uderstand the arm sub-gui  - are they all sliders?  how do you want to set min/max ?

thanks for posting ...