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:
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.
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.
Great job.
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
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
@billb
Hi Bill,
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”.
Cheers,
Thorsten
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.
@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!
