TODO - 

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

http://127.0.0.1:7777/services/r01.pinky/moveTo/80

References

• http://myrobotlab.org/service/InMoov#DefaultHardwareMap

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 :)

Changes

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.

Starting

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")

The new hand service ! - and below it all the sub service it works with

rightHand.detachServos()
rightHand.moveTo(10,10,10,10,10,10)

rightHand.attachServos()
rightHand.moveTo(10,10,10,10,10,10)

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

http://127.0.0.1:7777/services/i01RightHandWrist/moveTo/90

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.

http://127.0.0.1:7777/services/i01RightHandWrist/moveTo/130

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 :)