Guys, been testing ChibiOS (latest from 2 days ago) on z84 wing (on Omnibus F4 Pro v2 board, with BN-880 GPS/Mag). On this build I have to set compass orientation at “ROLL 180”. On my quad running latest copter release (NuttX) on Pixracer board, the same GPS/Mag unit requires “None” as compass orientation. Not sure which is correct (suspect “None” but can’t be certain - clearly one of the HALs has this rotated). Cheers, Paul
Edit: This appears to have been resolved in firmware of recent days. Many thanks.
Finally getting back into this since the fire at my house. I made a number of changes to the Solo’s python files that handle firmware loading to accommodate loading ChibiOS based FW. And it actually worked! I was able to load the FW without opening it up and using a USB. The only thing I still have to change is having it look for the APJ extension. In the meantime, I just renamed it to .px4 until I get around to that last change.
I made a few flights, including a Smart RTL demo. It flew great. !
Issues I noticed thusfar:
Tones during compass calibration not working, which I saw in the release notes
Gimbal makes a random twitch every minute or so for reasons unknown
Performance Monitor on NUTTX shows the Solo hogging system resources to the point of massive overruns. As usual. It’s actually amazing this works without flight handling implications.
Has anyone tested the roll rate on ChibiOS Plane when in Acro mode? I built z84 wing for testing ChibiOS on Omnibus F4 Pro v2.1 board, but the roll rate is about 25% of what I would expect when in Acro mode (Pitch is fine). I think there is definitely something amiss there!
@pauljatherton - are you saying you have tried the same airframe with the same parameters on chibi-os and non-chibi-os firmware, and found the flight behaviour is different? If so uploading a .bin log of each flight is the way forward, so the differences can be nailed down, thanks!
No, nuttX is not possible on Omnibus board of course, so a comparison between the two methods is not possible. I have however compared all the other flight modes on this controller with same firmware which all have snappy response on roll axis, but Acro has only 25% roll rate in comparison to these (roll set to 500deg/sec which is max) Roll rate in Manual flies perfectly also. Acro seems to be the only affected mode. So Acro isn’t very Acro unfortunately.
Hi, First thanks everybody for you effort.
I want to test ardurover as primary control in Manual mode and AP mode, or as auxiliary control in AP mode of a robot/ground drone that already is working nice over CC3D revolution and librepilot (Manual mode/Assisted manual mode)
Any combination will have to share telemetry data and sensors readings with Linux and ROS via mavlink and a Arduino DUE (sensor readings IIC or SPI) or some small program o control (emerncy stop or similar)
The space,MAVLINK telemetry compatibility and self-stabilized gimbal by servos (as librepilot do). is critical for me.
Im very confuse, if I buy another CC3D Revolution ardurover and autopilot are fullly sopported for them? (included new versions,sensors,telemetry etc. Do you think OPlink radio will be supported in the future?
I would agree. With the parameter set to max (500) it still only rolls at 25% the normal (Manual and Stabilize) rate. It is certainly no rolling at 500deg/sec.
ChibiOS in Copter 3.6-RC7 has all the tones working properly now. They sound the same as the nuttx tones, and the compass calibration tones are working.
Did test flight today on ‘latest’ firmware (d/l this morning) for Omnibus F4 Pro (running v2.1 board) in a z84 wingwing. I can confirm that the roll rate is still dreadful in Acro mode, but very responsive and perfectly fine in all other modes inc Stabilize and Manual. I have captured a log file which I’m hoping will demonstrate the issue to one of the devs, in the hope that this might be addressed in a future fw release. Aside from this one issue, the firmware worked flawlessly - very happy with it. Also flew ChibiOS copter fw on v1 Pixhawk perfectly. Many thanks, Paul
Edit: There has since been discussion with Tridge about this issue on gitter (mentioned on RCG here, here, and here)- For info I heard back the following:
…apparently the rates are limited by RLL2SRV_RMAX=75…set it to 0…
the limit is changed from default of 0 by autotune, but if reset back to 0 after autotune, the other pid parameters will limit the rate to a value thats acceptable in autonomous flight, then ACRO rates will apply correctly in ACRO mode.
I will test this theory, but can’t help thinking that it would be better to have the above parameter used only for regular ‘assisted’ modes, whilst allowing ACRO_ROLL_RATE to replace this in Acro mode.
you mentioned that you used a Nucleo board for development. Since I own a Nucleo F767 I’m curious how you used it? Since the USB connector of the board is connected to the ST-Link debugger I’m wondering if it is possible to flash the board using dfu through this? Or do I have to use the USB MCU pins (PA11 PA12)? Is it then still possible to use the ST-Link debugger?
If I get everything to work I’m willing to contribute a tutorial.
