RX_TIMEOUT error when setting power to Dynamixel Pro - Raspberry Pi

[jgrosso]

Hi!

New to the forums (and robotics), so forgive me
When trying to run

dxl_monitor

, I'm getting the following error message on my Raspberry Pi (after enabling

DEBUG_PRINT

:

[Dynamixel Monitor for DARwIn v1.00]

/dev/ttyUSB0 open success!
Set 1000000.0bps success!

TX: FF FF C8 04 03 18 01 17 INST: WRITE
RX: Time:5.10ms RETURN: RX_TIMEOUT
 Fail to change Dynamixel power!
Failed to connect Arbotix Pro!
Terminated DXL Manager.

I have tried a different GPIO connector, but no luck. I did accidentally leave the ArbotixPro controller (along with the Raspberry Pi) plugged in all night a couple days ago, if that could have any effect.


It seems that others have solved the problem by either installing a different distro or using the Edison instead, but I wouldn't want to deviate from the recommended configuration unless I have to.

Thanks so much!

[Maxzor]

Is it first possible to manage dynamixels directly from a Raspberry pi?

[KurtEck]

Have you tried it a couple of times and it still fails? I have whole thread talking about Raspberry Pi (or Odroid) having issues talking to the Arbotix Pro. This is due to FTDI usb delays, which sometimes can be rather long...

What software are you running? Are you using the HROS1 framework? If so awhile ago, I believe they merged in a change I made to mine, which tries to flush (tcdrain) the data out before starting the RX timing code. This helped reduce the number of timeouts, but did not totally eliminate them...

That is why I have experimented with updating the Arbotix Pro firmware to allow me to use a TTL USART on it to talk to the host, which I believe is working pretty well. I had it working with RPI2 as well as Odroid C1 and ODroid XU4 (Through TTL level converter). However this can be problematic as you need additional hardware to update the firmware on the Arbotix-Pro. And at least the first batch of Pros did not have the connector installed on the board to do this....

[jgrosso]

Thanks! My problem was actually that I had a faulty Arbotix Pro... I was shipped a new one, and it's working fine.
However, how would one deal with different Dynamixels that are failing each time dxl_monitor is run? (#13, R_KNEE is often a problem).

[KurtEck]

I am glad to hear you are back up.
Warning: I am rusty on the dxl_monitor program, I have my own code base that I did awhile ago that I use for looking at servos under Linux... But dxl_monitor is pretty nice...

Does servo #13 work at all? Or does it always fail? If always fail? Example if you start up the PS3 code, does the knee work?

If it does not work at all, it might have reset its servo id to #1, which would conflict with the real #1 in the shoulder.

One way to test this is to set ID=1 in DXL_MONITOR.
Assuming it allows you to, then tell servo #1 to move. to some position lets say 400
Again I don't have dxl monitor running right now, but the command is something like:
write 30 400

Does a servo in the shoulder move? Does the knee also move? If so it reset.

If this is the case, then you need to reset the ID of the knee servo back to 13.
Which you might be able to do, by:
First remove the DXL wire going to the shoulder that has the real #1.
Then assuming the monitor is still set to #1, I would try doing a move again to see if knee moves.
Then try to set it's id, maybe something like: write 3 13
(register 3 is the ID).

Now see if you can set the dxl monitor to servo #13... If so
Remember then to replug in the dxl connector going to the shoulder that you unplugged.

Warning: sometimes more than one servo can reset, so if when you told servo #1 to move, if more servos moved as well, you then need to reset each them to their appropriate servo ID. To do this you need to isolate each one such that only one #1 is connected at a time...

[ionutned]

Hi!

I'm reviving this old thread since I'm getting exactly the same error.

Now, just like the user before me, I talked to the company and they said the board must be faulty, they send me another one and... with the second one I get the same errors. I find it hard to believe this is a coincidence. Maybe I'm doing something wrong.. Although the instructions are very clear, not much possibility to mess up.
Could it be a software problem? Does anyone know if there are other tools to control those damn motors or am I forced to work with this HROS1 framework and its dxl_monitor ?

I tried it with both the edison and the pi.

[KurtEck]

I have not touched mine in awhile.

as I mentioned, I use my own Linux code, and test programs, sometimes it is simply some servo reset its identity to #1, which causes issues. Or it is the ftdi delay issue I mentioned. Or maybe delay value set on servos...

[ionutned]

I have not touched mine in awhile.

as I mentioned, I use my own Linux code, and test programs, sometimes it is simply some servo reset its identity to #1, which causes issues. Or it is the ftdi delay issue I mentioned. Or maybe delay value set on servos...

Looking in the docs for AX-12, I see a register called Return Delay Time, is this is what you're referring to?
Anyway, the funny thing is that with the current hardware setup I cannot access the servos directly, only through this arbotix pro. And this is the one that's not working, even the ping fails.

I assume there are other controllers which can be used for these servos, right?

[KurtEck]

First with the Arbotix Pro - If it were me, I would try to get it to talk to only a few servos at a time, to see if you can get any of them to talk.

I would also use my own library code to see if I can talk to them or not. That is I have my own Raspberry Pi project (which is a hodge podge of stuff) that needs to be cleaned up https://github.com/KurtE/Raspberry_Pi. It actually is setup to run on several different Linux boards, but was started when I first started playing with Raspberry Pi...

There is a program there AX12_Test, which again is a simple collection of tests, but can scan for servos and the like. Code is also setup to work with different controllers. In particular some controllers create devices /dev/ttyUSB0 and others create /dev/ttyACM0, plus also setup where you can use a udev rule to create a specific device /dev/ttyDXL which I use when I do things like use the Serial port of the RPI to talk to another board...

Edit: forgot to mention, yes the Return Delay time is what I was mentioning, and I typically set those to 0

And yes I do have other controllers.

The simplest one to use is one by Xevel - USB2AX which you can purchase from Trossen: http://www.trossenrobotics.com/usb2ax or Seeedstudio: https://www.seeedstudio.com/s/usb2ax.html or...

Robotis also sells several adapters.

I have made my own using Teensy processors...

However the HROS1 code base is sort of specifically setup to use the Arbotix Pro which was based off of the CM730 robotis board. And for example has the GYRO and ACCEL on board and does a query that grabs data from Servos and the like and sends all of it back as one packet. For awhile I was doing my own version of it using a Teensy, but have not played with it for awhile, as for example you might be better off using an independent IMU, that the host can talk to directly and maybe at USB full duplex...

As for the HROS1 framework, I have not touched mine for awhile: https://github.com/KurtE/HROS1-Framework
I believe that Andrew merged in one of my fixes that helped with the timeout, which was to do an RCDrain before starting timeout...
Helped a lot but still got several. I got less with ODroid, which I was using later

[ionutned]

Thank you for your detailed answer.

My problem with the arbotix pro is not that I can't talk to the servos, I can't talk to the board itself, even a simple ping times out. I'm not sure if modifying that return delay would change anything, but I can't do it, because I cannot set that value on the arbotix, any command to change it would time out..

I also thought about writing my own code to test it. After analyzing the Dynamixel protocol and the source code of the HROS1, basically I would have to write the exact same code anyway.. I will try your examples and see what happens.

The thing about the arbotix pro is that I got it with one of these robot kits, so it's all supposed to fit in well together. I could move to another controller, since having a controller with factory-written firmware which I cannot control is not ideal, but then I would also need to make new parts to stick the new board on the robot, because of different dimensions. Then if I need an accelerometer (and I most likely will), I would need a mounting solution for that too. My aim was to minimize all this hardware stuff, which is not really my thing.
For example I got an openCM and tested it yesterday, it works fine, I can do anything with the servos. I could in theory use it instead of the arbotix, especially since it's fully programmable, except for the hardware problems described above. Being a newbie in the area, I can't always tell the pros and cons.
Edit: with another board I will also have to find an alternate solution for powering the raspberry pi. Using two separate batteries for this seems like an overkill.

I will also try the hros1 framework from your github and see if there's any difference at all.