Another Python 3 serial comm issue

General discussion of using Roboclaw motor controllers
Post Reply
breuil11
Posts: 10
Joined: Tue Nov 01, 2016 7:34 pm
Another Python 3 serial comm issue

Post by breuil11 »

My issue is consistent using either Pi3 (Stretch) or Pi4 (Buster)

I have the roboclaw 2x7A from several years back with updated firmware. Using Python 2.7 with the pre-fixed roboclaw driver, I have no issues. When I use either Python 3.5 or now 3.7, the TTYS0 communication is very erratic and mostly non responsive. I'm using the July 2019 roboclaw3 driver. Using the 'bare minimum" test example Python 2.7 works great. Using same example with Python 3, it works, but there's a long delay in motor actuation and they run for for 2 or so seconds vice the coded 0.5 second sleep.

When I implement in my main robot code and compare, 2.7 is just fine and Python 3 is mostly non-responsive with occasional motor activity (but in the wrong direction), i.e., MixedForward will only drive one motor in the wrong direction vice both motors forward.

I like this controller but I'm at a loss...and I really need to move up and onward to Python3. Is it possible that the changes is Pyserial would make the signal more sensitive to noise???

Thanks
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Another Python 3 serial comm issue

Post by Basicmicro Support »

You need to use the roboclaw_3.py library instead of the roboclaw.py library file when using Python 3+. It is included in the python library download. Just change the import reference to roboclaw_3 to use it.
breuil11
Posts: 10
Joined: Tue Nov 01, 2016 7:34 pm
Re: Another Python 3 serial comm issue

Post by breuil11 »

I've been using both the roboclaw_3.py with python3 and roboclaw.py with python2. The python2 version has been working. With the python3/roboclaw_3 version the _write1 function will go through all 3 "trys" with a checksum value of [0,0] and no motor response. Sometime it responds but erratically.

...I just ran the previously working python2/roboclaw.py version and now it's not working...I'm wondering if my roboclaw controller is going bad. I've had it for over 2 years.

I know I haven't provided enough information for anyone to assess anything, but if someone can point me in a direction it would be appreciated.
breuil11
Posts: 10
Joined: Tue Nov 01, 2016 7:34 pm
Re: Another Python 3 serial comm issue

Post by breuil11 »

Fixed my Python2/roboclaw.py version...loose motor connections..working fine again. I still have the same Python3 issue. Below is output from some print statements out of roboclaw_3.py. I output the address, command, and val variables...decimal value then the converted value using .to_bytes(1,'BIG'). There's some weird output. Any ideas on what's causing this? Seems to be intermittent.
output.JPG
output.JPG (48.17 KiB) Viewed 6307 times
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Another Python 3 serial comm issue

Post by Basicmicro Support »

You are pringint characters instead of values which is why something sare coming up as characters. Non-printable values are printed as hex values. Change your debug code to print hex instead of characters.

Also when you print a string of bytes you are terminating on a 0 value instead of printing the whole array of bytes.

Those two things combined make your debug code difficult to figure out. Please fix those and re-post the information and/or email support with your user code and modified roboclaw library so we can look at what you are doing.
breuil11
Posts: 10
Joined: Tue Nov 01, 2016 7:34 pm
Re: Another Python 3 serial comm issue

Post by breuil11 »

SOLVED!!! As I was pulling together some output to provide to basicmicro support...realized my problem! I was still initializing my roboclaw write address as 0x80 hex. When I initialized as decimal (128) everything works great. By the way, the example, roboclaw_mixedpwm.py provided with the July update still initializes in hex (0x80) so don't use that with Python 3 and roboclaw_3 library.

My robot is happy again...

Image
Attachments
bot.JPG
bot.JPG (29.57 KiB) Viewed 6300 times
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Another Python 3 serial comm issue

Post by Basicmicro Support »

0x80 = 128 so I'm not sure why that would fix the problem.

However I would point I we recommend setting up the Roboclaw using Motion studio and saving the settings to the board(Device menu/Write Settings). Then you can remove any setup code from your python code.
breuil11
Posts: 10
Joined: Tue Nov 01, 2016 7:34 pm
Re: Another Python 3 serial comm issue

Post by breuil11 »

The 0x80 (128) is the address value I'm assigning to the variable used in your library function calls like in roboclaw_mixedpwm.py below. I don't know why it worked either. Thought maybe had something to do with converting something to bytes that was already in a byte format or something?? Sorry if I wasn't clear earlier. I wasn't configuring the board in my code. At work so I can't post my code. It was based on the code below except I used ttyS0 and I changed address = 0x80 to address = 128.

Thanks again.

Code: Select all

import time
from roboclaw import Roboclaw

#Windows comport name
rc = Roboclaw("COM9",115200)
#Linux comport name
#rc = Roboclaw("/dev/ttyACM0",115200)

rc.Open()
address = 0x80

rc.ForwardMixed(address, 0)
rc.TurnRightMixed(address, 0)

while(1):
	rc.ForwardMixed(address, 32)
	time.sleep(2)
	rc.BackwardMixed(address, 32)
	time.sleep(2)
	rc.TurnRightMixed(address, 32)
	time.sleep(2)
	rc.TurnLeftMixed(address, 32)
	time.sleep(2)
	rc.ForwardMixed(address, 0)
	rc.TurnRightMixed(address, 32)
	time.sleep(2)
	rc.TurnLeftMixed(address, 32)
	time.sleep(2)
	rc.TurnRightMixed(address, 0)
	time.sleep(2)
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Another Python 3 serial comm issue

Post by Basicmicro Support »

Hmm. Very odd. If anything more pops up, let me know. I don't see how changing the constant from 0x80 to 128 would have fixed it. 0x80 is just hexadecimal notation for decimal 128.

Post Reply