ArduPilot porting guide for ChibiOS + STM microcontrollers

rmackay9 · March 2, 2018, 11:59pm

One of the popular presentations at the Developer Un-Conference was Tridge’s talk on ArduPilot’s move to ChibiOS and the very significant performance improvements that gives us. (presentation, video)

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).

skyscraper · March 4, 2018, 7:21pm

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:

plane.get_roll_demand()
plane.get_thrust_demand()
plane.get_pitch_demand()
plane.get_yaw_demand()

github.com

kwikius/ardupilot/blob/master/ArduPlane/Plane.h#L86


friend class GCS_MAVLINK;
friend class Parameters;
friend class AP_Arming_Plane;


Plane(void);


// HAL::Callbacks implementation.
void setup() override;
void loop() override;


float get_airspeed() const { return this->airspeed.get_airspeed();}
float get_pitch_demand()const { return output_pitch.get();}
float get_roll_demand()const { return output_roll.get();}
float get_yaw_demand()const { return output_yaw.get();}
float get_thrust_demand()const { return output_thrust.get();}
float get_flap_demand()const 
{ 
   constexpr uint8_t flap_js_channel = 4;
   return quan::constrain(static_cast<float>( hal.rcin->read(flap_js_channel) - 1500) / 500.f,-1.f,1.f);
}
float get_airspeed_min() const { return static_cast<float>(aparm.airspeed_min);}

These are in common units, which represent some torque value to apply to the relevant axis between -1 and 1

Note that these “demands” know nothing about servos. It is then up to the mixer implementation to convert these values into useful control outputs

Here are various mixers That I have made based on this idea

A simple “wing” mixer

github.com

kwikius/ardupilot/blob/master/ArduPlane/mixers/falcon_mixer.cpp


// simple Flying wing mixer
namespace {

   float constexpr roll_gain = -0.5f;
   float constexpr pitch_gain = -0.5f;

   uint8_t constexpr num_outputs = 3;
   float output[num_outputs] = {0.f,0.f,0.f};

   void mixer_eval()
   {
      float const roll = plane.get_roll_demand() * roll_gain;
      float const pitch = plane.get_pitch_demand() * pitch_gain;

      output[0] = roll + pitch;
      output[1] = roll - pitch;
      output[2] = plane.get_thrust_demand();

      for ( uint8_t i = 0; i < num_outputs; ++i){

This file has been truncated. show original

The mixer for the Skyhook Discovery

github.com

kwikius/ardupilot/blob/master/ArduPlane/mixers/disco_mixer.cpp


namespace {

   uint8_t constexpr port_v_tail = 0;
   uint8_t constexpr stbd_v_tail = 6;
   uint8_t constexpr throttle = 1;
   uint8_t constexpr stbd_ail_outer = 2;
   uint8_t constexpr stbd_ail_inner = 3;
   uint8_t constexpr port_ail_inner = 4;
   uint8_t constexpr port_ail_outer = 5;

   float constexpr stbd_ail_inner_dir = -1.f;
   float constexpr stbd_ail_outer_dir = -1.f;
   float constexpr port_ail_inner_dir = 1.f;
   float constexpr port_ail_outer_dir = 1.f;

   float constexpr ail_inner_horn_len = 0.7f;
   float constexpr ail_outer_horn_len = 1.f;

   float constexpr up_ail_gain = 0.75f;

This file has been truncated. show original

Sitl mixer

github.com

kwikius/ardupilot/blob/master/ArduPlane/mixers/sitl_mixer.cpp


// sitl mixer
namespace {

   uint8_t constexpr num_outputs = 4;
   float output[num_outputs] = {0.f,0.f,0.f};

   void mixer_eval()
   {
       output[0] = plane.get_roll_demand();
       output[1] = -plane.get_pitch_demand();
       output[2] = plane.get_thrust_demand();
       output[3] = plane.get_yaw_demand();

       for ( uint8_t i = 0; i < num_outputs; ++i){
         output_action(i);
       }
   }
}

These have all flown in reaity or in the sim of course

Not also how the mixers stand alone in one file rather than being scattered over many source files

regards
Andy Little

khancyr · March 4, 2018, 10:33pm

Hello, you should look at the new scripting feature that would come, it should be able to do what you want !

Wild_Bill · March 6, 2018, 10:09am

Hi, thank you for your post.

Can you confirm that Ardupilot Copter can now be applied to cheap flight controller like the following;

Omnibus F4 V5
Specifications
STM32 F405 MCU, Runs Betaflight 3.0 firmware
SBUS/PPM input (Pinheaders)
6PWM output
Only 36x36mm, mount holes 30.5x30.5mm
BMP 280 Baro
SPI Sensor MPU6000/ICM-20608
128Mbit Flash
Powered directly from 2-6S Lipo (v5 only)

I appreciate the new hwdef.dat file will be needed and some other minor tweaks, but i am just checking i have understood the principal correctly?

Many thanks,

tridge · March 6, 2018, 8:36pm

yes, we will be able to support boards like that quite easily.
Maybe you’d like to try following the porting guide and creating the hwdef.dat yourself?

tridge · March 6, 2018, 8:40pm

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.
Cheers, Tridge

Wild_Bill · March 6, 2018, 9:47pm

Brilliant news!!!

I’ll give it a try

Thank you

skyscraper · March 7, 2018, 12:09pm

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++