With so many people trying to install GoPiGo3 software on every new release of every variety of OS they see, it "would be nice if" there was a success test at the end of

update_gopigo3.sh

...
installresult=$(python3 -c "import gopigo3" 2>&1)
if [[ $installresult == *"ModuleNotFoundError"* ]]; then
   echo "GOPIGO3 SOFTWARE INSTALLATION FAILURE: "+$installresult
   echo "Suggest installing over Legacy Pi OS"
fi 

For reference - Attempting to install over the recently released 64-bit PiOS (2022-01-28) would trigger this warning

I know this is a real WIBNI

It would be so cool if class easysensors.Servo checked gpg_config.json for "servo-center" (in uS) and "servo-range" (in uS), and there existed a servo_calibration_gui program.

Then easysensor.Servo.reset_servo() could center the servo exactly, and
easysensor.Servo.rotate_servo(x) could be correct,
(and the smaller "servo-range" could prevent servo stall if need be)

On my ModRob Servo Kit, the teeth on the servo and distance sensor servo mount are not sufficiently fine to center the servo then push the mount onto the servo in the centered direction. I have to use ps.rotate_servo(SERVO_1_CENTER_DEG) with value 85 degrees (1424uS), and my "servo-range" is only 1348.

(I do apologize for taking your time with a wild WIBNI.)

Background:
Modular Robotics/Dexter Industries decided to depreciate the older 8-cell NiMH batteries in favor of a monolithic Li-Ion battery module and dedicated Li-Ion charger module.

• NiMH battery performance varies over wide limits based on the manufacturer and quality of the cells.  This made it difficult to use the robot for any period of time and/or predict the useful runtime for the robot.
• The exposed contacts on the 8-cell battery holder created the risk of short-circuits causing potential damage to the battery holder and/or the robot.

As a consequence of all this, (along with possibly other issues), the decision was made to depreciate the 8-cell battery package in favor of a better quality, and safer, Li-Ion battery pack and dedicated charger.

Issue:
The originally designed firmware for the GoPiGo robots, including the GoPiGo3, has built-in battery voltage points that trigger:

• The power LED to turn yellow warning the user that the battery power is getting low
• The power LED to turn red to indicate that the battery power is critically low, additionally disabling the motors.
• The GoPiGo board commands a formal operating system shutdown if the battery voltage drops below a certain critical threshold.

Unfortunately, these battery voltage points were calibrated based on the discharge curves for a "typical" collection of eight NiMH batteries.  Since the Li-Ion battery pack automatically cuts power at a voltage considerably higher that even the NiMH warning threshold, the GoPiGo3 does not have an opportunity to trigger a safety-shutdown.  In fact, it does not even reach the "low battery - yellow power LED" warning stage before automatically cutting power.

It is an established fact that un-commanded and spontaneous shutdowns of a system like Raspbian/Linux can seriously corrupt the media and it is firmly established, (and documented on the MR/DI GoPiGo site), that a controlled shutdown is necessary to avoid corruption of the media.

Request/Proposed Solution:
The calibration constants for the battery thresholds should be changed to accommodate the new discharge curve of the new Li-Ion batteries.

• This could be hard-coded into a firmware update
  -- and/or --
• Both sets of constants could be supported in firmware with a corresponding setting in the calibration routine to select which set to use - defaulting to the Li-Ion set.

The documentation of the DistanceSensor states that the minimum and maximum range is 5mm and 8000mm (8m) respectively.

The highest readings that I get with the easy_Distance_Sensor.py example are 3m (3000mm).

Which are the correct ranges for the DistanceSensor? Does the sensor need to be configured to allow higher ranges?

Do you want to change the link to gopigo.io?

Actually, I like the old link, but it might not be consistent with the mandates from The Borg's marketing gods. (wink!)

My ROS2 GoPiGo3 is running well, but needs the latest gopigo3.py with the encoder ticks handling, so I tried:
https://github.com/DexterInd/GoPiGo3/tree/master/Install#subsequent-updates
but fails with (full console log below):
Executable "pip2" couldn't be found. Error occurred with RFR_Tools installation.

I understand my case is unusual - sorry to be a bother.

DETAILS OF MY SYSTEM

OS: Ubuntu 20.04.2 LTS 64-bit Server
Kernal: Linux ROSbot 5.4.0-1036-raspi #39-Ubuntu SMP PREEMPT Wed May 12 17:37:51 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
Python3: Python 3.8.10
Python2: Python 2.7.18 - "python2 --version"
PIP/PIP3:

pi@ROSbot:~$ pip --version
pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)
pi@ROSbot:~$ pip3 --version
pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

NO PIP2:

pi@ROSbot:~$ pip2

Command 'pip2' not found, did you mean:

  command 'pipx' from deb pipx (0.12.3.1-2ubuntu1)
  command 'pip3' from deb python3-pip (20.0.2-5ubuntu1.5)
  command 'nip2' from deb nip2 (8.7.0-1)
  command 'pip' from deb python3-pip (20.0.2-5ubuntu1.5)

GoPiGo3: (16-tick model)

GoPiGo3 info:
Manufacturer    :  Dexter Industries
Board           :  GoPiGo3
Serial Number   :  56ECD67E5152415447202020FF192614
Hardware version:  3.x.x
Firmware version:  1.0.0

Tried with bypass rfrtools, and then full update minus gui:

FAILED: Update Python package (only)

pi@ROSbot:~$ curl -kL dexterindustries.com/update_gopigo3| bash -s -- --bypass-rfrtools --no-dependencies


  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   251  100   251    0     0   1394      0 --:--:-- --:--:-- --:--:--  1394
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 12113  100 12113    0     0  11092      0  0:00:01  0:00:01 --:--:-- 11092
  _____            _                                
 |  __ \          | |                               
 | |  | | _____  _| |_ ___ _ __                     
 | |  | |/ _ \ \/ / __/ _ \ '__|                    
 | |__| |  __/>  <| ||  __/ |                       
 |_____/ \___/_/\_\\__\___|_|          _            
 |_   _|         | |         | |      (_)           
   | |  _ __   __| |_   _ ___| |_ _ __ _  ___  ___  
   | | | '_ \ / _\ | | | / __| __| '__| |/ _ \/ __| 
  _| |_| | | | (_| | |_| \__ \ |_| |  | |  __/\__ \ 
 |_____|_| |_|\__,_|\__,_|___/\__|_|  |_|\___||___/ 
                                                    
                                                    
   ____       ____  _  ____      _____ 
  / ___| ___ |  _ \(_)/ ___| ___|___ / 
 | |  _ / _ \| |_) | | |  _ / _ \ |_ \ 
 | |_| | (_) |  __/| | |_| | (_) |__) |
  \____|\___/|_|   |_|\____|\___/____/ 
                                       
Welcome to GoPiGo3 Installer.
Updating GoPiGo3 for master branch with the following options:
  --no-dependencies=true
  --no-update-aptget=false
  --bypass-rfrtools=true
  --bypass-python-rfrtools=false
  --bypass-gui-installation=false
  --user-local=false
  --env-local=false
  --system-wide=true
Using "master" branch
Options used for RFR_Tools script: "--system-wide master --use-python3-exe-too --update-aptget --install-python-package --install-gui"
Executable "pip2" couldn't be found. Error occurred with RFR_Tools installation.

FAILED: UPDATE w/o GUI

$ curl -kL dexterindustries.com/update_gopigo3 | bash -s -- --bypass-gui-installation
pi@ROSbot:~$ curl -kL dexterindustries.com/update_gopigo3 | bash -s -- --bypass-gui-installation
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   251  100   251    0     0   1651      0 --:--:-- --:--:-- --:--:--  1651
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 12113  100 12113    0     0  17529      0 --:--:-- --:--:-- --:--:-- 17529
  _____            _                                
 |  __ \          | |                               
 | |  | | _____  _| |_ ___ _ __                     
 | |  | |/ _ \ \/ / __/ _ \ '__|                    
 | |__| |  __/>  <| ||  __/ |                       
 |_____/ \___/_/\_\\__\___|_|          _            
 |_   _|         | |         | |      (_)           
   | |  _ __   __| |_   _ ___| |_ _ __ _  ___  ___  
   | | | '_ \ / _\ | | | / __| __| '__| |/ _ \/ __| 
  _| |_| | | | (_| | |_| \__ \ |_| |  | |  __/\__ \ 
 |_____|_| |_|\__,_|\__,_|___/\__|_|  |_|\___||___/ 
                                                    
                                                    
   ____       ____  _  ____      _____ 
  / ___| ___ |  _ \(_)/ ___| ___|___ / 
 | |  _ / _ \| |_) | | |  _ / _ \ |_ \ 
 | |_| | (_) |  __/| | |_| | (_) |__) |
  \____|\___/|_|   |_|\____|\___/____/ 
                                       
Welcome to GoPiGo3 Installer.
Updating GoPiGo3 for master branch with the following options:
  --no-dependencies=false
  --no-update-aptget=false
  --bypass-rfrtools=false
  --bypass-python-rfrtools=false
  --bypass-gui-installation=true
  --user-local=false
  --env-local=false
  --system-wide=true
Using "master" branch
Options used for RFR_Tools script: "--system-wide master --use-python3-exe-too --update-aptget --install-deb-deps --install-python-package"
Installing RFR_Tools. This might take a while..
Updating RFR_Tools for master branch with the following options:
  --install-python-package=true
  --system-wide=true
  --user-local=false
  --env-local=false
  --use-python3-exe-too=true
  --update-aptget=true
  --install-deb-deps=true
  --install-gui=false
Updating debian repository within RFR_Tools 
RFR_Tools: Couldn't add Nodejs repo to source because it's not available for "focal" distribution
Hit:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease
Get:2 http://packages.ros.org/ros2/ubuntu focal InRelease [4670 B]
Get:3 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease [114 kB]
Get:4 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease [101 kB]
Get:5 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease [114 kB]
Get:6 http://packages.ros.org/ros2/ubuntu focal/main arm64 Packages [756 kB]
Get:7 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 Packages [822 kB]
Get:8 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 c-n-f Metadata [13.4 kB]
Get:9 http://ports.ubuntu.com/ubuntu-ports focal-updates/universe arm64 Packages [791 kB]
Get:10 http://ports.ubuntu.com/ubuntu-ports focal-updates/universe Translation-en [176 kB]
Get:11 http://ports.ubuntu.com/ubuntu-ports focal-updates/universe arm64 c-n-f Metadata [16.6 kB]
Get:12 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 Packages [506 kB]
Get:13 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 c-n-f Metadata [7700 B]
Get:14 http://ports.ubuntu.com/ubuntu-ports focal-security/universe arm64 Packages [582 kB]
Get:15 http://ports.ubuntu.com/ubuntu-ports focal-security/universe Translation-en [97.2 kB]
Get:16 http://ports.ubuntu.com/ubuntu-ports focal-security/universe arm64 c-n-f Metadata [9964 B]
Fetched 4110 kB in 4s (1162 kB/s)                                 
Reading package lists... Done
Installing debian dependencies within RFR_Tools. This might take a while..
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'python-dev-is-python2' instead of 'python-dev'
Package python-pip is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  python3-pip

E: Package 'python-pip' has no installation candidate
Installing script_tools. This might take a while..
Done installing script_tools
Removing "auto_detect_rpi" to make space for the new one
Removing /usr/local/lib/python3.8/dist-packages/Dexter_AutoDetection_and_I2C_Mutex-0.0.0-py3.8.egg egg
Removing /usr/local/lib/python3.8/dist-packages/Dexter_AutoDetection_and_I2C_Mutex-0.0.0-py3.8.egg egg
Installing python package for RFR_Tools 
Traceback (most recent call last):
  File "setup.py", line 18, in <module>
    import setuptools
ImportError: No module named setuptools
Done installing RFR_Tools
Executable "pip2" couldn't be found. Error occurred with RFR_Tools installation.

HOW RFR_TOOLS WAS ORIGINALLY INSTALLED (May 31,2021)

=== R4R_Tools (for I2C_mutex)
$ sudo git clone https://github.com/DexterInd/RFR_Tools.git /home/pi/Dexter/lib/Dexter/RFR_Tools
$ sudo apt-get install libffi-dev
$ cd /home/pi/Dexter/lib/Dexter//RFR_Tools/miscellaneous/
$ sudo python3 setup.py install


Check that the mutex stuff will be available:

$ unzip -l /usr/local/lib/python3.8/dist-packages/Dexter_AutoDetection_and_I2C_Mutex-0.0.0-py3.8.egg
Archive:  /usr/local/lib/python3.8/dist-packages/Dexter_AutoDetection_and_I2C_Mutex-0.0.0-py3.8.egg
  Length      Date    Time    Name
---------  ---------- -----   ----
     3154  2021-05-31 15:48   I2C_mutex.py
     9445  2021-05-31 15:48   auto_detect_robot.py
     6211  2021-05-31 15:48   auto_detect_rpi.py
    23756  2021-05-31 15:48   di_i2c.py
     1700  2021-05-31 15:48   di_mutex.py
      303  2021-05-31 15:51   EGG-INFO/PKG-INFO
      372  2021-05-31 15:51   EGG-INFO/SOURCES.txt
        1  2021-05-31 15:51   EGG-INFO/dependency_links.txt
       46  2021-05-31 15:51   EGG-INFO/requires.txt
       60  2021-05-31 15:51   EGG-INFO/top_level.txt
        1  2021-05-31 15:51   EGG-INFO/zip-safe
     2812  2021-05-31 15:51   __pycache__/I2C_mutex.cpython-38.pyc
     6565  2021-05-31 15:51   __pycache__/auto_detect_robot.cpython-38.pyc
     4592  2021-05-31 15:51   __pycache__/auto_detect_rpi.cpython-38.pyc
    14282  2021-05-31 15:51   __pycache__/di_i2c.cpython-38.pyc
     1652  2021-05-31 15:51   __pycache__/di_mutex.cpython-38.pyc
---------                     -------
    74952                     16 files

HOW GoPiGo3 and DI_Sensors WERE ORIGINALLY INSTALLED

==== SETUP GoPiGo3 and DI_Sensors Python3 eggs 
$ cd /home/pi/Dexter/GoPiGo3/Software/Python
$ sudo python3 setup.py install
$ cd /home/pi/Dexter/DI_Sensors/Python
$ sudo python3 setup.py install

I can see some changes in the repository related to RPi 4. But I am unable to find a statement that would confirm or deny the support for RPi 4. I have also looked at Dexter Industries and done the old Googling trick.

Has this been fully tested?

The update_gopigo3 install script installs TTS and assumes the base OS defaults to sound output to the headphone jack.

This is not the case with the new Legacy PiOS, which defaults to output to HDMI (and also defaults to pulseaudio). Therefore when installing GoPiGo3 and DI_Sensors software via curl to bash, no sounds will be heard through a speaker attached to the headphone jack.

What I have found to work:

$ echo "defaults.pcm.card 1" > home/pi/asoundrc; echo "defaults.ctl.card 1" >> /home/pi/asoundrc
$ sudo apt purge pulseaudio
$ sudo apt autoremove
$ sudo reboot

Should the GoPiGo3.cpp::reset_all() method also power off the servos?

// Turn servo power off
GPG.set_servo(SERVO_1,0);
GPG.set_servo(SERVO_2,0);

@marcellobarile ,
it seems NodeJS got hurt when we moved the firmware number to 1.0.0
Now it fails the check.
I know where the firmware number is set, but before I go in and just change it, could you tell me if there are side effects?

Biggest change in 1.0.0 is that it supports up to 32 bytes per I2C transaction, rather than 16. What are the implications of that on NodeJS?

GoPiGo3/Software/C/GoPiGo3.cpp generates compile warnings:

 make
[ 10%] Building CXX object CMakeFiles/gopigo3.dir/GoPiGo3.cpp.o
/home/ubuntu/systests/cpp/GoPiGo3.cpp: In member function ‘int GoPiGo3::detect(bool)’:
/home/ubuntu/systests/cpp/GoPiGo3.cpp:143:106: warning: ‘%s’ directive writing up to 20 bytes into a region of size 18 [-Wformat-overflow=]
  143 |       sprintf(ErrorStr, "detect error: GoPiGo3 firmware needs to be version %sx but is currently version %s", FIRMWARE_VERSION_REQUIRED, str);
      |                                                                                                          ^~                              ~~~
/home/ubuntu/systests/cpp/GoPiGo3.cpp:143:14: note: ‘sprintf’ output between 83 and 103 bytes into a destination of size 100
  143 |       sprintf(ErrorStr, "detect error: GoPiGo3 firmware needs to be version %sx but is currently version %s", FIRMWARE_VERSION_REQUIRED, str);
      |       ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ubuntu/systests/cpp/GoPiGo3.cpp: In member function ‘int GoPiGo3::get_version_hardware(char*)’:
/home/ubuntu/systests/cpp/GoPiGo3.cpp:167:1: warning: control reaches end of non-void function [-Wreturn-type]
  167 | }
      | ^

using GoPiGo3/Software/C/CMakeList.txt to build Examples

The addition of importing easy_light_color_sensor to easygopigo3.py causes an import error:

easy_light_color_sensor.py:198 Invalid Syntax

on Raspbian For Robots Stretch which uses Python 3.5.

The easy_light_color_sensor.py calibrate function uses f-strings which are only supported in Python 3.6 and beyond.

Issue filed against that file:
DexterInd/DI_Sensors#89

I tried updating the firmware of my GoPiGo3 on Raspbian Jessie and got this error:
pi@raspberrypi:~/GoPiGo3/Firmware $ sudo bash gopigo3_flash_firmware.sh Updating the GoPiGo3 Firmware with '/home/pi/GoPiGo3/Firmware/GoPiGo3_Firmware_0.3.2.bin'. sudo: openocd: command not found

I also looked at the scripts in the openocd folder and they refer to the Dexter/ folder which obviously doesn't exist on raspbain.

easysensors.UltrasonicSensor.read_mm() prints three debug "raw xxx" readings each time it is called.

Please comment out or add verbose=False default parameter.

The self doc on the EasyGoPiGo3.steer() method states:

        Each motor is assigned a percentage of the current speed value. 
..
        :param int left_percent: Percentage of current speed value that gets applied to left motor. 
..
        :param int right_percent: Percentage of current speed value that gets applied to right motor. 
..
        For setting the motor speed, use :py:meth:`~easygopigo3.EasyGoPiGo3.set_speed`.
        Default ``speed`` is set to **300** - see :py:meth:`~easygopigo3.EasyGoPiGo3.__init__`.
        .. important::

but coded as (and nearly impossible to use):

        self.set_motor_dps(self.MOTOR_LEFT, self.NO_LIMIT_SPEED * left_percent / 100)
        self.set_motor_dps(self.MOTOR_RIGHT, self.NO_LIMIT_SPEED * right_percent / 100)

Typo in LED tutorial.

Ignore me.

In the gopigo3 library, the range of servo motions is given with 0 to 16666 us (microseconds):

In the easygopigo3 library, the servo limits are given with 575 to 24250us:

Which are the true limits for setting the servo position?
Are there different kind of servos? If not, the documentation needs to be updated to contain the true valid ranges for servo motion.

The C++ GoPiGo3 API does not support GoPiGo3 robots that have 16 tick encoders.

Additionally:

• The GoPiGo3 instance variables associated with the gpg3_config.json file are not declared and initialized
• An example driving the GoPiGo3 via keyboard control would be helpful

Created pull request #325 for this issue

When I try to compile the leds.cpp program using sudo g++ -o leds leds.cpp ../GoPiGo3.cpp -I..
I get the following errors:
/tmp/cc54Rdk4.o:(.data+0x0): multiple definition of spi_file_handle' /tmp/ccr13cUi.o:(.data+0x0): first defined here /tmp/cc54Rdk4.o:(.bss+0x0): multiple definition of spi_xfer_struct'
/tmp/ccr13cUi.o:(.bss+0x0): first defined here
/tmp/cc54Rdk4.o:(.bss+0x20): multiple definition of spi_array_out' /tmp/ccr13cUi.o:(.bss+0x20): first defined here /tmp/cc54Rdk4.o:(.bss+0x48): multiple definition of spi_array_in'
/tmp/ccr13cUi.o:(.bss+0x48): first defined here
/tmp/cc54Rdk4.o: In function spi_setup()': GoPiGo3.cpp:(.text+0x0): multiple definition of spi_setup()'
/tmp/ccr13cUi.o:leds.cpp:(.text+0x0): first defined here
/tmp/cc54Rdk4.o: In function spi_transfer_array(unsigned char, unsigned char*, unsigned char*)': GoPiGo3.cpp:(.text+0x84): multiple definition of spi_transfer_array(unsigned char, unsigned char*, unsigned char*)'
/tmp/ccr13cUi.o:leds.cpp:(.text+0x84): first defined here
/tmp/cc54Rdk4.o: In function fatal_error(char const*)': GoPiGo3.cpp:(.text+0x124): multiple definition of fatal_error(char const*)'
/tmp/ccr13cUi.o:leds.cpp:(.text+0x124): first defined here
/tmp/cc54Rdk4.o:(.bss+0x70): multiple definition of _time' /tmp/ccr13cUi.o:(.bss+0x70): first defined here /tmp/cc54Rdk4.o: In function get_time()':
GoPiGo3.cpp:(.text+0x174): multiple definition of `get_time()'
/tmp/ccr13cUi.o:leds.cpp:(.text+0x174): first defined here
collect2: error: ld returned 1 exit status

Manufacturer : Dexter Industries
Board : GoPiGo3
Serial Number : 0D9DAA74514E3437324A2020FF041C14
Hardware version: 3.x.x
Firmware version: 1.0.0
Battery voltage : 4.12
5v voltage : 4.805

g++ version:
g++ (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516

I also tried putting the leds.cpp, GoPiGo3.cpp and GoPiGo3.h in one folder and compile it with the following command: sudo g++ -o leds leds.cpp
Then I get these errors:
/tmp/cclfl8Fd.o: In function main': leds.cpp:(.text+0x1e8): undefined reference to GoPiGo3::detect(bool)'
leds.cpp:(.text+0x238): undefined reference to GoPiGo3::set_led(unsigned char, unsigned char, unsigned char, unsigned char)' leds.cpp:(.text+0x258): undefined reference to GoPiGo3::set_led(unsigned char, unsigned char, unsigned char, unsigned char)'
leds.cpp:(.text+0x274): undefined reference to GoPiGo3::set_led(unsigned char, unsigned char, unsigned char, unsigned char)' leds.cpp:(.text+0x290): undefined reference to GoPiGo3::set_led(unsigned char, unsigned char, unsigned char, unsigned char)'
/tmp/cclfl8Fd.o: In function exit_signal_handler(int)': leds.cpp:(.text+0x374): undefined reference to GoPiGo3::reset_all()'
/tmp/cclfl8Fd.o: In function __static_initialization_and_destruction_0(int, int)': leds.cpp:(.text+0x3c4): undefined reference to GoPiGo3::GoPiGo3()'
collect2: error: ld returned 1 exit status

What am I doing wrong?

Currently the encoder and speed values are rounded to integers which means that there is a loss in precision for get_motor_status:

The use for this rounding is probably only for resetting the encoders via offset_motor_encoder(MOTOR_RIGHT, get_motor_encoder(MOTOR_RIGHT)). However, this rounding can be done manually and get_motor_status and get_motor_encoder should provide values as floating points.

In addition to this, there should be a more direct way for setting the encoders to 0, without calculations that depend on other values. This resetting should then also be done in reset_all, since old encoder values become meaningless when starting a new program.

test_heavy_mutex_2.py has an errant tab:

pi@Carl:~/Dexter/GoPiGo3/Software/Python/tests $ python3 test_heavy_mutex_2.py 
  File "test_heavy_mutex_2.py", line 20
    mutex.release()
                  ^
TabError: inconsistent use of tabs and spaces in indentation

Note: Sorry, I have not learned how to do pull request. This one is really trivial to fix, I should have done it.

The file ../RemoteCamera/Robot/install_startup.sh enables the camerarobot.service

It would be nice to have a file stop_camerarobot.sh that stops it for the session, and perhaps a file uninstall_startup.sh that disables it?

Don't know if this works for stop_camerarobot.sh:

#!/bin/bash

# stop the GoPiGo3 camerarobot.service
sudo systemctl --runtime stop camerarobot

At the moment the following 3 methods of the EasyGoPiGo3 class are non-blocking by default.

• drive_cm
• drive_inches
• drive_degrees

Here's a screenshot of what I was referring to.

They should be set to blocking mode as otherwise, novice users will get easily confused.
Let the more advanced users figure this thing out, right?

On the following class' constructor, there's no mentioning of the exception that can be thrown.
It's about the IOError that isn't documented.

Hi there:

Is it feasible or does anybody has experience running the GoPiGo3 with a non-Debian Linux distro like in $SUBJECT?

Background: We have a small fleet of GoPiGo3's (around 15) we used to run event workshops for our (Red Hat, that is) developer line of products. Until, well, Covid came along. So it's been 2.5 years and we would like to revive this, but would like to brush up our game:

• We'd like to use the robots more as "edge devices", again to show our product range in this area
• We plan to run some ML workloads (think road/line following) directly on the robots
• Thinking about running MicroShift (a IoT-device version of our Container Platform) on the small guys

All of this requires one of the above distros running and probably a raspi 4 and something like a Google Coral TPU stick.

Before I start digging into the setup scripts and hitting roadblocks any help would be appreciated!

A student with a Grove Ultrasonic Ranger "distance sensor" attempted to run Dexter/GoPiGo3/Projects/ObjectAvoidanceRobot/object_avoidance_robot.py program.

The program is designed to catch IOError to mean "GoPiGo3 robot not detected or DistanceSensor not installed", but the easygopigo3.EasyGoPiGo3().init_distance_sensor() eats the distance sensor missing exception, returns "None" for the distance sensor instantiation, and continues on as planned for the normal flow.

This later causes the object_avoidance_robot.py program to error stating "NoneType has no read_mm() attribute".

object_avoidance_robot.py needs to include something like:

...
    gopigo3 = EasyGoPiGo3()
    distance_sensor = gopigo3.init_distance_sensor()
    if (distance_sensor == None):              # <--- NEW ERROR CASE
        print("I2C connected Time Of Flight Distance Sensor not detected")
        sys.exit(1)

When an update_gopigo3.sh install to Bullseye fails, the “check_if_firmware_upgrade_needed” will fail instantiating a GoPiGo3 because the setuptools was not present to install the gopigo3 egg files. When that instantiation fails because of the missing modules, the check executes the exception clause which improperly states “Firmware Upgrade Is Needed”

try:
        g = gopigo3.GoPiGo3()
        current_firmware = g.get_version_firmware()
        if current_firmware == available_firmware:
                print(f"\nThe GoPiGo is already running the latest firmare: {current_firmware}. \nAn upgrade is not needed at this time.\n")
                exit(1)
except Exception as e:
        print(e)
        print("Firmware upgrade is needed")
        exit(0)

While the end of the installation does give an error, many folks do not seem to read it.

GOPIGO3 SOFTWARE INSTALLATION FAILURE: +Traceback (most recent call last): File "<string>", line 1, in <module> ModuleNotFoundError: No module named 'gopigo3'
Suggest installing over Legacy Pi OS (Buster).

========
Suggestion for check_if_firmware_update_is_needed.py
move the firmware upgrade needed notice to an else clause:

...
 if current_firmware == available_firmware:
                print(f"\nThe GoPiGo is already running the latest firmware: {current_firmware}. \nAn upgrade is not needed at this time.\n")
                exit(1)
 else:
        # print("Firmware upgrade is needed")
        print(f"\nThe GoPiGo3 is running firmware: {current_firmware}.  An upgrade to {available_firmware} is needed.\n")
        exit(0)

except Exception as e:
        print(e)
        exit(0)

The current edit boxes for Wheel Diameter and Wheel Base are both (60, 40) which does not display a user determined Wheel Base value having two digit precision (e.g. 114.05 the last digit will be cut off)

Fix is to expand the Wheel Base edit box:

        # self.wheel_base_input = wx.TextCtrl(self, value=str(wheel_base_width), size=(60, 40))
        self.wheel_base_input = wx.TextCtrl(self, value=str(wheel_base_width), size=(70, 40))

When using the line follower blocks, "line follower (red) sees" and "line follower (black) sees", the equivalent python code has a syntax error, causing the code to fail to run. If instead one checks if the line position is equal to a string using the "line_follower values" and the equals and text blocks, the issue is not found. I believe this occurs because, when using the "line follower (red) sees" and "line follower (black) sees" code blocks, the colon that ends the if statement is on the next line. I have included images of both functioning bloxter code and non-functioning code (where the python equivalents are almost identical, except the colon as noted previously).

Hi, I am trying to test in Matlab some controllers for Mobile Robots, I am using a sockets communication between Python and Matlab, but there is a problem when I try to compute the odometry in Matlab, I was wondering if it is possible to me modify the source code in order to make the odometry and provide the position of the robot in centimeters o meters, and its orientation, What steps Should I follow?.
Thanks

The LED's should reset to original values when it detects a reboot on the Raspberry Pi. When rebooting, it held the same values until I disabled all power and rebooted.

Placeholder Issue: I am working on a limited C++ version of the Python EasyGoPiGo3.py

Focus:

• Implement most useful motion and encoder methods of EasyGoPiGo3.py

Limitations:

• no "plug-in" sensor methods
• May not Implement simplified LED methods

class EasyGoPiGo3 derived from GoPiGo3 class

TODO Methods:
set_speed(speed_in_DPS=150)
get_speed()
forward(): drive forward - use set_speed() or default: 150 DPS
backward(): drive backward
stop():
drive_cm(dist_cm, blocking=true)
drive_inches(dist_inches, blocking=true)
right() : pivot cw around right wheel
left(): pivot ccw around left wheel
spin_right(): spin in place clockwise
spin_left(): spin in place counter-clockwise
target_reached(left_tgt_degrees, right_tgt_degrees): use to detect when to stop forward(), backward(), right(), left(), spin_right(), spin_left()
and for non-blocking drive_cm() or drive_inches()
reset_encoders(): resets both encoders to 0
read_encoders(out:left, out:right, in:units=CM/INCH/DEGREE)
read_encoders_average(out:ave, in:units=CM/INCH/DEGREE)
turn_degrees(in:deg, blocking=true): left: negative degrees

Not Planned For Initial Version:
blinker_on(id:{LEFT,RIGHT}
set_left_eye_color(R,G,B)
set_right_eye_color(R,G,B)
set_eye_color(R,G,B)
open_left_eye()
open_right_eye()
open_eyes()
close_left_eye()
close_right_eye()
close_eyes()

The easygopigo3.EasyGoPiGo3.close_eyes() command only closes one of the eyes, on GoPiGo3 board. I've tried reboots, and firmware re-flashes, and the issue persists.

In order to install GoPiGo3 drivers/api to ubuntu the pi user and /home/pi directories are needed/used, and the resulting gopigo3.py from the install_on_ubuntu branch load_robot_constants() does not contain the code (existent in master branch) to check the serial file and create /home/pi/Dexter/gpg3_config.json.

This code really needs to exist, even if the user desires to use a custom config file path.

When the distance sensor is not installed and we try to import the easygopigo3 module from another directory other than the source directory (the ~/Dexter/GoPiGo3/Software/Python folder) it fails saying the No module named mock_package.

This error will appear if someone wants to write a script in any part of the file system (other than the source directory) which uses the easygopigo3 while the distance sensor isn't installed.

I was trying to add OpenCV to the RemoteCameraRobot streaming example (https://github.com/DexterInd/GoPiGo3/tree/master/Projects/RemoteCameraRobot).

The idea for a start is to draw a simple square on top of the video. I understand this can be done either in the class StreamingOutput(object) or in the class StreamingHandler(server.BaseHTTPRequestHandler), and the code for the rectangle will look like that: cv2.rectangle(cv2.imread(self.buffer), start_point, end_point, color, thickness)

However when I try to do so the stream breaks and I only see the blank screen the the waiting for stream message.

Any idea on how to make it work?

The December 2022 update to the GoPiGo3 C++ API implemented searching and using the 16-tick serial pkl file when creating the /home/pi/Dexter/gpg3_config.json file, but did not make modifications to the set_motor_ and get_motor_ methods to use the ENCODER_TICKS_PER_REVOLUTION and the resulting MOTOR_TICKS_PER_DEGREE.

Ref: Pull request #305

Issue:
Once the motors have been energized by the methods in the easygopigo3 library, they never get turned off.  This causes a continuous power drain and potential stress to the components involved.

Why this is an issue:

1. Battery power is a limited resource and allowing continuous motor current to run will cause them to be depleted more quickly.
   • Though I have not measured this with precision, my experience with the New Remote Camera Robot project indicates that, absent motor power, the battery's run time is in the tens or twenties of hours.  After the motors have been energized and stopped, the run time is measured in units of hours.
2. Allowing current to continuously run thorough the motors/drivers stresses both the motors and their driving circuitry and may shorten their useful life.
   • Note that the servos already have a disabling method that can be used to turn off power to the servos when not in use.

Proposed solution:
Within the stop() method, follow the set_motor_dps() command that stops robot motion with a set_motor_power() command that turns the motors themselves off.  This makes removal of power automatic and prevents inadvertent additional load on the power source.

Alternate solution:
Create a motor disabling method corresponding to the servo[n].disable_servo() methods that already exist for the servos.

• IMHO, it is better to make the motor disable command a part of the stop() method as that conserves power automatically and is consistent with the user's expectation that the motors not receive power when they're not being used.
• In the event that the programmer's use-case requires finer grained control over stopping and releasing the motors, the existing set_motor_dps() and set_motor_power() methods can be used.

Caveat:
If you remove power from the robot motors too quickly after stopping them, the robot's inertia may try to keep the motors moving if the robot is heavy or moving quicly.  The solution to this is to provide a slight, (0.25 - 0.50 second), pause between the set_motor_dps() command that stops the robot and the set_motor_power() command to give the robot time to come to a complete stop.

Ref:  The following documents:

1. GoPiGo3/Hardware/GoPiGo3 v3.1.3.pdf
   https://github.com/DexterInd/GoPiGo3/blob/master/Hardware/GoPiGo3%20v3.1.3.pdf
2. GoPiGo3/Hardware/GoPiGo3 v3.2.0.pdf
   https://github.com/DexterInd/GoPiGo3/blob/master/Hardware/GoPiGo3%20v3.2.0.pdf

Issue 1:
Within the section marked "Power", the inductor for the 5v buck regulator is missing both the component designation and its part number.

Issue 2:
Within the section marked "Power", the two soft-fuses, (F1 and F2), are also missing part numbers.

Issue 3:
Within the section marked "SWD, UART, SPI", the level-shifter IC is also missing its component designation and part number.

Nice To Have:  (but not mandatory)

• A Bill Of Materials, (BOM), cross referenced to the component designations, would be a convenient source of information about the components.
• A separate folder with datasheets for all major components, (aside from the common resistors and capacitors), would be convenient too.
  • I would be willing to help provide and upload these documents as I have already collected a number of them.
  • I have added this to my repo, but it shows up in the wrong pull request.

Justification:

• The inclusion of a component's designation on the schematic allows the component to be referenced and identified outside the confines of the schematic itself.
• The inclusion of a component's commercial part number allows the component to be cross-referenced and the component data-sheet to be obtained so that its characteristics can be understood and - if necessary - suitable replacement and/or upgrade components can be obtained.

Ref:

Despite this comment: "You can install the GoPiGo3 on your own operating system with the following commands in the command line:" that command line fails immediately because of a command "feedback" that is not found.

Received from GitHub Security Alerts

suggest requirements.txt:

werkzeug==0.15.3

I tested RemoteCameraObject runs successfully with werkzeug==0.15.3 and Flask==1.1.1.

IMHO, a serious limitation of the current "calibration" routine is that, though excellent, (thank you!), it is too limited as there are a number of things that can, and should, be included.  For example:

• Servo calibration constants. (Issue #296)
• Calibration "tweaks" for the motors so that straight-ahead travel is actually straight ahead.
• The ability to set the "warning/power-off" voltage levels to accommodate differing battery chemistries.
  • This could be implemented as a radio-button selector for Li-Ion/NiMH with the option to manually select the voltage(s). 
  • Note that this is actually worthy of its own issue as the hard-coded warning thresholds were designed for the NiMH battery pack and are totally unsuitable for the new LI-Ion batteries as the batteries die hard before the warning threshold is reached and the GoPiGo board "safety shuts down" the robot.  (See issue #311)

The basic idea is to design the calibration utility so that it can be expanded relatively easily with additional tabs for additional functionality that may be added in the future.

the latest commit is causing the easygopigo3 to not work.
" File "build/bdist.linux-armv7l/egg/easygopigo3.py", line 2251, in
ImportError: No module named mock_package"

this line here: references "mock_package" which is not defined elsewhere
https://github.com/DexterInd/GoPiGo3/blame/master/Software/Python/easygopigo3.py#L2251