ROS2: Updating ~/Dexter/ on Ubuntu 20.04.2

I’ve created quite an edge case with this “ROS2 on GoPiGo3” project, and now need to update the Dexter software.

My ROS2 GoPiGo3 node is publishing its whereabouts and responding to motor commands but ROS2 is using the “pre-16-tick” GoPiGo3 version code.

(In my non-ROS tests, I manually reset the EasyGoPiGo3 object “constants”, not a good approach for a generic ROS2 driver.)

I’m pretty sure I should just clone the new code down and run setup the way I originally did, but have filed an “issue” to see if MR has any spare cycles for my “one in a million” edge case.

Tagging: @mitch.kremm as an FYI (not sure if you wander “git-land”)

For innocent bystanders: The Python “Steering Committee” deemed Python2 to be “Dead and Done With” (EOL April 2020) causing nightmares for every corporation with a code base in use by more than three customers.

" Python 3.0 was released in 2008 and was a major revision of the language that is not completely backward-compatible and much Python 2 code does not run unmodified on Python 3. Python 2 was discontinued with version 2.7.18 in 2020. "

Peterson, Benjamin (20 April 2020). “Python Insider: Python 2.7.18, the last release of Python 2”. Python Insider

==== FIX FAILED INSTALL (ROS2 Distance_sensor reports No module named ‘I2C_mutex’)
$ pushd ~/Dexter/lib/Dexter/RFR_Tools/miscellaneous/
$ sudo python3 setup.py install

  • check it:
    $ unzip -l /usr/local/lib/python3.8/dist-packages/Dexter_AutoDetection_and_I2C_Mutex-0.0.0-py3.8.egg
3 Likes

I have renamed pip2 to pip for now, although this will lead to issues on GoPiGo OS. It’s something I have to revisit.

2 Likes

Is that something I could just do - like a symlink pip2->pip and not mess up everyone. I really don’t want to cause problems for “normal folk”.

2 Likes

even on pip it’s just a symlink. But I couldn’t remember if the symlink happens by default or if I did one for Gopigo OS.
If the symlink is by default I will revert today’s change.

3 Likes

In case anyone trying ROS on Ubuntu with a “16 tick”
GoPiGo3 needs to update (not install from scratch), Here is what worked:

=== UPDATE THAT WORKED
(!!! log in as pi !!!)

  • BACKUP ~/Dexter
    cp -r ~/Dexter ~/Dexter.old
    rm -rf ~/Dexter

  • Get Dexter/GoPiGo3 (from master)
    $ sudo git clone http://www.github.com/DexterInd/GoPiGo3.git /home/pi/Dexter/GoPiGo3

  • Get Dexter/DI_Sensors
    $ sudo git clone https://github.com/DexterInd/DI_Sensors.git /home/pi/Dexter/DI_Sensors

  • Setup RFR_Tools (for I2C_mutex)
    $ sudo git clone https://github.com/DexterInd/RFR_Tools.git /home/pi/Dexter/lib/Dexter/RFR_Tools
    $ cd /home/pi/Dexter/lib/Dexter//RFR_Tools/miscellaneous/
    $ sudo python3 setup.py install

  • SETUP GoPiGo3 Python3 egg
    $ cd /home/pi/Dexter/GoPiGo3/Software/Python
    $ sudo python3 setup.py install

    Installed /usr/local/lib/python3.8/dist-packages/gopigo3-1.3.0-py3.8.egg

  • Install DI_Sensors egg
    $ cd /home/pi/Dexter/DI_Sensors/Python
    $ sudo python3 setup.py install

  • Get serial number file
    $ wget -O .list_of_serial_numbers.pkl https://raw.githubusercontent.com/DexterInd/GoPiGo3/master/Install/list_of_serial_numbers.pkl

  • Check your python is using the installed package
    $ python3
    Python 3.8.10 (default, Jun 2 2021, 10:49:15)
    [GCC 9.4.0] on linux
    Type “help”, “copyright”, “credits” or “license” for more information.

import gopigo3
print(gopigo3.file)
/usr/local/lib/python3.8/dist-packages/gopigo3-1.3.0-py3.8.egg/gopigo3.py

  • Check what methods are in GoPiGo3 class:
    $ python3

import gopigo3
for f in dir(gopigo3.GoPiGo3):
… print(f)

look for
_check_serial_number_for_16_ticks

  • [OPTIONAL - Create default ~/Dexter/gpg3_config.json

gpg3=gopigo3.GoPiGo3()
(ctrl-D to exit)

more ~/Dexter/gpg3_config.json

  • [MY OPTION] - copy gpg_config.json
    cp ~/rosbot-on-gopigo3/configs/tilde-Dexter.gpg3_config.json ~/Dexter/gpg3_config.json
2 Likes

This is where I lost you - where did that rosbot-on-gopigo3 directory come from?

But looks like you continue to make great progress
/K

1 Like

That is the github root of ROSbot Dave.

$ more ~/Dexter/gpg3_config.json 
{"wheel-diameter": 66.77, "wheel-base-width": 106.14, "ticks": 16, "motor_gear_ratio": 120}

Notice my bot has 16 ticks - “Classic” GoPiGo3s have 6 ticks. Also my effective wheel diameter is pretty close to the default 66.5, but the wheel base is 11mm different than the default 117 mm.

Because ROSbot Dave has no desktop installed, I couldn’t use the DI desktop control panel app to determine the correct wheel diameter, wheel base, (and encoder ticks), and because the version of gopigo3.py at the time I was starting ROSbot did not automatically generate a gpg_config.json with the correct encoder ticks, I created the file manually, (and saved it off to “rosbot-on-gopigo3/configs/” so that it would not get lost when any update wiped out the ~/Dexter directories. The update management of any existing gpg_config.json file would be a merge nightmare for ModRobotics.)

BTW, the ros-gopigo3/gopigo3_node (and HandsOnROS) use a very hard coded wheel diameter and wheel base (as in Class Variable with no ROS parameter) which makes the published odometry and pose slightly wrong when a bot has an effective wheel diameter or effective wheel base different than the defaults. (The flat contact area of the tires, any motor shaft tilt, and radius variation all cause the actual contact points to change the momentary wheel base. The effective wheel base is the value that makes the pose angle and commanded angle best match the actual angle turned. The effective wheel diameter is the value that makes the odometry and commanded distance best match the actual distance traveled.)

The automatic creation of ~/Dexter/gpg_config.json with the (probably) correct encoder ticks and default wheel base and wheel diameter values, and the use of the file by gopigo3.py.GoPiGo3() class is in this latest update. I have written my ROS2 gopigo3_node to set the WIDTH and CIRCUMFERENCE “constants” in the class initialization instead of in the class definition to make the ROS2 node aware if the user has configured the wheel diameter or wheel base.

$ ros2 run ros2_gopigo3_node gopigo3_node
==================================
GoPiGo3 info:
Manufacturer    :  Dexter Industries
Board           :  GoPiGo3
Serial Number   :  56ECD67E5152415447202020FF192614
Hardware version:  3.x.x
Firmware version:  1.0.0

GoPiGo3 Configuration:
WHEEL_DIAMETER: 66.770 mm
WHEEL_BASE_WIDTH: 106.140 mm
ENCODER_TICKS_PER_ROTATION: 16 (per one motor revolution)
MOTOR_GEAR_RATIO: 120 (motor revolutions per wheel revolution)
MOTOR_TICKS_PER_DEGREE: 5.333333333333333 (of wheel rotation)
(Using default values or ~/Dexter/gpg3_config.json if present)


Odometry Precision: 0.11 mm
==================================
[INFO] [1626702553.544924216] [gopigo3_node]: ros2_gopigo3_node: created main loop callback at 1 Hz

That Odometry Precision on a “Classic GoPiGo3” works out to 0.29 mm. I have not determined if there is actually any accuracy difference.

I just ran ROSbot Dave approx 42 inches 1.067 meters, and the /odom reported 1.058 meters, so 8mm difference between reported and actual. Turning approximately 360 degrees by eye/hand response gave a reported heading change of -1 degree and visually it looks like it turned about 361 so perhaps 2 degree error. I’ll have to verify my gpg_config.json values.

p.s. A really pedantic developer would add a ROS2 arg “gpg3_config_file” and pass it to GoPiGo3(config_file_path=node.get_arg(“gpg3_config_file”)) or something like that but that will have to remain on the TODO list.

2 Likes

Actually that has to be wrong. The encoder ticks get converted to encoder “readings” so the precision of both classic and new GoPiGo3 bots is probably the same. I need to review the code again to see if GoPiGo3.get_motor_status encoder values are whole degree or half degree. I know that one of the APIs has a x2 in the chain.

2 Likes

This is very helpful. As mentioned on another post, I really do need to calibrate my robot.

Using the joystick for navigation I noticed it was pulling to the left. I did a quick test logging the encoder values . I forget which topic I ended up using, but it seemed to be reporting individual ticks counting up (and then counting down if going backwards).
/K

2 Likes

What joystick routines do you use?

In DexterOS / GoPiGo O/S the remote camera robot pulls sharply to the left on initial start and has a tendency to drift left (severely) when the joystick is centered.

Yes

  1. The robot was fully calibrated.
  2. The joystick was calibrated and centered.

I ended up reworking the motion routined , (elementary algebra and knowing precedence of operations Is Your Friend!), so that the bot’s initial velocity wasn’t something like “200” right off the starting block.

I also tweaked the calculations for direction to make “straight ahead” actually straight ahead.

1 Like

Great points - I should look at the joystick messages to make sure it’s actually calibrated properly. It seemed to be when I was testing it initially, but worth checking again.
/K

2 Likes