Dynamixel error : could not parse data

Support
1

We have several problem with dynamixel motors these days:

Some motors say ‘could not parse received data’ when being scanned (MX 28 and MX 64, correctly pluggued, parametrized and powered). I tried several times and always get this answer.

Do you know what could cause such a behavior ? Looks like the motor is not completely dead, but we can do nothing out of it. We have seen several motors (i.e. a whole leg) go to that state at the same time.

Do you have any idea how to revive a motor in ‘could not parse’ state ?

Du you know what can cause this state ? It’s often on the legs motors and I’ve been told the Dynamixel hub can have short circuits, do you know how to test it ?

Could you try to add protections (such as monitoring the load and cutting the motor if static overload is detected ? ) in Pypot ?

2

One time I had this error due to a bad power supply but in this case it was for all the motors. I think that “could not parse data” means something is wrong with the TTL communication between the motors. I have this error with the Pixl board and high speed communication.
Maybe you can try to decrease the baudrate of the communication to check if you always have the same error.

3

This error exactly means that the CRC of the message does not correspond. It indicates that some value inside the message as not been correctly transmitted. In our experience it is often due to:

  • broken wire
  • broken motor
  • bad power supply

Unfortunately a broken wire/motor can corrupt the whole bus and thus make the debug harder. The only solution is to check all motor/wire one at the time.

Maybe try to flash the firmware but I’m really not sure it will make any difference.

I’m really not sure what you have in mind here? Is this related to what @Theo had in mind? Monitoring motors wires · Issue #146 · poppy-project/pypot · GitHub

4

The only time I saw this, it was on a Poppy Torso and every motors except AX12 caused this error. The led is working but it is impossible to communicate with them, even impossible to flash them again.
However you can try to put the ground on the data pin for a few seconds, It can solve it (with luck).

As the led is still working, the embedded microprocessor (STM32) is not totally dead. The only raison I see, is that the µP took a 12V input in the data pin, which burned the data pin on the processor (or the logic gates before it).

Two solutions:

  • you send them back to Robotis SAV (but I have not seen back the one I gave to you some months ago)
  • you open the motor an solder a new STM32 (5€). It requires a good soldering tip and good skills, but comparing to the motor price, it is almost priceless.

I think you can see rather this open issue, but it is not related to an electrical shock on motors.

5

Hi,

I’m working on the Manon’s Poppy, in which the left leg was initially unfunctional (motors 12, 13 dead).

I’ve replaced them (as I said in another post here), and I had some TimeOut problems. I’ve then tested the voltage in each leg motors, and the results were good (11.3 to 11.6V). I’ve then continued testing and trying using the robot with its legs, but non concluding. I tried several things like reducing the number of connections used in the pelvis hub, but no results too.

Well, after several tests, and I do not know how and why (Poppy was just powered, and I only scanned the motors, it was always compliant), I received the same message as @Manon for the legs port.
After testing the motors of the legs one by one, the conclusion is that the motors 12, 15, 22 and 23 are not working. Impossible to reconfigure them or anything.

Maybe I’ll try the solutions of @Theo to solve this problem.

Anyway, i’m also writing here to talk about the electronic part, especially for the legs, because I know that a lot of people have problem with the legs motors (burnt/dead), including me. According to me (I spend a lot of time informing myself on the forum), there are 2 issues (for this problem) :

  • the dynamixels are not as reliable as expected
  • the electronic (for the legs) is not so developed, and as a conclusion not reliable.

In my case, I guess that the electronics is the problem, because in 2 uses (Manon and then me), it causes several dead/burnt motors, knowing that the motors were in rest (compliant, just powered on) when it happened.

So, I want to intend something : instead of “repairing” or softly preventing (monitoring the temperature, checking the intensity…), wouldn’t be better to improve the electronics to avoid death ? I do not know whether there are works on it yet, but I think it would be great !
[Prevention is better than cure ! ]

@Matthieu It’s becoming one of my main aim. Maybe we could work on it together ? I’m working on Poppy with @Chibimoon in Génération Robots, so maybe we can meet to talk about this (and, why not, other subjects concerning Poppy).

@Theo concerning my project on movements (see here), I guess I’ll do it later. I really prefer making Poppy reliable.
[Burning Poppy costs a lot of money but also a lot of time !]