InMoov Hand Ready For Testers - build 1804



speakErrors (Speech Service) // damn good

autoDetach after 5 minutes inactivity

isValid systemCheck - various levels + contextual string

check scripts - subsume all previous capabilities - minimal script

videos need to be done (all interfaces - webgui, gui, xmpp)

WebGUI - TODO - framework for button cmdText -> quick propegate



InMoov service has become service(s)...
The InMoov service primary resposibility is to correctly start and name all the sub/peer services necessary to interact with InMoov.

Just like airplane flight .. the most complicated part is "taking off from the runway" .. this is the same for InMoov :)


There is now a whole system of "reservations" where composite service "reserve" the names of the services they depend on.  With this reservation system it is trivial to make "more" composite systems of the same type.  Previously names would clash and problems would occur.  Now no matter how complicated a service is - all its sub-parts are uniquely named.  Name collisions can be created if the intent is to share services with different composites.

Arduinos are named by their COM port - not by their body location - this is appropriate since the Arduino control can span into different parts of the body

WebGU can be used with InMoov

XMPP can be used with InMoov

detach works

re-attach works

multiple InMoov(s) can be controlled from a single computer

more code is re-entrant, meaning you can rerun many of the same scripts multiple times without adversly affecting the state of the system.


Here is the basic script to start the right hand
First the services need to be installed -
Click on the runtime tab and right click on InMoov then select Install
This only needs to be done once...  All InMoov's dependencies will be downloaded and installed.

Next we can start an InMoov service.

i01 = Runtime.createAndStart("i01", "InMoov")
rightHand = i01.startRightHand("COM12")
with these 2 basic lines an InMoov service is created named i01 (because you can create many InMoov services now :)

With that service, a new right hand is created, the gui should come up with all the servos and the Arduino service connected if the port is correct.

All Servos should be attached and ready for positioning with the gui

The new hand service ! - and below it all the sub service it works with
In the running services you can see the automatic naming hierarchy.  As I mentioned these start as reservations, and can be changed before sub-services are started. Once you start a service you can not change its name.. although you could release it and re-create it.

These are the default names, I leave it to Gael if he wants abrieviated defaults or different names.
You can now test detaching the servos
now the servos should not move, in the detach state the servos are not trying to maintain the position, you can test this by gently manually turning the servo/finger and the servo shold comply.
It is now a single line to re-attach the servos

Now the servos will move and hold position

Creating a webgui gives you another interface to your InMoov

Runtime.createAndStart("webgui", "WebGUI")

Should bring up the webgui page

The REST API will allow complete although not neceassarily efficient control of InMoov (from a remote system too)

The REST API link dynamically creates the same view as "running services" in the other gui.
But unlike the old gui - you can click on any service and get a list of all its capabilities.  There is a context sensitive help, and any method can be invoked with parameters to generate a URL which can be used from any computer on the network.

for example

creates the URL

which will move the wrist to 90 position... the "button" and form are not important - they just form the appropriate URL

So changing just the paramter at the end will cause an effect e.g.

Keyboard controll would probably have some advantages, but I would need to know a default mapping of keys to servos or some methodology as to the the control



To show you what I'm working on .. this represents a composite service structure, such as the InMoovHead.
Previously, it was not structured .. but now IT IS !!!

The InMoovHead contains references to other composite service structures.  So in the above diagram InMoovHead would be #8  .. it contains or controls references to 2 composite service structures MouthControl #10 and EyeTracking #3.  EyeTracking contain/controls references to a group of other services (2 Servos 2 PIDs, Arduino etc).

Wait, there can be more complexity !  - The Arduino of MouthControl "might or might not" be shared with the Arduino of HeadTracking depending on who's InMoov :P    and although there is multiple tracking systems there is only ONE CAMERA !!  How can they both use the same camera ?  They must share !

Wait there are more requirements ! - each service name MUST BE UNIQUE !!!  This is the rule .. it must be obeyed !  So how to auto-magically build the names ?  You follow the path !  If you named your very complex InMoovHead service "head01" then all the other default names are created for you - e.g. head01EyeTracking & head01MouthControl - as their sub-services might be called head01MouthControJaw or head01EyeTrackingOpenCV .. but you can override the default naming and force composite services to share things..

For example.. by default in the InMoov head I will be making the HeadTracking and EyeTracking service share the same camera by telling both they need to use a service called "OpenCV".. 

changes to the tree structure can easily be done with a couple lines of script, so everyone can play with the same pieces (services) but build very different structures..

Below is an update of the InMoov head which is "better" - the 2 OpenCVs from the 2 seperate tracking systems (HeadTracking & EyeTracking) have been merged - I left the 3 Arduinos seperate until I get more info from Gael.  The correct number of servos exist now for the head, additionally the 4 PID services shoul remain, since each could be tweaked for specific behaviors or servo differences (e.g. fast eye tracking, slower head tracking)

The structure can grow in depth .. representing the depth of complexity of InMoov.. additionally it can grow upwards .. representing larger composits, such as Arms, Hands, and Multiple- InMoovs (swarms!)


Heh, this is a new InMoovHead service .. :) ... needs work .. a little too many services :P
But there ARE supposed to be 2 tracking systems (head & eyes) with 2 PIDs each .. that look ok ...
back to the bit forge :)

Comment viewing options

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

Yey, lots of tabs! I remember

Yey, lots of tabs! I remember mentionning time ago, that InMoov would require a personal tabing feature. Like groups of sliders in one tab.

Left arm tab would have bicep, rotate, shoulder, homoplate sliders.

Right hand tab contains wrist, thumb, index, majeure, ringfinger, pinky

This way when detaching them from the gui, it wouldn't be a mess to work with them.

Some more work....


hairygael's picture

This new tree structure is

This new tree structure is very interesting, I like the idea that it will be easier to add or remove parts for who ever's robot. I see the benefits of it but as you know,  I'm not at all familiar to this way of thinking and I'm deeping myself more and more everyday in an unkown world. Robotic programming.

hairygael's picture

We had a very good worky

We had a very good worky session with this all brand new structure.

"Detach and attach" will be very handy to unpower the servos during resting position, avoiding getting the servos to warm up for nothing.

The webgui works, the only issue I found is the "move to xxxx" didn't seem to work.

We nned to find out why.

Grog tried to get in control of my robot through the atlantic ocean, unfortunatly we had to stop before we could reach our goal, personal life sometimes calls us back.