I have been wondering if we should run the gyro sampling on the MPU6000 at a higher rate. It can’t do accel over 1kHz, but IIRC it can do gyro at up to 8kHz.
yep, I’m getting a lot more variance, but I’m also running 4 EKFs, 3 IMUs and 2 compasses 
I should setup a board with a single IMU. Do you have a GPS and mag hooked up and with GPS lock?
Yes, and log write too. I use not true GPS but recorded NMEA stream for debug.
UPD. And with built-in OSD too
[quote=“Pedals2Paddles, post:20, topic:20491, full:true”]
The procedures for building with Nuttx are unchanged and still work. And that’s what people should still use unless they want to be test pilots for ChibiOS.
Make based builds are no longer even used or supported in ArduPilot. …
[/quote]many THX
the comment on make I think is not correct though, luckily
Leonard has got some good flight results running copter with ChibiOS at 1kHz on a PH2.1 cube. I’m going to extend support in AP_InertialSensor to allow for 2kHz and he will try that soon
Make is still there but is no longer being supported or updated. It has been replaced by WAF. Probably half the board types are not even included in make anymore. All of the linux board types have been removed from make completely. ChibiOS builds are not in make and they won’t be. If you want to build ChibiOS, you will need to use WAF.
I just ran the build with the latest from @tridge’s branch and loaded onto my Solo. Spectacular!
The performance monitor data is astounding! The Solo is very heavy load on the Pixhawk’s performance. As you can see, with the Nuttx / px4 firmware, it is extremely overtaxed at all times. The gimbal and logging take a heavy toll on it. Massive overruns at all times. With ChibiOS, well the the numbers speak for themselves. Overruns went from 30-50% with px4/nuttx, down to 0.125%. I don’t even need to describe the results.
ArduCoper master 3.6-Dev // Nuttx & PX4
PERF: 1316/4000 max=6659 min=2119 avg=2953 sd=597
PERF: 1280/4000 max=8157 min=1882 avg=2952 sd=616
PERF: 1275/4000 max=7370 min=2014 avg=2958 sd=637
PERF: 1313/4000 max=7256 min=1905 avg=2960 sd=607
PERF: 1328/4000 max=6748 min=1942 avg=2958 sd=600
PERF: 1313/4001 max=6854 min=1934 avg=2953 sd=584
ArduCopter 3.6-Dev // ChibiOS
PERF: 1/4000 max=3004 min=2200 avg=2501 sd=86
PERF: 2/4000 max=3308 min=2125 avg=2501 sd=96
PERF: 1/4000 max=3102 min=2197 avg=2501 sd=90
PERF: 2/4000 max=3102 min=2098 avg=2501 sd=88
PERF: 5/4000 max=3795 min=2104 avg=2505 sd=99
PERF: 0/4000 max=2998 min=2104 avg=2501 sd=94
PERF: 0/4000 max=2888 min=2100 avg=2500 sd=82
Thanks Matt! Really nice to hear.
Now the big question, have you flown it?
Not yet. Perhaps this weekend.
WOW, THIS is good stuff.
Whats the state of CAN on the chibios port… just curious …?
It’s under works, I will have initial implementation out soon.
In November I was trying to bring up the night_ghost port of ArduPlane (pre-merge-into-Master) on an Omnibus F4 V3, but with limited success, particularly on the I2C airspeed sensor front. End goal is a very lightweight but fully functional full house e-glider with everything ArduPlane has to offer. See attached planned layout, and photos of the flight controller itself. Does it seem that the ChibiOS-based ArduPlane is now ready to handle everything shown here? If so, I will dive in. If not, I can wait.
Thrilled with what Tridge, Sid and others have accomplished here.
Kelly
yes, that board should work fine with either the F4Light HAL maintained by @night_ghost or with the ChibiOS HAL that Sid and I have done. So you can do either port or both 
If you’d like to do the ChibiOS port then please see the docs here:
http://ardupilot.org/dev/docs/porting.html
Cheers, Tridge
Thanks Tridge. I have read the porting guide. Nice work. Have you and Sid brought your Chibios system up on the Omnibus F4 V3? Or would I need to be the pioneer for that board? I can’t tell from this list if someone has already brought up the Omnibus F4 V3:
It’s one of the more common boards among those following night_ghost. And actually, my main question before going pioneer is have you guys had success with a digital airpspeed sensor on I2C to any of the STM32 flight controllers?
Kelly
@tridge I would like to know why for the revomini do you use PC6 for RCIN instead of PB14 as in F4Light HAL, this will let UART6 free for GPS and PB10,PB11 could be used as I2C (instead of UART3) for an external compass.
Andrea
@anbello, i think PB14/15 use timer12 and that isn’t referenced in chibios f405 dma table yet. this is quite a bit beyond my knowledge though.
basti
I think the f405 table was amended a couple of days ago when the omnibusf4v2 board was added to ChibiOS, so if someone wanted to change it, might be possible now.
1m
@james_pattison I think you are right, from what I see here should be possible to use PB14 or PB15 as RCIN.
My latest post contains wrong information, is not possible to use PB14 or PB15 as RCIN using DMA, but now @sh83 has added support for interrupt based RCIN parsing:
I tested this for target omnibusf4pro on a quad with Omnibus F4 Pro V2 and it is all OK. I did also a test flight in stabilize, althold, loiter, circle and land, all OK.
I set up an enviroment on a Raspberry Pi 2 for building the Arduplane Chibios firmware for STM32F flight controllers. All appears to have gone well except the final --upload. Any ideas what might be wrong? FC is Omnibus F4 V5 if that matters. Is airbotf4 the right board?
pi@PiZeroW:~/ArduPlane/ArduPilot $ sudo ./waf plane --upload
Waf: Entering directory `/home/pi/ArduPlane/ArduPilot/build/airbotf4'
Checking for env.py
env added CHIBIOS_BUILD_FLAGS=USE_FATFS=no CHIBIOS_PLATFORM_MK=os/hal/ports/STM32/STM32F4xx/platform.mk CHIBIOS_STARTUP_MK=os/common/startup/ARMCMx/compilers/GCC/mk/startup_stm32f4xx.mk
[436/438] Linking build/airbotf4/bin/arduplane
[437/438] Generating bin/arduplane.apj
[438/438] Uploading build/airbotf4/bin/arduplane.apj
Loaded firmware for 46,0, size: 820464 bytes, waiting for the bootloader...
If the board does not respond within 1-2 seconds, unplug and re-plug the USB connector.
Found board 46,0 bootloader rev 5 on /dev/serial/by-id/usb-APM_REVO_405_0-if00
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff type: ÿÿÿÿ
idtype: =FF
vid: ffffffff
pid: ffffffff
coa: //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////8=
sn: 004900363436510b35373636
chip: 10076413
family: STM32F40x
revision: 1
flash 983040
Erase : [====================] 100.0%
Program: [====================] 100.0%
Verify : [ ] 1.0%Attempting reboot on /dev/serial/by-id/usb-ArduPilot_revo-mini_360049000B51363436363735-if00 with baudrate=57600...
If the board does not respond, unplug and re-plug the USB connector.
Attempting reboot on /dev/serial/by-id/usb-ArduPilot_revo-mini_360049000B51363436363735-if00 with baudrate=57600...
If the board does not respond, unplug and re-plug the USB connector.
Attempting reboot on /dev/serial/by-id/usb-ArduPilot_revo-mini_360049000B51363436363735-if00 with baudrate=57600...
If the board does not respond, unplug and re-plug the USB connector.
Traceback (most recent call last):
File "/home/pi/ArduPlane/ArduPilot/Tools/ardupilotwaf/px_uploader.py", line 736, in <module>
main()
File "/home/pi/ArduPlane/ArduPilot/Tools/ardupilotwaf/px_uploader.py", line 710, in main
up.upload(fw, force=args.force, boot_delay=args.boot_delay)
File "/home/pi/ArduPlane/ArduPilot/Tools/ardupilotwaf/px_uploader.py", line 559, in upload
self.__verify_v3("Verify ", fw)
File "/home/pi/ArduPlane/ArduPilot/Tools/ardupilotwaf/px_uploader.py", line 461, in __verify_v3
report_crc = self.__recv_int()
File "/home/pi/ArduPlane/ArduPilot/Tools/ardupilotwaf/px_uploader.py", line 254, in __recv_int
val = struct.unpack("<I", raw)
struct.error: unpack requires a string argument of length 4
Waf: Leaving directory `/home/pi/ArduPlane/ArduPilot/build/airbotf4'
Traceback (most recent call last):
File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Scripting.py", line 165, in waf_entry_point
run_commands()
File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Scripting.py", line 266, in run_commands
ctx = run_command(cmd_name)
File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Scripting.py", line 250, in run_command
ctx.execute()
File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Scripting.py", line 616, in execute
return execute_method(self)
File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Build.py", line 255, in execute
self.execute_build()
File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Build.py", line 275, in execute_build
self.compile()
File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Build.py", line 377, in compile
raise Errors.BuildError(self.producer.error)
File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Errors.py", line 45, in __init__
WafError.__init__(self, self.format_error())
File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Errors.py", line 51, in format_error
txt = tsk.format_error()
File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Task.py", line 415, in format_error
txt = cmd
NameError: global name 'cmd' is not defined
pi@PiZeroW:~/ArduPlane/ArduPilot $