Betaflight firmware support

[nikhil-sethi]

Fixes: NA

About

This PR adds support for betaflight as a new firmware for drone flight. Reference issue: #4351 The implementation is similar to that of arducopter with some basic changes that I wanted to discuss.

How Has This Been Tested?

• Tested with betaflight 4.3.0 at commit 3267f041
• Currently only tested on Linux (Ubuntu 20.04). I understand that windows is recommended but my dual boot does not have AirSim + Unreal setup as of yet. Let me know if I should set it up or if someone else can test it! Also, I don't have a mac machine.
• RC input tested with a very basic custom program that outputs normalised joystick values to a UDP socket that betaflight listens to.

Known issues and doubts:

1. The stick responses are good enough for all axes after tuning PID values but the throttle seems sluggish for flying or testing. (takeoff at ~1700; almost full when doing maneuvers). Is this a basic inertia/mass issue? Shouldn't it be decoupled from raw PWM values. I haven't investigated this yet.
2. The arducopter implementation uses json to get the fdm packet here and there. #2075 says this is for easy addition and removal of sensors. However, for better compatibility, I found it easier and minimal to implement an fdm packet struct equivalent to the SITL target in betaflight. Are there some performance issues with this implementation that would be better with json? Please let me know if I am missing something.

Screenshots (if appropriate):

• Testing video: https://youtu.be/sVEfow3y6rU

TODO

• [ ] Fix/understand throttle issue
• [x] Fix/Understand fdm data structure
• [x] Format and cleanup according to repo style

[rajat2004]

Re JSON vs FDM packet, the benefit with JSON (or any kind of serialized format) is that the sender and receiver can add more types of data, extract info that is required and ignore the rest (e.g. if something is not supported, backwards compatibility). For e.g. with Lidar & RC control support, it would have worked even if either side didn't support it, it would just be ignored. For the fixed struct, variable data like Lidar won't work very nicely since the receiver would need to know exactly where the data starts and ends. New fields can only be added at the end, any change anywhere else in the struct would cause incorrect data being read if older struct is being used on other side.

FDM struct would be faster in performance than serializing to string and later parsing it, it'll most likely not be the bottleneck for the simulation, there are other much more obvious issues like AirSim internal physics and UE4 rendering, firmware side handling, and then network communication. Another thing that was very useful with the JSON interface was the ease of debugging, the packet can be easily read manually in Wireshark, to spot any obvious errors.

ArduPilot is also moving towards using JSON for interfacing with multiple simulators, e.g. this Discuss post

[nikhil-sethi]

Re JSON vs FDM packet, the benefit with JSON (or any kind of serialized format) is that the sender and receiver can add more types of data, extract info that is required and ignore the rest (e.g. if something is not supported, backwards compatibility). For e.g. with Lidar & RC control support, it would have worked even if either side didn't support it, it would just be ignored. For the fixed struct, variable data like Lidar won't work very nicely since the receiver would need to know exactly where the data starts and ends. New fields can only be added at the end, any change anywhere else in the struct would cause incorrect data being read if older struct is being used on other side.

FDM struct would be faster in performance than serializing to string and later parsing it, it'll most likely not be the bottleneck for the simulation, there are other much more obvious issues like AirSim internal physics and UE4 rendering, firmware side handling, and then network communication. Another thing that was very useful with the JSON interface was the ease of debugging, the packet can be easily read manually in Wireshark, to spot any obvious errors.

ArduPilot is also moving towards using JSON for interfacing with multiple simulators, e.g. this Discuss post

Thanks for explaining this in detail. It makes sense now why JSON was used. I'll progress with FDM for current testing purposes and in the meantime discuss at the betaflight PR if I can add the JSON unpacking routine in their target.

[microsoft-cla-retired[bot]]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

:x: nikhil-sethi sign now
_{You have signed the CLA already but the status is still pending? Let us recheck it.}