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 https://github.com/ArduPilot/ardupilot/issues/9763.
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:
https://github.com/ArduPilot/ardupilot/pull/9787
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
Hello,
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:
RNGFND_ADDR,0
RNGFND_FUNCTION,0
RNGFND_GNDCLEAR,5
RNGFND_LANDING,1
RNGFND_MAX_CM,9500
RNGFND_MIN_CM,5
RNGFND_OFFSET,0
RNGFND_ORIENT,25
RNGFND_PIN,-1
RNGFND_POS_X,0
RNGFND_POS_Y,0
RNGFND_POS_Z,0
RNGFND_PWRRNG,0
RNGFND_RMETRIC,1
RNGFND_SCALING,1
RNGFND_SETTLE,0
RNGFND_STOP_PIN,1
RNGFND_TYPE,8
on Terminal, I have these data on firmware:
Do you have the same issue on Chibios ?
Thanks
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.
Source: http://chibios.sourceforge.net/html/testsuite.html
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,
Marc
Have you reported this issue before ?
I wonder if VRBrain is considered as a supported FC as it it not showned in the list
http://ardupilot.org/copter/docs/common-autopilots.html
suggest you try on master looks like some VRBrain verstions only got supported on chibos very recently
Cool, thanks for the update 
Is this issue solved?
I faced the same today and have no idea how to solve.
Everything was working perfectly with Copter 3.6.5 with NuttX, but not working on Copter 3.6.6 with ChibiOS.
I’m using Pixhawk2.1 with Cube
Can you be more specific? What is “this”?
Sorry that I didn’t share much details in the query.
LW20-C is tested in ArduCopter 3.6.5 with NuttX. I upgaded the firmware to 3.6.6 along with ChibiOs, PFD was displaying “Bad Lidar Health”.
Later I changed to AC3.6.6 with NuttX, and Sonar range was showing correct with the same parameter.
LW20 is connected to Telem1 (Serial1) of the Pixhawk2.1 with cube.
It’s working well with 3.9.6 thanks Tridge !