Additional response bytes received

General discussion of using Roboclaw motor controllers
SeeGee
Posts: 6
Joined: Mon Oct 05, 2020 5:47 am

Additional response bytes received

Post by SeeGee » Mon Oct 05, 2020 5:59 am

I'm working with a Roboclaw 2x7A with firmware v4.1.34. I'm connected via TTL serial from a Beaglebone Black at 115.2 Kbit/sec, and for the most part, things seem to work pretty well.

Where I have been running into some issues is when polling the Roboclaw for encoder counts and/or status via C++, using the Linux standard terminal I/O calls (send()/recv()). Again, it usually works properly - I send a valid two-byte request about 10 times per second, and usually I get the expected 7-byte response with a valid CRC in both cases. However, occasionally instead of the expected response, I will receive a blast of data (400-500 bytes) that consists of the expected response repeated over and over again. There doesn't seem to be any rhyme or reason to when these chunks of data are received, but the received data itself doesn't look like noise, so I don't really think it's interference from the motors.

Any ideas what could be behind this behavior?

User avatar
Basicmicro Support
Posts: 1555
Joined: Thu Feb 26, 2015 9:45 pm

Re: Additional response bytes received

Post by Basicmicro Support » Mon Oct 05, 2020 8:57 am

I've never seen this. Can you get a dumb of the 400-500 bytes? Also I'd like to see your code for BeagleBone. Try to keep it as simple as possible to reproduce the problem.

SeeGee
Posts: 6
Joined: Mon Oct 05, 2020 5:47 am

Re: Additional response bytes received

Post by SeeGee » Sat Oct 10, 2020 9:34 am

Sorry for the late response. I'm not really able to post the existing code as-is due to corporate rules, so what I did was distill it down to the simplest representative code I could. I ran that, and haven't been able to get the behavior to repeat itself. Soooo, it looks a lot more likely that there's something flaky with the code I'm working with than the Roboclaw itself.

I'll continue working with it as I can, and if the issue shows itself with the code that I *can* give you, I'll post an update. Thank you for the timely response just the same.

SeeGee
Posts: 6
Joined: Mon Oct 05, 2020 5:47 am

Re: Additional response bytes received

Post by SeeGee » Sat Oct 24, 2020 5:02 pm

I got some time to follow up on this a bit more, as my demo code wouldn't exhibit the problem but the in-situ code continues to do so. I finally found my logic analyzer, and hooked it up to the TX/RX pins to see exactly what was happening.

Every half-second or so, I'm retrieving the status of the Roboclaw via these five messages (and their expected responses, which I *usually* receive properly). "S(X)" indicates a send of message type X, and "R" indicates a receive:

Code: Select all

S(16): 80 10
R: FF FF FF EB 80 32 D2 
S(17): 80 11
R: FF FF E7 00 82 71 BA 
S(49): 80 31
R: 00 00 00 02 52 DD 
S(79): 80 4F
R: 00 00 00 00 00 00 00 00 23 B9 
S(90): 80 5A
R: 00 40 00 00 9A 11
This data is correct, and the exchange runs fine from anywhere from 1 to several dozen cycles. Then, occasionally I will get something like this:

Code: Select all

S(16): 80 10
R: FF FF FF EB 80 32 D2 
S(17): 80 11
R: FF FF E7 00 82 71 BA 
S(49): 80 31
R: FF FF FF EB 80 32 D2 
R: FF FF E7 00 82 71 BA 
R: 00 00 00 02 52 DD 
R: 00 00 00 00 00 00 00 00 23 B9 
R: 00 40 (delay) 00 00 9A 11 
R: FF FF FF EB 80 32 D2 
R: FF FF E7 00 82 71 BA 
R: 00 00 00 02 52 DD 
R: 00 00 00 00 00 00 00 00 23 B9 
(delay)
R: 00 40 00 00 9A 11 
R: FF FF FF EB 80 32 D2 
R: FF FF E7 00 82 71 BA 
R: 00 00 00 02 52 DD 
R: 00 00 00 00 00 00 00 00 (delay) 23 B9 
R: 00 40 00 00 9A 11 
R: FF FF FF EB 80 32 D2 
R: FF FF E7 00 82 71 BA 
R: 00 00 00 02 52 DD 
R: 00 00 00 00 00 00 (delay) 00 00 23 B9 
(RX data continues for several more cycles/hundreds of bytes)
Graphically, the last exchange looks like this (data sent to the Roboclaw is on channel 0, received data is on channel 1):

saleae.png
saleae.png (112.18 KiB) Viewed 2940 times

It's like the Roboclaw is remembering previous commands and is responding to them repeatedly in a single burst. The system will not let me attach the Saleae analyzer capture file, so if there's an email address I can send it to, I'll do so ASAP - this will show exact timings for the TX/RX data. The Saleae software is available for free from saleae.com.

For the time being, I'm going to try to slow down the exchange a bit and see if that makes a difference, and will update this thread with the results.

SeeGee
Posts: 6
Joined: Mon Oct 05, 2020 5:47 am

Re: Additional response bytes received

Post by SeeGee » Sat Oct 24, 2020 9:03 pm

Slowing things down didn't make any difference, but I did make more progress. It occurred to me that my example code (which worked) wasn't doing something that my production code did - it did not send a "Set S3, S4 and S5 Modes" (74) command on startup. I removed that command from the production build, and poof, everything worked perfectly. I also added the command to my test code, and it destablized the Roboclaw in the same manner that I had seen before.

Attached is a C++ example that will reproduce the issue, along with a makefile. Running the test app as "rc_test" should run without issue. Running it as "rc_test 1" will set the S3/S4/S5 modes, wait 5 seconds, then will begin issuing the requests to the Roboclaw. The issue should show itself shortly thereafter. On my own device, I've found that running the test code with the "set modes" command enabled will also cause subsequent runs *without* setting the mode to also fail, requiring a power cycle of the Roboclaw to clear the issue.

Please let me know if anything looks iffy in the code or if any further info is needed. Thanks!

Edit: It occurs to me that setting the pin modes really is kind of pointless upon startup, since the device has to be power cycled afterwards anyway. So, this whole adventure was probably a waste of time except from a "hey, that's interesting behavior - don't do that" perspective.
Attachments
rc_test.zip
(2.81 KiB) Downloaded 86 times

User avatar
Basicmicro Support
Posts: 1555
Joined: Thu Feb 26, 2015 9:45 pm

Re: Additional response bytes received

Post by Basicmicro Support » Mon Oct 26, 2020 8:21 am

I was basically going to say the same thing as your last edit. :)

Set S3,S4,S5 Mode and SetConfig commands are complicated because of the reset/power cycle requirement. At some point(once I have the time) I will look into this further. Without a close up of the "garbage" data I would suspect Roboclaw got a readversion command and was dumping the version string out. It is the only command that would send that much data back.

SeeGee
Posts: 6
Joined: Mon Oct 05, 2020 5:47 am

Re: Additional response bytes received

Post by SeeGee » Wed Oct 28, 2020 12:37 pm

I'd been looping through a 16 and 17 (get encoder counts), a 49 (get motor currents), a 79 (read ispeeds counters), and a 90 (get status), and up to the point where things went wonky, I'd received valid responses to each command. The huge chunk of data that I was getting back were a single block of repeated responses to those previous commands, usually starting in response to the "get motor currents" command in the loop. At no time was a version request sent, nor was a version response in the data received.

Knowing what triggers it, it's not a problem now, especially since you're not really supposed to do anything after setting the pin modes anyway. I'm not thinking it even has to call for a fix since it should probably be considered undefined behavior to continue working with the Roboclaw afterwards without cycling the power.

But, I figure it's probably not a bad idea to have it documented here in case someone else runs across the same scenario.

SeeGee
Posts: 6
Joined: Mon Oct 05, 2020 5:47 am

Re: Additional response bytes received

Post by SeeGee » Wed Oct 28, 2020 12:42 pm

As an aside, your responsiveness to the issue was very encouraging - thank you! It makes me a lot more likely to recommend Roboclaws as a low-cost solution for a lot of our internal R&D needs for the robotics and other motion-related groups. They're really capable little controllers, they respond very well (when you're not abusing them like I did), and in general my experience has been that they're a great piece of kit.

User avatar
Basicmicro Support
Posts: 1555
Joined: Thu Feb 26, 2015 9:45 pm

Re: Additional response bytes received

Post by Basicmicro Support » Tue Nov 03, 2020 8:14 am

I will need to see your code. Preferable a very trimmed down version that shows the problem. Anything proprietary will make it impossible to actual run on this end so please try to provide as generic an example of your code as possible. You can email it to support@basicmicro.com.

woko1754
Posts: 11
Joined: Sun Feb 21, 2021 3:16 am

Re: Additional response bytes received

Post by woko1754 » Sat Sep 25, 2021 1:46 am

I discovered the same problem. Is there a solution available ?

Post Reply