We have just implemented a major upgrade to the ArduPilot sensor drivers for STM32 based boards (PX4v1, Pixhawk, Pixhawk2, PH2Slim, PixRacer and PixhawkMini).
The new sensor drivers are a major departure from the previous drivers which used the PX4/Firmware drivers. The new drivers are all “in-tree” drivers, bringing a common driver layer for all our supported boards, so we now use the same drivers on all the Linux boards as we do on the PX4 variants.
We would really appreciate some testing on as many different types of boards as possible. The new driver system has an auto-detection system to detect the board type and while we think it is all correct some validation against a wide variety of boards would be appreciated.
Advantages of the new system
The new device driver system has a number of major advantages over the old one
- common drivers with our Linux based boards
- significantly lower overhead (faster drivers) resulting in less CPU usage
- significantly less memory usage, leaving more room for other options
- significantly less flash usage, leaving more room for code growth
- remote access to raw SPI and I2C devices via MAVLink2 (useful for development)
- much simpler driver structure, making contributions easier (typical drivers are well under half the lines of code of the PX4 equivalent)
- support for much higher sampling rates for IMUs that support it (ICM-20608 and MPU-9250), leading to better vibration handling
How to test
We’d love people to test the new system and report success or failure. To test you should do the following:
- using your favourite GCS load the ‘latest’ firmware from firmware.ardupilot.org
- boot it up
- test all your sensors for correct output by monitoring them with the graphs on your GCS
- if everything looks OK then go for a fly
Note that this should be considered alpha code. If you are not comfortable flying alpha code then just do ground testing. Most of the testing we need can be done without flying.
Things to particularly watch out for:
- you will probably need to re-calibrate your magnetometers, especially if you have a HMC5983 external mag
- carefully check sensor orientation has come out right
- check that all the peripherals that worked previously still work (eg. rangefinders, RPM sensors etc)
- make sure you have all pre-arm checks enabled before flying
- you shouldn’t need to re-calibrate your accelerometers, but please do check for consistency between sensors before flying
Higher Sample Rates
If you have a board that has accel and gyro sensors capable of higher sample rates (eg. PixRacer, Pixhawk 2.1 or PixhawkMini) then you will automatically get a much higher sample rate on those IMUs. They will sample the primary gyro at 8Khz and the primary accel at 4kHz. This should result in considerably better handling of some types of vibration. Back to back flight logs with the current stable release of ArduPilot compared to the ‘latest’ firmware would be appreciated to confirm this, particularly for airframes that have had a problem with vibration.
Please report success/failure in this thread on discuss.ardupilot.org
please note that VRBrain has not yet been converted to the new driver system. I’m hoping that will happen soon with some help from Luke Mike
Also note that if you set the BRD_TYPE parameter to 100 on a FMUv2 based boards and reboot then it will use the old PX4 drivers. That allows for easy direct comparison. We will be removing this option at some future stage to save flash space.
This is a really good development. I was starting to lose faith in non Linux boards being supported in the longer term, but this breathes new life into the microcontroller side of ArduPilot.
This test is for copters too?; I’m trying to tune again my racer with a pixracer to remove video vibrations, it’s possible to try autotune with this vers?
Thank’s for great work
yes, this is for all vehicle types. I flew it on my 250 quad racer with a pixracer and it worked very nicely for me.
Nice, I install and give a try with autotune, thank’s Tridge
2 posts were split to a new topic: ArduPilot New Sensor Test
NOTE: This is not a support forum, Post your topics regarding testing etc… in the correct sections (unless @tridge meant to post a specific thread somewhere) tagging the posts ‘in-tree-sensors’ could be helpful
I really appreciate the moderation and I like the idea of keeping discussions short and focussed. But these replies/questions were pretty much related to the “Call”.
You can reply and tag the new posts. I think @OXINARF has moved it to the development team since this is bleeding edge for changes. Feel free to post replies to the topic moved there. This category for blogs is just for announcements.
Posting in the right category and using tags keeps relevant posts together, not a long thread that is hard to manage. Discourse works much better to keep topics focused. It even help find previous posts when entering a new topic to keep duplication down.
Like @billb said, this should be really an announcement post and people can comment on the announcement but testing should be separate I have moved the discussion to Development Team as that is the category to discuss current development and also keeps one place to check what is going on with this driver testing.
@billb and @OXINARF
All fine! Thanks so much for all the work you are putting into this!
@Thorsten et al. Just another thing about discourse forum software is that if you start a thread, you can ‘invite’ people to participate. I’d suggest that if you raise a topic about your testing of ‘in-tree-sensors’ you invite @tridge to the conversation.
I have an SPRacing F3 Mini, which is STM32-based. I’d be happy to test out the drivers and other firmware on this board. I have been eager to use this board on a Tali H500 hex-copter, since I fried the mainboard.
I have pushed a new version of the fast sensor code to master now. It now uses DMA for SPI which greatly reduces CPU cost, and uses a new strategy for filtering.
Please test if you can!
Great, and extremely admire you,