A gimbal add-on that tracks up and down movement

Nov 03, 2026 Last reply: 7 hours ago 4 Replies
Jump to replies (4)

When this build is running, a small color display rides along on a camera gimbal and shows how the rig is moving up and down. A white center line sits on screen with a green leveling bar next to it, and as the gimbal is tilted to the left and brought back upright, the green bar changes shape and angle against that line. A two-digit readout on the same screen shifts between values like 94, 92, 91, 90 and 96. The point of all this is the z-axis, the up and down motion that a gimbal leaves unstabilized, and which depends on how steadily the person holding it walks.



The hardware is compact: a Seeed Studio XIAO ESP32-C3 board, a BN0085 sensor, an ST7735 display, some buttons and cables, and a small LiPo battery rescued from a bike light. The whole set of parts came from AliExpress for under 25 dollars. The maker picked the ESP32-C3 because it is tiny, cheap and has exactly the GPIO pins needed. Everything lives in a grey PLA case with corner screws, a metal push button and a square button beneath it, attached to the gimbal through a bracket on its side.



The process behind it is the part that stands out. The maker wrote none of the code personally, leaning on AI for the firmware, the case design drawn up in Fusion over an MCP connection, and even most decisions like part choice. The libraries are the Adafruit BN0085, ST7735 and GFX ones. The reported result is that the AI-written code worked perfectly.



There are open ends worth noting. I2C refused to cooperate, so the switch went to SPI at the cost of more pins, and routing cables inside the cramped enclosure was a fight. The displayed line is a moving average rather than the exact sensor readout, and how steady that reads during a real walk still seems worth testing.


Curious about the display side of this. With SPI taking extra pins on the ESP32-C3, how did the maker end up wiring the buttons and the BN0085 alongside it? Was there any pin left over, or did everything land exactly where the board allows?

I think showing a moving average instead of the raw sensor output is a smart call here. If the line followed every tiny wobble of the handle it would probably flicker too much to be readable mid-walk, and a steadier line seems more useful for judging your own pace. The trade-off is that sharp jolts get softened on screen, but for an accessory like this that seems like the right side to land on.

One idea for a next version: mount the BN0085 at the end of the gimbal near the camera base instead of wherever it sits now. Getting the sensor closer to the camera could give better dynamics during stabilization, and reading the IMU directly from there might beat calculating corrections with it down on the handle. The battery and board could stay in the grey case as they are.

The maker has addressed part of this: the data shown is processed rather than raw, and the line on screen is a moving average rather than the exact sensor readout. What has not been said is exactly which fusion processing the BN0085 output goes through, so that part the maker has not specified.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required