There is now a developer wiki page on how to port ArduPilot to run on new flight controller boards especially those with STM32x CPUs. As you’ll see from the guide, with some of the most common STM CPUs, porting can be as easy as creating a new hwdef.dat file to specify which pins should be used for the buses (CAN, SPI, I2C, UART) and then which buses to be used for each sensor on the board. There are some scripts available as well which help make sure the file is written correctly and help ensure there are no conflicts in the pin assignment.
ArduPilot already supports quite a large number of boards but we expect that in 2018, with the improved efficiency of ChibiOS and easier porting, that number could more than double.
If you’re interested in porting ArduPilot to a new board, please read the guide and reach out to us on the ArduPilot ChibiOS Gitter channel (linked from the porting guide).
I am impressed by the latest developments on ArduPilot. I wasnt expecting that ArduPilot would dump Nuttx and move to Chibios. I like it I couldnt agree more with the reasoning as laid out in the Youtube video
I really like this new approach with use of Chibios as a true RTOS and also targetting the cheap FC boards that are out there. It really uses the hardware efficiently at last and opens up Ardupilot again to the masses. I was never very impressed with Nuttx but when I was using official ArduPilot, rightly or wrongly I didnt get any feeling that there was much interest in moving away from it. I am glad I was wrong about that!
That was a major reason that I started work my own board Ardupilot Flight Controller with on-chip OSD because, though I like Ardupilot, I felt there was a major gap between the Pixhawk and the type of cheap flight controller that I wanted.
The new official approach using Chibios fills the gap quite nicely. I havent used Chibios but it looks to have at similar performance to FreeRTOS that I used and the readymade drivers cut out a lot of work.
I like the use of the script to fit the software to the hardware. It looks similar to STM32Cube, which works well. Hopefully I will try it out on my own board at some stage soon.
So full marks to the dev team for that.
I still have some major gripes with ArduPilot. Here is the main one. and which is why I dont see me going back to using Ardupilot at the moment.
I think that the mixing is way too primitive.
On my my fork of ArduPilot on my SkyHook Discovery, I wanted to be able to automatically adjust the trim for different flight modes. The Crow flaps need proportional elevator trim as they are applied and I also wanted to be able to ignore Crow flap in auto modes etc and to be able to automatically dump Crow if useful throttle was applied in case I had to abort a landing. Unfortunately in the Official ArduPilot, trying to achieve any of that is just hopeless. I had a quick look recently and I still don’t see much has changed.
The approach I used in my ArduPlane fork was to strip out most of the current servo code in the ArduPlane App and end up with just 4 generic hopefully self explanatory Ardupilot provided functions as follows:
The problem with this approach is that users often want a combination of mixers for unusual aircraft.
The solution we are planning on is to support mixers via Lua scripting. The Lua script will have available as input all the current mixer outputs, plus the state of the aircraft (airspeed, groundspeed, attitude, RC sticks, mode etc). Then we can develop custom scripts that do whatever mixing system the user wants.
The solution we are planning on is to support mixers via Lua scripting. The Lua script will have available as input all the current mixer outputs, plus the state of the aircraft (airspeed, groundspeed, attitude, RC sticks, mode etc).
A simple consistent User API for Ardupilot ? Sounds great!
Achieve that and it would allow much simpler development in the language of your choice, be that Lua, Python or C++