PDA

View Full Version : Dynamixel SDK linux: COMM_RXTIMEOUT error



Deimos
01-15-2014, 06:56 PM
Hi,

I've been having some issues getting the dynamixel SDK working with my USB2AX, and I have no idea what could be going wrong :(. I've tried this on both my laptop running Arch and my BBB running Angstrom, with the same results:

- Download dynamixel sdk for linux here: http://support.robotis.com/en/software/dynamixel_sdk/usb2dynamixel/usb2dxl_linux.htm

- Change line 25 of dxl_hal.c (https://github.com/Jared-B/Fang/blob/master/DXL_SDK/src/dxl_hal.c#L25) from "/dev/ttyUSB%d" to "/dev/ttyACM%d", because the USB2AX shows up on ttyACM not ttyUSB.

- Compile library, then "ReadWrite" example using included makefiles

- Run the example; it returns "Succeed to open USB2Dynamixel, press enter to continue" or something along those lines

- Press enter, it returns "COMM_RXTIMEOUT" (which I believe means that it isn't receiving a status packet), and connected AX-12 doesn't move.

I've checked the servos using Roboplus and the same USB2AX. The dynamixel wizard shows both ID and Baud rate set to 1. The servos work fine using the power supply (12v 5A). I tried changing the ID of the servo in the example to broadcast, and it stops complaining about the lack of status packets (I'd assume because the servos don't return a status packet off of a broadcast), but still no movement.

I tried using an FTDI to listen in on the dynamixel bus, and it seems as though the USB2AX is sending nothing at all (I was able to read packets sent from an Arbotix). I'll probably have to try this again, to make sure.

Unfortunately I do not have a logic analyzer or scope, so debugging these kinds of issues is a little more difficult :p.

So, any ideas about what I might be doing wrong? Anything I can do to try to locate the issue?

KevinO
01-15-2014, 07:12 PM
Correct me if I'm wrong but you need to change more than line 25 in the dxl_hal I believe. It's been a while since I've had that open but I thought there was a couple of sections that are commented out. Xevel had a new version you could download off his site. https://paranoidstudio.assembla.com/code/paranoidstudio/git/nodes/master/usb2ax/soft Though glancing at, it seems just a bit of clean up.

You could always increase the wait time of the dxl_set_timeout to give it more time to respond.

KevinO
01-15-2014, 07:15 PM
There is also the possibility your login isn't part of the dialout group. By default you are not added usually, at least with Ubuntu you are not. (5 bucks this is it!)

Deimos
01-15-2014, 07:40 PM
I've fixed the dxl_hal.c file, and will test it out in a bit (note to self: read Xevel's guide on using the SDK before using the SDK :p).

KevinO
01-15-2014, 07:42 PM
If you haven't added yourself to the dialout group go ahead and do it. I've forgotten every single time I've built a new project based off Linux and draw a blank for a few seconds when it doesn't send out any commands. :P

tician
01-15-2014, 07:52 PM
I seem to remember there being a common problem with the very short timeout period in the linux version of the dxl library from Robotis.


Line 154 has the timeout equation and it would not hurt to change that from:

gfRcvWaitTime = (float)(gfByteTransTime*(float)NumRcvByte + 5.0f);
to the windows version of:

gfRcvWaitTime = (float)(gfByteTransTime*(float)NumRcvByte + 2*LATENCY_TIME + 2.0f);
and insert at ~line 12:

#define LATENCY_TIME (16)

kamondelious
01-15-2014, 08:26 PM
Here's what I did to get the basic functionality working. The howto docs on Xevel's site miss a few changes.


$ diff -b robotis/src/dxl_hal.c robotis/xevel_src/dxl_hal.c 22c22
< struct serial_struct serinfo;
---
> //struct serial_struct serinfo;
25c25
< sprintf(dev_name, "/dev/ttyUSB%d", deviceIndex);
---
> sprintf(dev_name, "/dev/ttyACM%d", deviceIndex); // USB2AX is ttyACM
36c36
< newtio.c_cflag = B38400|CS8|CLOCAL|CREAD;
---
> newtio.c_cflag = B1000000|CS8|CLOCAL|CREAD;
48a49,50
> //USB2AX uses the CDC ACM driver for which these settings do not exist.
> /*
61c63
< }
---
> }*/
76c78
< newtio.c_cflag = B38400|CS8|CLOCAL|CREAD;
---
> newtio.c_cflag = B1000000|CS8|CLOCAL|CREAD;
106a109,110
> //USB2AX uses the CDC ACM driver for which these settings do not exist.
> /*
120c124
<
---
> */


I never got the sync read feature working. It appears to require further changes within dynamixel.c which I have never completely figured out. dxl_tx_packet validates the instruction packet and requires something more than simply adding INST_SYNC_READ to dynamixel.h and

&& gbInstructionPacket[INSTRUCTION] != INST_SYNC_READ
in the if statement with the rest.

Deimos
01-15-2014, 08:31 PM
Works great with those changes! Thanks for your help!


There is also the possibility your login isn't part of the dialout group. By default you are not added usually, at least with Ubuntu you are not. (5 bucks this is it!)

I'm assuming that is the same as the uucp group an Arch (Gives access to "serial and USB devices such as modems, handhelds, RS-232/serial ports."). If so, then I ran into that problem when setting up the arduino IDE and I fixed it a while ago :D.

And thanks for the tip Tician, your suggested code hasn't broken anything so I'm going to assume it's helping :).

Are you sure Xevel's code doesn't include all the necessary changes Kamondelious? This (https://github.com/Jared-B/Fang/blob/master/DXL_SDK/src/dxl_hal.c) seems to work, and all I did was add in Xevel's changes.

Xevel
01-16-2014, 01:38 AM
There is also the possibility your login isn't part of the dialout group. By default you are not added usually, at least with Ubuntu you are not. (5 bucks this is it!)

A good addition to the doc, thanks!
I always forget these kind of things too :/



I seem to remember there being a common problem with the very short timeout period in the linux version of the dxl library from Robotis.


Line 154 has the timeout equation and it would not hurt to change that from:

gfRcvWaitTime = (float)(gfByteTransTime*(float)NumRcvByte + 5.0f);
to the windows version of:

gfRcvWaitTime = (float)(gfByteTransTime*(float)NumRcvByte + 2*LATENCY_TIME + 2.0f);
and insert at ~line 12:

#define LATENCY_TIME (16)


The LATENCY_TIME thing seems to me to be designed specifically to take into account the default latency setting of the FTDI driver... Anyway, that's an interesting fix, and i will add it to the documentation too, just in case.



Here's what I did to get the basic functionality working. The howto docs on Xevel's site miss a few changes.


$ diff -b robotis/src/dxl_hal.c robotis/xevel_src/dxl_hal.c 22c22
< struct serial_struct serinfo;
---
> //struct serial_struct serinfo;
25c25
< sprintf(dev_name, "/dev/ttyUSB%d", deviceIndex);
---
> sprintf(dev_name, "/dev/ttyACM%d", deviceIndex); // USB2AX is ttyACM
36c36
< newtio.c_cflag = B38400|CS8|CLOCAL|CREAD;
---
> newtio.c_cflag = B1000000|CS8|CLOCAL|CREAD;
48a49,50
> //USB2AX uses the CDC ACM driver for which these settings do not exist.
> /*
61c63
< }
---
> }*/
76c78
< newtio.c_cflag = B38400|CS8|CLOCAL|CREAD;
---
> newtio.c_cflag = B1000000|CS8|CLOCAL|CREAD;
106a109,110
> //USB2AX uses the CDC ACM driver for which these settings do not exist.
> /*
120c124
<
---
> */


I fail to see the difference with what is on my website, could you point it out please?



I never got the sync read feature working. It appears to require further changes within dynamixel.c which I have never completely figured out. dxl_tx_packet validates the instruction packet and requires something more than simply adding INST_SYNC_READ to dynamixel.h and

&& gbInstructionPacket[INSTRUCTION] != INST_SYNC_READ
in the if statement with the rest.

Sync_Read is indeed different from the rest of the Dynamixel commands and necessitates some develpment to include in the SDK. The structure is detailed here : http://www.xevelabs.com/doku.php?id=product:usb2ax:advanced_instructions