I think the problem could be in MRLCOMM


When connecting the power it energizes some servos, wrist remains energized all the time even without connecting the arduino to the pc.

You can also see that the other hand is moving, the head and the pinky on the left is closed to the maximum. I don't dare to connect the biceps or the shoulders that have wiper motors because it would break everything.

I loaded version 58 and it does the same. I always saw it shake all the servos, the head also when turning on, but before I did not notice any of them stay on. The right hand had not been used for a long time because it had broken fingers, I just finished fixing it, so I would not know if the problem was from before. I think this could be the cause of it being burned, the wrist servo continued to be energized from the start, forcing against its own physical limit, with all the time it takes for webgui to start and configure, I did not have time to calibrate it.
You can try connecting servos but not connecting USB to see if you have the same problem.

I am thinking that maybe for this reason, a couple of years ago I had problems and he started shaking his arms and breaking his fingers violently and after starting he calmed down.

Thanks Grog,
It's cool to see that new rebuild.

I was just trying to find the root of the problem to see if I could help something, because maybe we were looking for the problem somewhere else.
I understand what you are saying, but with the virtual servo, I could not realize this error when giving it power. Since in the last tests it was not connected to MRL. It's just the sketch on the arduino that powers the servos on startup.

I think I now understand better the purpose of the NervoBoard, to give power after everything is loaded and avoid this behavior.

I will be watching for the new rebuild.

This looks like you started mrl..  a servo was attached/enabled.   you kill the java application..  however, the arduino continues running the mrlcomm code and the servo remains attached.

This is a very known issue...  opening and closing the serial port will trigger MRLComm to reset and will properly disable all servos.


the problem is that if you run a sketch on the arduino and then you pull the usb cable out of it..  if the arduino has power, it will continue running the code that is running on there.

MrlComm was told to add a servo and keep it at a position, so when you pull out the usb cable  (or disconnect the serial port) MrlComm has no idea it was disconnected and tries to maintain that position for the servo.  

Pressing the reset button on the arduino should fix this and force MrlComm to reset.  Another way to do this is to open the serial port back up.  That cuases the arduino to reset.  

This would be a nice to fix item..  when I'm working with Mrl on Harry,  i have a small script that I run if i shutdown mrl that opens and closes the serial ports one time to reset MrlComm.

in the future..  (maybe near future?)  we need to make sure MrlComm has a reasonable heartbeat detection... if MrlComm looses contact with the Arduino.java, it should perform a softReset... this is probably the cleanest solution here.   This has been a long standing issue .. now that the code is much easier to maintain and debug.. we can probably look at fixing it much easier now.

Hi captains!

Test pilot here!

Well, analyzing what happened to me, it is surely a combination of what Kwatters say, the enable stay on and others things.

Disconnecting the arduinos and giving only power to the servos they shake for a second. I found this to be a known problem. They call it servo jitter or servo twich.

It is the final test seen in my video. It's just powering the servo, there is no arduino involved in this, I tried taking the arduino board fully out of the system and kept doing it.

I found some solutions in the arduino forum

"wiring a 4k7 resistor between the servo signal and ground wires."

it didn't work for me

" 10K resistor between the servo data pin and 5V."

it didn't work for me

But I think I can get on with it with no problems, it's just starting for a second that it does on all servos. I will see later connecting the big motors with a relay after a delay to avoid that.



Arduino has tri-state pins:

They can be +5v, gnd, or high impedence (similar to unconnected / floating )

Servos have a singnal wire, if it's "floating" as you have in your diagram - anything can happen, and there are differences in servo manufacturer that can affect this, also differences if damage occures, like internally a resistor to ground that fried (if it had one), the servo will then float.

I'm surprised this did not make the servo calm :
"wiring a 4k7 resistor between the servo signal and ground wires."

grounds also can be noisy too, which can produce jitter, but yours looks very determined to go one way.
I'm guessing another servo using the same power rails does not move ?  Do you have a way you can check how noisy your ground is?

Big switch that cuts all power is always the safest - I got one of these on WorkE 

The Eject Button

Hi guys

I tested 200

I too notice th same in 200. Some parkinson related to Auto-disable. Even when servo it's not attached, if we turn on Auto-disabled, a blink is seen in the Enable and Energized.
if the servo is attached it makes small intermittent movements. It is also seen in the log window "publishServoEvent" with every move.

If we press enable, it doesn't keep it on either.

Whenever I start it appears in the local language "Spanish" which sounds horrible and almost nothing is understood. I always change it to English, but apparently it doesn't save those settings.

GUI glitch

There are some interface issues like the Sweep shown ON when it is not actually ON for the first time.

All dropdowns have problems, they take a long time to load their content or they never do and you have to press F5 and wait a long time until they appear.

I can fix InMoov button bugs using css instead of angular.


Energize pulse - Fixed in 203 http://build.myrobotlab.org:8080/job/myrobotlab/job/develop/203/artifact/target/

If we press enable, it doesn't keep it on either. <-  this is by concesus ... I thought if a person said "enable" it would be a god command and it would be enabled, but i was out voted by kwatters & Gael - who said, if autoDisable is on - it will become inactive.

Whenever I start it appears in the local language "Spanish" which sounds horrible and almost nothing is understood. I always change it to English, but apparently it doesn't save those settings.

Nothing is currently saved, although exporting of scripts is "sort of" worky.  I know there is some additional work that needs to be done to localize properly.

I'll watch your nice video :)

Hello Astro,

Regarding saving Language, I have fixed some of the issues related to the save buttons in the InMoov2 gui, but many parts still needs improvments to be done on the java side, which I obviously cannot achieve.

In java for InMoov there is only two options for to save: exportAll() and export() none are fully doing what is necessary to reach the level of what we had in the ini files.

Currently on the main InMoov UI if you press "exportAll" it will save only the main started services to data/InMoov/config/myConfig.py. Ah one of the bad thing of that button is that it just over writes everything again, so users will loose all their config if they didn't make safety file.

If you use the "save Config" (which uses export()) in a body part or in mouth, ear, chatbot, it will save the started service but nothing else unfortunately. I am working on that in way that it could save files similar than what we have in the ini files. The ini files i am talking about, are not located in data, but in dev/InMoov2/config. During a normal fresh install they will be located in resource/InMoov2/config.

I have made the button "load system" which is loading these config ini files, but currently the InMoov scripts related to those files (that use to work in Manticore) are still in conflict with Nixie.

This is the reason I started working on individual python scripts to replace the exportAll() and export().

These scripts should save in a way that the files produced in data/InMoov/config/ will be very similar to the ini files. This way users of Manticore will be able to just translate their config to the new config files, without the need to go through the InMoov2 webgui for to redo all the configurations.

Hello Gael and GroG!!

"if autoDisable is on - it will become inactive"
Oh yes, it makes sense.

I'm guessing another servo using the same power rails does not move ?
You are the master of debuggers. You nailed it again.

I thought 2 servos, wrist and thumb had burned. But only wrist raised temperature and I didn't even check the thumb. Now checking, I tried to connect a microservo there and it doesn't work either, looking for the problem I could find a cut signal cable on the shoulder. D'oh!

So another good news is that the thumb servo was not burned :)

Do you have a way you can check how noisy your ground is?
No. I only have a multimeter.

@Gael Thanks for all the explanation about "Save config" and Export.

I don't know if you guys have the same problem with the InMoov interface or is it just my PC that with the DevTools errors is very slow and I see these glitches.

I think the problem I'm having is that angular with mouseover, mouseout and translate transform is slower than using css, so I made a few changes and it seems to work fine for me.

@Gael, can you try these files on InMoov2?

I'm going to see the bottom "Notifications" to make it hide and show when needed.


Hello Astro,

Thanks, I just tested your files with succes.

For me it is difficult to say if it's better because I wouldn't get the artifact you are mentionning, but I believe what your showing/explaining must happen to others as well.

Therefore, I will push your modifications to the master branch.

I have not been using DevTools since almost Grog explained how to use it because of the errors pilling up.

The number of errors is so high (up to 75000 errors sometimes), therefore DevTools is pratically not usable. I read in one of your post that you have the same issue. This is the reason I use Visual Code and work my way with that...

It's interesting to note that in Firefox if you examin the element, it doesn't throw errors.