GoPiGo3 Theory Of Operation - drive_cm()?

,
1

I think I understand the basic GoPiGo3 theory of operation:

Raspberry Pi is a non-RT OS that runs “Robot Brain” code, and

  • communicates via SPI (at 500kbit max) using
    set and polled-get messages with

GoPiGo3 ATSAMC20J 32-bit MicroController that is controlling and reading
GoPiGo3 sensors (

  • 2x “Grove” A or D,
  • 2x I2C,
  • 2x 720 count/rev encoders)

and GoPiGo3 actuators (

  • 2xMotors,
  • 2xServos,
  • 2x red LED,
  • WiFi Multi-color LED,
  • Power Multi-color LED,
  • 2x “eyes” Multi-color LEDs)

Using a microcontroller for time critical operations frees the brain to think deeper without FOMO and allows more precise control loops between actuators and sensor feedback, and can increase safety.

One example of this architecture allowing precise control would be:

  1. setting one or more wheel movement limits,
  2. commanding “run until [any | multiple] limit is reached”,
  3. provide either interrupt or polled status - (GoPiGo3 provides polled status)

Examples of allowing increased safety, would be:

  1. setting one or more safe operation limits such as
    – current draw to detect stalled motor (not available on GoPiGo3)
    – current draw to detect shorted output pin (not available on GoPiGo3)
    – low battery voltage (GoPiGo3 provides polled status value)
  2. stopping or blocking related operations such as:
    – stop motors if current spikes after initial rise (not intrinsic on GoPiGo3)
    – interrupt brain with “Low Voltage - shutdown now to prevent damage”
    (I see some sort of GoPiGo_Power_management process running that might be polling battery voltage.)

Q: Does the EasyGoPiGo3.drive_cm( 25.4 , True) stop the motors, or only polls roughly 10 times per second to see if the limit (both wheels +/-5 deg) is reached?

1 Like
2

Hi @cyclicalobsessive,

Q: Does the EasyGoPiGo3.drive_cm( 25.4 , True) stop the motors, or only polls roughly 10 times per second to see if the limit (both wheels +/-5 deg) is reached?

It doesn’t stop the motors, it waits for the motors to reach their target distance of 25.4 centimeters. And it does that by polling every 0.1 seconds the status of each motor. Basically, the method is put on hold until the GoPiG3 reaches its destination and then it proceeds to the next instruction.

I think you may already have gotten through the source code, judging that you know about that polling of 10 times per second, but either way, here’s the code that does the polling when it’s set to blocking mode:

Hopefully I understood what your question was and if not, please let me know.

Thank you!

1 Like
3

drive_cm uses set_motor_position to set a target position for the motors to run to. Although the EasyGoPiGo3 drivers don’t stop the motors after reaching the target, as long as there isn’t a new (conflicting) motor command issued, the GPG3 firmware will continue to attempt to keep the motors at the target position specified. Effectively, the GPG3 firmware will stop the motors once they reach their target position.

4

thanks, that matches the theory of operation I was hoping for.

I would love to have a better model of the firmware architecture and processes. I don’t know anything about Atmel processors; It has been a major project just to learn about the Raspberry Pi hardware, Raspbian OS, and Python.