MRL Next Release - Manticore !

Manticore is becoming organized here 

Manticore Release

Thanks Shaun for pointing the github project out ..

(Image from talented artist  kikicianjur-d384nro @ deviant Art ! )


So we all are on the same page, we are headed for release.  This is the "short list" of worky one-click requirements.

  • voice control
  • vision tracking
  • kinect working
  • pir working
  • servo positions and speed working with all servos even during tracking
  • virtual InMoov (thanks Calamity !)
  • packaged self-contained InMoov scripts inside of myrobotlab.jar (thanks Moz4r!)
  • beginings of solid integration junit tests for each build to preseserve Workyness (thanks Kwatters!)

The next release will be tagged Manticore !

Comment viewing options

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

Brrrr, exciting!!! To enhance

Brrrr, exciting!!!

To enhance version 1.0.107 which had the above short list (posted by Grog) working, I hope to get the joy of using:

-voice control with programAB (presently working with various Speech options)

-webkitrecognition (presently working with Chrome)

-face recognition (presently working, slows down the fps a lot, a bug with populating filters in OpenCV)

-neopixelring (presently working with USB, not with RX/TX as far as I tried, and I really tried)

-sensors for fingers?

-kinematic?(I tried with joystick from Kwatters script but result was not efficient, old joystick maybe?)

calamity's picture

the TX/TX was working last

the TX/TX was working last time I try it. But it's been a while. I have currently use the neopixel for another project and have not use it for a while. I will replug it soon to test it

about kinematics, kwatters did an awesome job with the service InverseKinematics3D. I use most his code for IntegratedMovement service. When I tried it, I got some difficulty too. I think it's mostly because it have some hardcode setting to convert the IK angle to servo position and that in some position, it can generate null pointer exception. 

I have work a lot on integratedMovement service recently and I begin to be quite happy with the result. I will do a demonstration with the InMoov soon, but I need to fix a problem with one of the arm first



kwatters's picture

nice short list.

so. couple of comments.

1. we need a set of example scripts at a minimum that create an arduino, attach a servo, and move it.  This script needs to run as a unit test that will break the build if the script doesn't run (on virtual arduino).

2. we need an example script that starts up a minimal inmoov (minus the webgui and swing gui) in a unit test using the virtual arduino.  This unit test must fail if the syntax of the python script is invalid.  We should also try to exercise some of the inmoov code itself in this unit teest.

3. I'm not sure about being able to test the neopixel and I think the IK and integrated movement services need more work, so we shouldn't officially support those in this release.  Perhaps next release? 

4. webkit, program ab, inmoov all should be no problem.  Even face recognition, I'm pretty confident that we can get that all offically supported in this release.

...  Now, the question is , where do those scripts come from,  we have the InMoov repo that contians a lot of stuff.  (probably more stuff than we need to / care to test with each build.)  

So,  I recommend we get a couple minimal python scripts together, add them as some of the unit tests, make sure they run with every build and validate their syntax.  Once that test infrastrure is in place, (and the scripts are worky)  then I think it'd be ok to release.

I've been working on trying to update the unit tests a bit.  the ArduinoTest (and the Arduino2Test)  are good examples of how to use the virutal arduino in a unit test.

Finally, as part of the release we need to / should publish both the javadocs and the jacoco code testing coverage reports.  The javadocs will help document and they will be in sync with the actual code if they're bundled with the release.  The jacoco code coverage reports will let people know what is tested with each release by the auto testing elves.  


Then...  Unleash the Manticore!


calamity's picture

I beleive the Neopixel

I beleive the Neopixel Service is working fine and can be officially supported. What seem to be broken now is the ability to daisy chain Arduino. That is not a necessity for the Neopixel service, it just saved a USB port. I will look and test at what is not working. 

For the IntegratedMovement service, It is not ready for release. While it's in a working state, it need more polishing and documentation.



kwatters's picture

Virtual arduino testing with the neopixel

If we can unit test the neopixel by using my the virtual arduino .. then ok. We can support it. That means a unit test to make sure the service is worky (at least with the virtual arduino service.)

GroG's picture

WOOT ! Bring the Beast !

I'll be working on OpenCV, which includes unit test as soon as the interfaces are defined (working on that too) - then I'll switch to Tracking's interfaces and tests ..

- oh and a variety of backend infrastructure updates in the copious spare time which remains ;)

hairygael's picture

I canl test the minimal

I canl test the minimal script for head, arm, hand, torso with latest release.


Need to add the velocity and maybe other things to make it worky. Switch detach to disable...

GroG's picture

So I have to ask :)On the

On the short list is :

  • packaged self-contained InMoov scripts inside of myrobotlab.jar (thanks Moz4r!)

It would be a really big improvement to auto-package worky InMoov scripts with every build and every release...

What scripts are we going to package ?

Are they going to be the ones in InMoov repo or ones in your home directory ?  

Also just to be clear - the scripts selected will forever be auto-tested every build, but future changes need to go on the "develop" branch and we can have a process of release which auto-moves the latest to the "master" branch.

Make sense ?  I want to make very sure we all know where the scripts which will be auto-packaged and guaranteed worky come from.


Ash's picture

Hi All, Short but very

Hi All,

Short but very exciting list ;-p

Thanks a lot for your work !

moz4r's picture

Impressive beast ! Services

Impressive beast !

Services script will be a good thing to test I think. It is great raw reference. 

harland's picture

be happy to help

Azul would be happy to help with testing on a physical Inmoov.  I have the time and a complete shop for rebuilding Azul if needed (ready to give its plastic body to advance MRL).  I am much better at building, not software.  I agree with Gael that we need code to support finger sensors to make the hands more useful.  Since some Inmoov’s  have wheels,  maybe some thought toward commands for “driving” them around.

GroG's picture

Thanks Harland, Its great to

Thanks Harland,
Its great to have yours and Azul's expertise !!!

This is an inital post to get all the elves to head in the right direction ... there is much work to do, but I and the rest of the elves would greatly appreciate any robot-test-time when we are in "pre"-release mode ...

It's still a bit early.. stay tuned !

And yes I totally agree on the platform service !

juerg's picture

looking through some of the

looking through some of the files I see e.g. has e.g.

ear.addCommand(u"disconnect head", "i01.head", "detach")

has this to be changed to "disable" instead of "detach"?

If I want to add german "ge" can I start to work on that based on the englisch version?

And can you add into your list that I have a chance to get my german MarySpeech working


The voice gets loaded but to it looks like NaturalReaderSpeech kicks in and ignores my german voice.


juerg's picture

another small issue (2132):

another small issue (2132): after "install all" the restart does not terminate mrl (win10/64).

also trying to close the window does not terminate

I have to use Task Manager to kill the java process

juerg's picture

I understand that we have now

I understand that we have now an inmoov folder within the mrl-version which has a lot of definitions, some also related to the users individual environment e.g.


which lets me start a vinmoov, can set the language and specifies the COM-Ports for the Arduinos.

So each time I download a new mrl version I will need to merge my own version of that file with the newly downloaded version?

I am on windows so case in folder/files does not matter but I see all these 3 cases used to refer to InMoov:

inmoov... (all lower case)

won't this cause trouble in linux systems?