roboclaw 7A delayed motor stop

[breuil11]

I'm working on a tracked robot application and am having trouble with the motors continuing to drive for about a half second after being commanded back to 0 (I'm about 99.9% sure its not coasting to stop, but actively being driven.) This makes it very hard to control the robot to a particular direction, especially at higher speeds.

Configuration:
Raspberry Pi 3
roboclaw 7A v5
- Packet Serial
- 115200 baud
- RPi UART TXD (GPIO14) connected to roboclaw S1

My main code is written to drive via keyboard at the moment, so I wrote the simple code below to make sure I wasn't having keyboard input issues. The problem still persists.

####begin code sample
import time
import roboclaw

#Linux comport name
roboclaw.Open("/dev/ttyS0",115200)
address = 0x80

roboclaw.ForwardM1(address,30)
roboclaw.ForwardM1(address,0)
####end code sample

Is this typical behavior? Is this maybe a RPi issue? Is there a way to get a faster response? I was expecting that after commanding ForwardM1 to 30 followed immediately with a command to 0, the motor would simply "bump" or not move at all.

I'm new to this. I like the controller and would actually be happy if someone told me I was making a noob mistake.

Thanks for any help

[Basicmicro Support]

I would suspect the second command is failing to execute properly immediately(there is an automatic retry built in to commands that fail to ack properly). You will need to see if this is the case or not by adding some code to see how long each command is taking.

You can print the current processor tick in milliseconds using this:

import time

and

millis = int(round(time.time() * 1000))
print millis

Put these two lines before and after each command to see the start and stop time so you can see if the command is being delayed. If it is it indicates the command is retrying. If that is the case I recommend using a slower baudrate to see if the problem is a timing mismatch causing bad data.

[breuil11]

Thanks for the response. I ran the code below at the original 115200 and then at 9600...

import time
import roboclaw

roboclaw.Open("/dev/ttyS0",9600)
address = 0x80
millis = int(round(time.time() * 1000))
print millis
roboclaw.ForwardM1(address,30)
millis = int(round(time.time() * 1000))
print millis
millis = int(round(time.time() * 1000))
print millis
roboclaw.ForwardM1(address,0)
millis = int(round(time.time() * 1000))
print millis

...the motor ran both times (for about 0.31 sec based on numbers below) with the following output (only showing last 3 digits)

{at 115200 baud}
249
550
550
851

{at 9600 baud}
134
435
435
736

Seem to have the same delay for both baud rates before the second motor command is executed. Any other tips would be appreciated.

Thanks

[Basicmicro Support]

First make sure you have the latest firmware installed on the Roboclaw. If it has older firmware before the checksum and ack changes then the commands will run but the python library will think they didnt and keep trying until they timeout.

Also you should check the return value from the function calls to see if they are showing an error.

[breuil11]

Thanks again. I'm working to get the firmware updated. However that leads me to another beginner question.

Connecting the roboclaw to Windows via IonMotion. Right now all I have is a USB to TTL converter and not having much luck.
1. Is using the USB to TTL converter vs a Serial Port to TTL a non-starter?
2. I have not found any kind of tutorial or instruction on connecting to IonMotion. Does the roboclaw 7A v5 have to be in a certain mode? Right now I'm connection to the S1 and S2 pins in Packet Serial mode. Can you point me to a thread or instructions.

Thanks

[Basicmicro Support]

Firmware can only be updated directly through the USB connection on the Roboclaw. If you are using an old Roboclaw that doesnt have the USB connector than that unit must be sent in to get the firmware update.

If your board is that old that does explain why you are having trouble with the python commands. The check sum was changed last year from a simple 8bit sum checksum to a CRC16 checksum and all the libraries were updated to use the new format.

[breuil11]

I've got the USB connector on my board. I apparently referenced an old post that talked about needing to use a Serial to TTL converter for connecting to IonMotion for a firmware update.

So have all the python libraries linked on the download page been updated for the new checksum?

Thanks for the help. Hopefully I can get it worked out from here.

[breuil11]

Updated the firmware (.16 to .19) and everything is working great...problem solved.

Thanks!

[Basicmicro Support]

Great, Let me know if you need anything else.