Please validate my assumptions
-
- Posts: 3
- Joined: Wed Jan 17, 2018 2:09 pm
Please validate my assumptions
I was recently asked to implement packet control of a RoboClaw unit, driven through an embedded linux board.
I have chosen USB packet serial mode for communications. The RoboClaw module is UDP connected to multiple enpoints for drive control, gathering sensor data, and administration. All will connect through the UDP socket. The RoboClaw will connect via USB/FTDI serial, as I understand that functionality is native to the RoboClaw, and that it can then handle all IO through the USB serial port in packet mode? There will be no other serial or RC connections to the unit.
The RoboClaw module opens the USB/ftdi serial port and simply uses it as an asyncronous comm port in raw character mode.
* Are packet serial commands immediately acknowledged, or is there a command processing delay before a response is returned? If so, what is the maximum time to allow before registering an error?
* Can multiple drive commands be stacked as a stream without waiting for acknowlegement from the RoboClaw, or must I send each command and wait for a response, as a distinct transaction? I effectively want both motors to receive their velocity commands at the same time, so I don't want to have to wait any significant time for a response when driving motor-1, then repeat for motor-2.
My scenario would be as follows in pseudo-code:
string drive1("motor drive command 1");
string drive2("motor drive command 2");
string driveBoth = drive1 + drive2;
serial->send(driveBoth);
response = receive(timeout = ?) // expect {0xff,0xff} since two commands were sent
Is this use valid, and what must I allow for as a mamimum response time? per command, and
when stacked?
As others have stated, a real protocol with guranteed framing would be preferable to having to guess at the unit's state?
I have chosen USB packet serial mode for communications. The RoboClaw module is UDP connected to multiple enpoints for drive control, gathering sensor data, and administration. All will connect through the UDP socket. The RoboClaw will connect via USB/FTDI serial, as I understand that functionality is native to the RoboClaw, and that it can then handle all IO through the USB serial port in packet mode? There will be no other serial or RC connections to the unit.
The RoboClaw module opens the USB/ftdi serial port and simply uses it as an asyncronous comm port in raw character mode.
* Are packet serial commands immediately acknowledged, or is there a command processing delay before a response is returned? If so, what is the maximum time to allow before registering an error?
* Can multiple drive commands be stacked as a stream without waiting for acknowlegement from the RoboClaw, or must I send each command and wait for a response, as a distinct transaction? I effectively want both motors to receive their velocity commands at the same time, so I don't want to have to wait any significant time for a response when driving motor-1, then repeat for motor-2.
My scenario would be as follows in pseudo-code:
string drive1("motor drive command 1");
string drive2("motor drive command 2");
string driveBoth = drive1 + drive2;
serial->send(driveBoth);
response = receive(timeout = ?) // expect {0xff,0xff} since two commands were sent
Is this use valid, and what must I allow for as a mamimum response time? per command, and
when stacked?
As others have stated, a real protocol with guranteed framing would be preferable to having to guess at the unit's state?
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Please validate my assumptions
packet serial commands are acknowledhed immediately when using USB. When using TTL baudrates at or below 38400 have a 1ms delay added.
Only one thread should handle communciations to the Roboclaw.
You should wait for the ack. However there are dual motor commands to allow controlling both motor channels atomically.
Only one thread should handle communciations to the Roboclaw.
You should wait for the ack. However there are dual motor commands to allow controlling both motor channels atomically.