jharris1993
commented
1 month ago Have you confirmed this on Carl?
I noticed a similarly strange behavior with Charline - if I start a Python script in Thonny that initializes an instance of the robot, and it the program gets stuck for any reason; and if I either abandon the running instance, or reset the running instance within Thonny, the robot stops responding to attempts to create additional instances of itself. The only way to resolve this is a reboot.
I have not confirmed this on Charlie yet, but I don't recall anything like this in the past.
I do not know if this is a problem with a Thonny update or a problem with Charline, but it does have me puzzled.
May 17, 2024 8:11:43 PM slowrunner @.***>:
I do not expect a GoPiGo3 firmware "fix" for this issue - simply documenting the existence of the issue
While the GoPiGo3 API is open-source, available for us to understand to the level of our curiosity, the code that runs inside the “red board” has always required us to use black box testing for any insight.
The Raspberry Pi uses the GoPiGo3 API to send commands across an SPI bus to the red board, and interpret any returned result data. The GET_MOTOR_STATUS_LEFT, and GET_MOTOR_STATUS_RIGHT commands via the gopigo3.get_motor_status() API return:
Returns a list: flags -- 8-bits of bit-flags that indicate motor status: bit 0 -- LOW_VOLTAGE_FLOAT - The motors are automatically disabled because the battery voltage is too low bit 1 -- OVERLOADED - The motors aren't close to the target (applies to position control and dps speed control). power -- the raw PWM power in percent (-100 to 100) encoder -- The encoder position dps -- The current speed in Degrees Per Second So imagine my surprise when using the gopigo3.reset_motor_encoder() API (which sends an OFFSET_MOTOR_ENCODER SPI command) to see get_motor_status() return non-zero robot speeds, and in fact speeds far exceeding possible GoPiGo3 robot motion.
This is the result when resetting the encoders without moving the robot:
**** started moving [INFO] [1715963280.121958244] [odometer]: start heading -0.0329 rads [INFO] [1715963280.122452707] [odometer]: last heading -0.0329 rads [INFO] [1715963280.123078985] [odometer]: current heading -0.0329 rads [INFO] [1715963280.123697318] [odometer]: last_point - x: -0.1734 y: 0.0196 z: 0.0000 heading: -1.9 [INFO] [1715963280.124226837] [odometer]: current_point - x: -0.1734 y: 0.0196 z: 0.0000 heading: -1.9
<<<---- ROBOT IS NOT MOVING BUT REPORTS 2880 DPS or 1.6m/s EQUIVALENT VELOCITY --->>>
[INFO] [1715963280.125430411] [odometer]: start_point - x: -0.173 y: 0.020 z: 0.000 heading: -2 [INFO] [1715963280.218462322] [odometer]: *** stopped moving [INFO] [1715963280.218914730] [odometer]: start heading -0.0329 rads [INFO] [1715963280.219304433] [odometer]: last heading 0.0000 rads [INFO] [1715963280.219889507] [odometer]: current heading 0.0000 rads [INFO] [1715963280.220388767] [odometer]: start_point - x: -0.1734 y: 0.0196 z: 0.0000 heading: -1.9
[INFO] [1715963280.221521544] [odometer]: stop_point - x: 0.000 y: 0.000 z: 0.000 heading: 0 - moved: 0.175 meters in 0.1s * Dave has a maximum measured velocity of 450 DPI which is 0.25 meters per second. There is absolutely no way any GoPiGo3 robot could move at 1.6 m/s. I have seen reported speeds over 5000 DPI returned when resetting the encoders.
The difficulty for Dave comes in trying to correctly identify when Dave is moving. I thought I could use motor_status.dps but the GoPiGo3 redboard is reporting fictional motion when resetting the encoders - bummer.
— Reply to this email directly, view it on GitHub[https://github.com/DexterInd/GoPiGo3/issues/336], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AC36Q5ACBZ6U4VUV6S7QHSLZCY247AVCNFSM6AAAAABH4PZHIWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYDGMRTGIYTINI]. You are receiving this because you are subscribed to this thread. [Tracking image][https://github.com/notifications/beacon/AC36Q5GHHLAXXD5BOOLIGBTZCY247A5CNFSM6AAAAABH4PZHIWWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHISSEISE.gif]
slowrunner
I do not expect a GoPiGo3 firmware "fix" for this issue - simply documenting the existence of the issue
While the GoPiGo3 API is open-source, available for us to understand to the level of our curiosity, the code that runs inside the “red board” has always required us to use black box testing for any insight.
The Raspberry Pi uses the GoPiGo3 API to send commands across an SPI bus to the red board, and interpret any returned result data. The GET_MOTOR_STATUS_LEFT, and GET_MOTOR_STATUS_RIGHT commands via the gopigo3.get_motor_status() API return:
So imagine my surprise when using the gopigo3.reset_motor_encoder() API (which sends an OFFSET_MOTOR_ENCODER SPI command) to see get_motor_status() return non-zero robot speeds, and in fact speeds far exceeding possible GoPiGo3 robot motion.
This is the result when resetting the encoders without moving the robot:
Dave has a maximum measured velocity of 450 DPI which is 0.25 meters per second. There is absolutely no way any GoPiGo3 robot could move at 1.6 m/s. I have seen reported speeds over 5000 DPI returned when resetting the encoders.
The difficulty for Dave comes in trying to correctly identify when Dave is moving. I thought I could use motor_status.dps but the GoPiGo3 redboard is reporting fictional motion when resetting the encoders - bummer.