Update — IMU finally working properly with section control, no AutoSteer
I wanted to update this old thread now that I finally have the IMU working the way I originally wanted.
The final arrangement is still two Nano ESP32-S3s.
The first ESP32 is dedicated to the SparkFun BNO086. The BNO086 is connected by SPI, and that ESP32’s only job is to read the IMU and send the data over a wired UART connection to the main machine controller. That custom software was all written by AI.
The second ESP32 is the machine controller. It handles the sprayer functions, AOG UDP communication, section control, nozzle PWM, turn compensation, pressure compensation, work switch, etc. It receives the IMU data over UART and sends the appropriate AgOpenGPS PGNs. This custom software started with my hand coding and ended with AI assistance.
The working path is:
BNO086
↓ SPI
IMU ESP32
↓ UART
Machine ESP32
↓ UDP / AgIO PGNs
AgOpenGPS
I deliberately ended up with only the machine ESP32 communicating with AOG over WiFi. The IMU-to-machine connection is copper UART rather than a second WiFi/UDP stream. That has been simpler and more reliable.
A few things I learned along the way:
- SPI was the right choice for the BNO086. I avoided I2C because of the BNO08x/ESP32 clock-stretching issues I had been fighting.
- The BNO086 PS0/PS1 mode pins (solder jumpers) need to be set correctly for SPI at startup.
- The dedicated IMU ESP32 does not need to know anything about AOG or sprayer control. It just acquires valid IMU data and passes it to the machine controller.
- The machine controller is the only device that needs to construct and send the AOG PGNs.
One thing that caused my confusion earlier in this thread was that AOG roll indicator was working while the AgIO IMU icon was still gray.
It turned out those are two separate things.
**PGN211** carries the actual IMU data. Once PGN211 was being received correctly,
AOG could use the roll information and the roll display responded correctly
when I tilted the BNO086.
But that alone did not make AgIO recognize the hardware as an IMU device.
To get the AgIO IMU indicator to go green, I also had to do the
device-identification side correctly: PGN211 source = 0x79
**PGN121** IMU Hello Reply
When AgIO sends its PGN200 Hello Request, the machine controller
now sends the appropriate PGN121 IMU Hello Reply.
The machine-controller hello response, **PGN123**, is separate.
So the progression was basically:
PGN211 working
↓
AOG roll works
↓
AgIO IMU icon still gray
Then:
PGN211 sent from source 0x79
+
PGN121 reply to AgIO PGN200 hello
↓
AgIO IMU icon turns green
That distinction may save somebody else some head scratching. Working roll does not necessarily mean AgIO has completed the IMU device-recognition handshake.
I originally sent PGN211 at about 20 Hz. After adding a traffic monitor and watching the actual AOG/machine-controller traffic, I reduced PGN211 to 10 Hz. AOG still responds smoothly, and it cuts the IMU UDP traffic roughly in half.
I also staggered the periodic outgoing PGN timing so the regular IMU, machine and section-feedback packets are not bunched up and transmitted in one burst.
Another thing changed from my original reason for adding the IMU. I initially wanted yaw rate mainly for individual-nozzle turn compensation. During development I discovered that my earlier problem with AOG’s left/right tool speeds was actually my own parsing error. I now use AOG’s left/right tool-speed values for the sprayer turn compensation, while the BNO086 provides IMU hill side tilt information to AOG. That ended up being a cleaner separation of jobs.
So the answer to my original question from four months ago is:
Yes, you can add a BNO08x IMU to an AOG section-control machine without building an AutoSteer system.
You do not need the complete AutoSteer PCB just to provide IMU information to AOG.
In my case the working implementation is:
BNO086 → SPI → dedicated ESP32 → UART → machine ESP32
→ PGN211 IMU data
→ PGN121 IMU hello/identity
→ AgIO / AOG
The dedicated IMU processor may be overkill for some installations, but I like the separation. The IMU side is small and deterministic, while all AOG/WiFi communication stays in one place.
The IMU portion is finally at the point I wanted: power it up and it just works.
BTW that June 18 image of the messy controller enclosure has been reworked using KiCAD into a PCB
