Call For Testers - Final ChibiOS testing before NuttX is removed

We are now at the point that we are ready to remove NuttX and PX4Firmware support in ArduPilot master. What we need now is for final testing to be done on STM32 based boards to find any remaining regressions before we remove the NuttX/px4 builds.
So we calling for testers to find any regressions. We need users who are willing to test ArduPilot master on their boards and carefully look for changes in behaviour between the px4 builds and the ChibiOS builds. Both bench testing and flight testing are useful, so if you don’t want to fly ArduPilot master builds (as they have not been through the full testing we do for a release) you can still contribute by carefully bench testing your setup.

How to test

To test ArduPilot master you can either load the ‘latest’ firmware builds from as a custom firmware load, or you can use control-Q on the MissionPlanner firmware load page to load the latest builds.

Before reporting a regression, please test against the same build but using a px4 build. So for example, if you have found an issue with a CubeBlack ChibiOS build please compare against the latest master px4-v3 build so we know if it is related to the switch to ChibiOS. Issues that are not regressions related to differences between the NuttX/px4 and ChibiOS builds should be reported separately from this call for testing.

When testing please play close attention to the following:

  • any change in support for peripherals (eg. I2C devices, primary sensors, auxiliary sensors, compass behaviour etc)
  • any change in behaviour of RC input
  • any change in behaviour of failsafe operations

As you will be testing a non-release build please do very careful ground testing before flying. If you are not comfortable flying with a pre-release build then ground testing is still valuable.

We have a list here of currently known regressions and possible issues:

Thanks for testing!


Are you going to remove just the boards that are supported by both or remove PX4Firmware completely? What about boards not ported yet?

I’m planning on removing it completely in about 3 weeks time.
I’m guessing you are referring to the aerofc-v1? I’d love to see that ported over. Can you work on that? It shouldn’t take a lot of work.

New Chibios build has bad behavior when THR_FS=0

On NuttX, the inputs stay put when the taranis is powered off (and failsafe set to no pulses). Usually you can continue an automatic mission like this when your transmitter connection is lost.

On ChibiOS, the inputs go to extremes when connection is lost. Mode doesn’t switch in either build.

I’m still taking notes for further testing.

1 Like

thanks for finding this!
I’ve pushed a fix for this to master. Can you please re-test?
Cheers, Tridge

Will the Solo’s LED driver be ported over before the Nuttx builds are killed?

1 Like

So a bunch of tests have to be done and we all want good health for our vehicles in the future, but it’s the third time I read the OP and still not close enough to understant it, I guess for dummies like me make things simple and fearless for our vehicles with a bit of organization will help.
Some thoughts…

Test (on ground remove props)

1st on current version, get log. …?
then NuttX/px4 lastest, get log.
then ChibiOS beta lastest, get log.
then Get back (if needed)

Plug Check tones, leds, compass, gps fix, channels, telemetry, peripherals, I2C devices, sensors, checks …?
Arm, move the vehicle, checks …?
Disarm, checks …?
Get log

Get back (if needed) to NuttX/px4

How to… …?

Logs upload (choose one

Post issues and link to download, logs versions, …?


NuttX/px4 lastest link

ChibiOS beta lastest link

NuttX/px4 lastest link

ChibiOS beta lastest link

NuttX/px4 lastest link

ChibiOS beta lastest link

Trad Heli
NuttX/px4 lastest link

ChibiOS beta lastest link

Antenna tracker …?
NuttX/px4 lastest link

ChibiOS beta lastest link

With a Taranis X9D+ and X8R set to no pulses on connection loss,

Nuttx (PX4) builds on latest:
-Mode changes to FS_Short_Actn on TX shutdown. Re-connection results in immediate mode change to whatever TX is set to. If re-connection waits until the long failsafe (RTL engaged), then booting the TX does not change the mode out of RTL UNLESS the mode changed from when the TX was powered off. I don’t like the inconsistent behavior - Mode should either honor the TX on reconnect, or not honor the TX until another switch.

Thr_FS=0, the mode doesn’t change, and after about 1 second, the inputs are treated as neutral.

ChibiOS firmware seems to have the same behaviors. LGTM!

@tridge per our discussion earlier today… Spektrum input from the Solo’s RC is going haywire after the new IO DSM changes. T-Logs attached. Opened

Solo ChibiOS.tlog (294.4 KB)
Solo PX4.tlog (790.4 KB)

Really good news. ChibiOS porting is more easy.

@Pedals2Paddles I’ve reproduced and fixed the DSM issue. Fix is here:
I expect to merge this fix in this afternoon

@edge540T there is no specific testing formula, what we need users to do is to test on their vehicle, and look for anything that is behaving badly that doesn’t behave badly with the HAL_PX4 based releases.
The thing that you would bring to the testing is a different setup - everyone has slightly different vehicles, and so we get much broader test coverage if more people test it.
Cheers, Tridge


I’m using a LW20/Serial SN S20-00321 MFD 2017/06 on arduplane 3.9.2
Everything is working correctly on NuttX but not working on Chibios with these same parameters:
on Terminal, I have these data on firmware:
Do you have the same issue on Chibios ?

what flight board are you using? Can you please upload a full parameter file as well. In particular the SERIAL settings are critical.

Thanks Tridge,
here is the parameter file
the board is a pixhawk 2.1 cube

I also have this issue: Dual airspeed sensor problem

2 lidar sur telem2.param (14.1 KB)

I have a problem in ChibiOs - Weird compasses hangs and readings on ChibiOs
Could someone assist on what can I do to somehow diagnose it?

Here i follow this tips Testing Strategy of ChibiOS

Most of the ChibiOS/RT demos link a set of software modules (test suite) in order to verify the proper working of the kernel, the port and the demo itself.

Strategy by Component

The OS components are tested in various modes depending on their importance:

  • Kernel . The kernel code is subject to rigorous testing. The test suite aims to test all the kernel code and reach a code coverage as close to 100% as possible. In addition to the code coverage, the kernel code is tested for functionality and benchmarked for speed and size before each stable release. In addition to the code coverage and functional testing a batch compilation test is performed before each release, the kernel is compiled by alternatively enabling and disabling all the various configuration options, the kernel code is expected to compile without errors nor warnings and execute the test suite without failures (a specific simulator is used for this execution test, it is done automatically by a script because the entire sequence can take hours).
    All the tests results are included as reports in the OS distribution under ./docs/reports .
  • Ports . The port code is tested by executing the kernel test suite on the target hardware. A port is validated only if it passes all the tests. Speed and size benchmarks for all the supported architectures are performed, both size and speed regressions are monitored .
  • HAL . The HAL high level code and device drivers implementations are tested through specific test applications under ./testhal .
  • Various . The miscellaneous code is tested by use in the various demos.
  • External Code . Not tested, external libraries or components are used as-is or with minor patching where required, problems are usually reported upstream.

Kernel Test Suite

The kernel test suite is divided in modules or test sequences. Each Test Module performs a series of tests on a specified kernel subsystem or subsystems and can report a failure/success status and/or a performance index as the test suite output.
The test suite is usually activated in the demo applications by pressing a button on the target board, see the readme file into the various demos directories. The test suite output is usually sent through a serial port and can be examined by using a terminal emulator program.


Joy Writer at Buzzcnn

This post should be closed as Nuttx has been removed a while ago.

1 Like

My VRBrain is OK with Nuttx. I had a run with latest ChibiOS on it and boot loader was so corrupted during mandatory settings like calibrations that I had to reflash it three times without more success.

Ice on the cake: M8N GPS settings where also corrupted and USB connection was impossible.

So continue like that with ChibiOS and be happy,