PDA

View Full Version : [Question(s)] Can not read response bytes from arbotix-m (C++) (PhantomX Pincher)



Max
08-01-2015, 01:43 PM
Hey, I am writing a c++ ROS node in style of the arbotix (http://wiki.ros.org/arbotix) package for the phantomx pincher.
The goal is basically to communicate with the arbotix-m board like the python node does.

I started to write a simple programm that reads out the temperature or pings a servo.
For the abstraction of the serial communication I use the serial library which is distributed over the ROS network (http://wiki.ros.org/serial) to keep as much as possible inside the ROS ecosystem.
Now I encounter a very strange problem while reading out the dynamixel registers. This is what happens:

1. My program writes the specific bytes for reading out the temperature on servo 1:

0xff 0xff 0x01 0x04 0x02 0x2b 0x01 0xcc
2. The LED on the arbotix blinks indicating that some kind of cummunication is active.
3. My programm waits for the return package but that never comes (after 1 second it stops waiting and exits).

Now the strange part:
1. I start cutecom and connect to the arobitx device with the same settings as in my programm (port,baud,parity,stopbit).
2. When I start my programm in parallel it still does not work
3. I send an arbitrary byte e.g. 0x0d in cutecom to the port.
4. My programm suddenly is able to recieve the response bytes and acts as it should, every time I run it.


When I shut down cutecom my programm is again not able to recieve the response bytes.
I tried to start the communication in my program with an arbitrary byte but that does not change anything.
Besides cutecom I can also use arbotix_terminal to connect to the board and send one command (get temp 1) which returns succesfully.
Then my programm works fine too, as long as i stay connected with arbotix_terminal.


My settings are:

baud: 115200 (copied from the arbotix.py)
port: /dev/ttyUSB0
parity: none
stopbit: 1
bytesize: 8

I know that the basic serial communication, the arbotix board and the servos work, because when I fire up the arbotix/arbotix_python node all acts as it should.
All topics are published and I can watch e.g. the diagnostic topic that echos current joint positions etc.

I first thought of some extra magic going on in the python files of arbotix_python that I am missing, but in cutecom I am able to send the request package and recieve the correct response bytes (but first I also have to send an arbitrary byte).
I tested the whole stuff with a different serial library (libserial) but got the same results.

Maybe there is something stealing my response bytes so I can not recieve them in my programm until some 'real' connection is established and secures them (if that makes any sense).
But that would not explain the 'arbitrary first byte' in cutecom.

Have you any ideas what is going wrong?

Os is Ubuntu 14.04 (3.13-61) x64.
This is the code (relevant stuff):



int main(int argc,char**argv){

serial::Serial serialComm_("/dev/ttyUSB0",115200);
serialComm_.setBytesize(serial::eightbits);
serialComm_.setParity(serial::parity_none);
serialComm_.setStopbits(serial::stopbits_one);

serial::Timeout timeout_struct;
timeout_struct.inter_byte_timeout=0;
timeout_struct.read_timeout_multiplier=0;
timeout_struct.read_timeout_constant=1000;
timeout_struct.write_timeout_multiplier=0;
timeout_struct.write_timeout_constant=1000;
serialComm_.setTimeout(timeout_struct);


UBYTE id=0x01;
UBYTE inst=ARBOTIX_READ_DATA;
UBYTE reg=ARBOTIX_TEMPERATUR;
UBYTE nBytes=0x01;
UBYTE len=0x04;
UBYTE checksum=255-((id+len+inst+reg+nBytes)%256);

UBYTE buffer[8];
buffer[0]=ARBOTIX_PREFIX;
buffer[1]=ARBOTIX_PREFIX;
buffer[2]=id;
buffer[3]=len;
buffer[4]=inst;
buffer[5]=reg;
buffer[6]=nBytes;
buffer[7]=checksum;

for(int i=0;i<8;i++)
{
ROS_INFO("Byte%d:%X",i,buffer[i]);
}

serialComm_.flushInput();
serialComm_.write(buffer,8);

UBYTE input[7] = {};

serialComm_.read(input,7);
serialComm_.flushOutput();

for(int i=0;i<7;i++)
{
ROS_INFO("Byte%d:%X",i,input[i]);
}
}

kgranat
08-07-2015, 11:34 AM
I don't think this will solve your problem, but I would recommend that you remove jumper 2 (j2). This is the reset jumper that allows the FTDI cable to reset the ArbotiX-M for reprogramming. Depending on how your drivers are setup, you may be resting the board every time you open the serial port. This can cause some headaches as the boot loader waits several seconds before it starts to run the Arduino code. If you remove the jumper, then the FTDI/computer can't reset the board. This will help you debug a little more reliably.

I've got a little more information on ftdi resets here
http://datablue.net/index.php/blog/11-never-trust-an-ftdi

I'm assuming that you're using the standard ROS firmware on the ArbotiX-M, right?


Do you have access to a second FTDI or other usb-serial adaptor?

Max
08-19-2015, 08:39 AM
Thanks for your reply.
I did not have the time to try the jumper trick yet, but maybe it will fix that strange behaviour when sending the first bytes.
Yes I am using the standard ros firmware on the arbotix-m and I have access to up to 5 robots with all the same cable though.

I could solve the read problem by using yet another serial library (cerealPort (http://isr-uc-ros-pkg.googlecode.com/svn/stacks/serial_communication/trunk/cereal_port/)).
This library offers several read functions and one of them worked.
I guess the other libraries and some of the current read functions may be waiting for some kind of EOL that is not sent by the arbotix-m.
The working read function maybe just reads nBytes no matter what kind of bytes. But thats just guessing and I am happy as long as it works. Maybe I will dive a bit deeper into the reason when there is more time.

The strange behaviour when sending the first bytes after the usb cable was disconnected still persists but maybe the jumper will do the trick.
At the moment I have a loop over the first command until the arbotix-m responds and called this 'initialization' :wink: