Inverted Pendulum

I see they discontinued this so we need to build our own.  There is a DIY kit and it is just an Arduino, 2 motors, IMU and a bridge.   I guess we could add a 24L01 or use an ESP32 instead of Arduino so you have wireless connection to ARC https://circuitdigest.com/microcontroller-projects/arduino-based-self-balancing-robot

I have this one too: ELEGOO Tumbller Self-Blancing... https://www.amazon.ca/dp/B07R1XP3YX?ref=ppx_pop_mob_ap_share

but the code would have to be different. I haven’t modified it because they’re pretty boring and quite difficult to control, surprisingly

I was going to buy one of those but you don’t currently support the IMU I believe. GY-521?? and the MPU6050 are really cheap.  I am sure I have one laying around somewhere.

The robot skill doesn’t use the imu. The firmware needs to be modified to accept movement parameters.

Doing the imu error calculation in ARC would be too slow. It requires a much tighter loop and therefore runs on the microcontroller. In this case, the Arduino. Because once you capture the imu data, and send it to Arc, a process in Arc, sends commands back. Too much time has gone by, and the imu measurement is expired.

The time between measurement and action needs to be as low as possible. Otherwise, the calculated error from the measurement is expired.

So do the Kalman and error calculation on the Arduino. Allow the Arduino to accept commands from ARC for movement.

The movement of an inverted pendulum is actually adding an offset to the value for the error calculation. For example, in a perfect world standing straight up and down would be 0 degrees. So if your imu is reporting -3 degrees, an error of -3 degrees is needed for correction.

If you want the robot to move forward, you can set the value from 0 to -2 degrees (or something. This is just an example). Then it leans forward during the correction, so it moves forward.

The ARC movement commands modify the error value on each wheel to allow the robot to move.

Would an onboard PC running ARC be just as responsive as an Arduino as you don’t have network bottlenecks.

IMU=>SPI=>Arduino (Mega) IMU=>SPI=>ARC (Rockpix)

A PC can never be as responsible as a microcontroller. Even a microcontroller that is considered slow, such as an Arduino Genuiunonono that's 16mhz, will still process the instructions more consistently and with higher precision.

The communication (SPI, UART, or WIFI) is irrelevant to how the operating system executes instructions and the overhead and prioritization.

You see, even your computer's accessory ports have microcontrollers that do the timing accurate closed loops - and they pass information to and from the cpus i/o as requested, generally by an interrupt. So from what I'm explaining, you would use the microcontroller as an i/o extension similar to how your computer works. You don't see the microcontrollers on your computer because they're inside and come with it. Your robot "parts" are DIY extensions that do the same thing.

An operating system will never and can never perform the timing necessary for high-precision closed-loop functions - such as an inverted pendulum. Even a "real-time" operating system, such as freeRtos, is not actually real-time compared to a closed loop. The definition of real-time when referring to operating systems is not misleading.

I should add as well one of the challenges that I mentioned earlier is timing. The number of microseconds between the closed loop needs to be tracked to the highest precision possible - because that's the value you use for compensation between samples. The code for an inverted pendulum can be pretty simple if tightly closed loops have high precision. Soon as you introduce variance in timing, you have no measurement to compensate for the sample rate. Remember, physics is still happening between samples, and you need some way to compensate for that time between samples accurately.

Thanks for the education as always DJ