Close
0%
0%

Feiyu gimbal firmware

Better firmware for the mighty Feiyu mini 3D

Similar projects worth following
The Feiyu Mini 3D was a miracle of brushless gimbals in terms of its small size & price, but it didn't really work because of nagging firmware problems. This is alternative firmware to get the essential functionality, but not a complete feature set. Once installed, the original firmware will be completely lost. It's more for documenting how a brushless gimbal works.


Reprogramming the Feiyu is a long & hard process. It requires a SWD programmer. The NRF52 development kits have a SWD programmer which can be driven by the JLink software & repurposed for programming any ARM. Lions use a segger jlink programmer. There's also this: https://github.com/ataradov/free-dap


After 8 years of programming various gimbals, brushless gimbals continue to be expensive bits of kit, so there's still some incentive to keep hacking them.





Miniature gimbal cams have abounded on quad copters in recent years, but have never appeared as standalone modules.  We're still stuck with giant & expensive gimbals for phones & action cams.  This continues to make junk like the Feiyu relevant.  

While the custom firmware was as functional as needed in 2016, there is some desire to add highpass filtered terms to the feedback.  It already did lowpass filtering to the gyro input, but never fully stabilized.  It was good enough for 854x480 but horrible in 4k.  Highpass filtered terms did so well for steering vehicles, it could buy some more pixels.  This project is a motivational tool to try to improve the firmware.

After a short test, highpass filtering wasn't as good as straight derivatives.  It took the same constants & 90% bandwidth.  

  • Flipped mode

    lion mclionhead12/27/2021 at 00:24 0 comments

    The brain power could be offloaded to a heavy duty microcontroller outside the gimbal.  That would allow a better motor mixing model.  Lions aren't convinced a better mixing model would improve it.  When the DJI is panning rapidly, it's being held straight up so the yaw motor is just changing yaw instead of roll & pitch.  It would be a big rewrite & manely a science project, based on how much it's used.

    Another week at gimbal & broad yielded a much needed feature to allow shooting with the handle above or below the camera.  The easiest way to do it was flipping the pitch & putting sign flipping routines in hundreds of random places, just like a 10 year old.  There might be a grand unifying equation or a lookup table of signs based on flipping, but it was just faster to hack it out.  The handle position can be divided into quadrants with a different set of sign flips for each quadrant.

    Some quadrants don't work, but aren't worth supporting because the handle is in front of the camera.  The only need for the handle to go in front of the camera is in right side up mode for selfies.  

    Forcing the pitch upside down for 1 second causes the firmware to detect the new orientation.  Instead of flipping the pitch, the roll motor can also be rotated 180 deg to achieve the same effect.  In total, there are many combinations of pitch flips & roll motor flips, each requiring their own batch of sign flipping routines.  Flipping the roll motor requires taking the camera out while flipping the pitch doesn't, so it was deemed enough just to support flipping the pitch.

    Anyways, it was impressive to revisit the amount of work which was originally done from March 2016 to July 2016.  It involved reverse engineering the circuits, creating a bootloader, creating new firmware for the STM103 & atmega.  Last month's enhancements were minor compared to the huge past effort.

    The test harness for a gimbal must not be underestimated.  A mane problem still remanes of programming it in the enclosure.  It now requires undoing a lot of farsteners.  The easiest next step is routing the programming headers all the way into the battery compartment.  Another way is having umbilicals strapped to the outside.

  • Enclosure

    lion mclionhead12/08/2021 at 22:57 0 comments

    This thing got used maybe once in 5 years, but with the number of gootube videos made with brushless gimbals on the rise, it was due for an upgrade.  The brushless gimbal movies dominate real estate videos & they manely use the DJI Osmo pocket series. 

    The mane need is an updated handle with battery compartment.  There's also a need to increase the accelerometer weight to try to level the horizon more.  Finally, there's a need to switch I2C to software since I2C crashes are now a well known bug in the STM32.

    It also needs a follow mode for yaw.  There's still no plan for pitch.  Pitch is better served by using a gopro 7 & beyond.  Without a viewfinder, it was quite difficult to aim pitch.  The soldering & 2 axis joystick for the factory firmware was still present, but would be taken out for a new enclosure with only a yaw stick.  

    A key need was to enclose the battery & make it as small as possible.  Previously, duct taping the battery was stressing the battery & never got it very snug.  Salt water proved to be a huge problem with exposed battery connectors.  The next solution ended up still being duct tape, but duct taping a lid.  There was no printable battery cover as compact as the duck, but it wouldn't stress the battery.

    The gopro got a long needed cap in 3 attempts.  The trick is using stringers to allow the PLA to flex & using the springiness of PLA to hold it on.

    Tight squeeze in there.  It would be easier if lions invested in flat flex cables & modern connectors, but it would rapidly approach osmo pocket cost.  The 1st osmo pocket is down to $200 but was terrible.  The 2nd osmo pocket is $350.  A

    https://www.sparkfun.com/products/9426

     thumb joystick would save a lot of space.

    Interestingly, the original firmware was programmed with an AMD Phenom at a slower clockspeed.  The newer AMD Ryzen required adding delays to the serial port writes even though the serial port is a USB dongle.  There was a slight decrease in USB latency which overloaded the bootloader.

    The follow mode revealed new problems in the firmware.  The mane problem seems to be when the handle is centered, the yaw motor only affects roll.  As the handle moves to the side, the yaw motor contributes more to pitch than roll.  The problem wasn't as obvious before follow mode because the lion tended to keep the handle centered while panning with the joystick.  When moving the handle to the side is the user input, it's more obvious.

    It has a motor mixer which calculates the contribution of the yaw & roll motor to roll & yaw.  The motor mixer doesn't calculate the contribution of the handle motor to pitch.  It's been relying on the PID controllers to compensate automatically when the handle is on the side.  This causes pitch to oscillate.  The oscillation seems to throw off pitch sensing.  It really needs to mix all 3 motors.  

    A quick test of pitch/yaw mixing only degraded results.  Moving only 15 deg/sec helps.  Other gimbals are capable of much faster slew rates without glitching.  Can't remember the slew rate with the factory firmware.  There could be a better motor mixing model, but it might just require a better micro.

    There might be firmware  examples which solve these problems by now.  Continuing to invest in a home grown gimbal these days is like investing in a TI 58 ROM to calculate loans.  The smaller gopros which fit it aren't made anymore.  There weren't any clones with matching picture quality, years ago.  Lions only used it once in 5 years, only for night footage where digital stabilization is disabled.

View all 2 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates