Servers by jDrones

Helio Spring IMU-F


(Richard Joy) #1

My first post on this forum so let me know if this is the right place for this type of question.

I would like to know if this flight controller is a viable candidate to run Arducopter on Chibios.

Its a bit different from some of these types of controllers since it has both a F4 and F3 processor. The F3 is used to filter the gyro data prior to sending it to the F4 so wondered if this would be an issue.


(vosair ) #2

I concur. This is the best 30x30 FC you can buy. The IMUF gyro filter is really amazing at rejecting noise.


(rs2krs2k) #3

I’m one of the developers of the Helio Spring and the IMU-f. I would absolutely love to see this happen. I’ve been using Arducopter and Ardupilot for years on both airplanes and multirotors with the pixhawk and and dying to see how it performs with the IMU-f. If any of the Ardupilot developers want to help we’d love to send Helio Spring samples and offer any help we can to make this happen. :slight_smile:


(Tim Sweet) #4

I am also one of the engineers on the Helio team and will do what we can to help.


(Peter Hall) #5

I guess it would require a driver to be written to interface with the F3 and treat it as a gyro sensor. Or alter the F3 firmware to pretend to be a gyro that is already supported. Porting the rest should be reasonably straight forward mapping of pins.


(rs2krs2k) #6

The first option would be most optimal because of how the SPI on the STM32F3 works, but option two is possible as well. It would be pretty simple to make the STM32F3 emulate something like an MPU6000 at a slower SPI frequency then we normally run at on the SPI communication that happens between the F3 and F4.

If we wanted to go about option one, where’s a good place to get started. I’m not familiar with the project’s code enough to make a driver or even add a target yet, but I’m happy to learn.

Please correct me where I’m wrong, but not counting the addition of a target, it looks like at least these files/folders would need to be modified:
AP_InertialSensor/
SPIDevice.cpp
decode_devid.py
board_drivers.cpp


(Peter Hall) #7

I have been reading abit more about your board, ’ Highly advanced filtering at 32khz and quaternion output at 16khz’ So the F3 gives the F4 quaternions? If that is the case you may be better setting it up as a external position estimate as is done in motion cap rooms. You will have to be careful the filtering the F3 does does not upset the EKF. I’m not sure how its handled on beta flight.

Essentially you have two steps, I guess you could do the port first and get it working with no inertial sensor, or a external one. Then add the new driver.

I don’t know much about driver stuff I suggest you talk to the people on gitter.


(rs2krs2k) #8

Yes, quaternions are an options as is filtered Gyro and unfiltered ACC. I’m interested to see how the KF in the F3 will interact with the EKF in Ardupilot. The filtered gyro readings are significantly more accurate than the gyro readings the EKF normally gets so some tweaking of the EKF settings may be in order to get best results.

That’s an interesting idea on using it as an external position estimate. I’d love to see how that works. Thank you for the gitter link. :slight_smile:


(Tim Sweet) #9

Ideally you’d want to bypass the filtering in Ardupilot all together like we do in other firmwares. Use the gyro readings from the IMUF co-processor “raw.”


(tridge) #10

I’d be interested in trying a port if you can send me one. Can you send me the schematic as well?
Alternatively, I could help you do a port yourselves. That would actually be the best approach if you are willing as you are best placed to test and get the most out of the board.
From the butterflight code, it looks like the F3 is connected over SPI, with a GPIO for reset. I had a quick look through accgyro_imuf9001.c, and some parts of it are clear, but some bits are a puzzle. For example imufReadAccData() is a no-op, so where is the data actually read?
I see gyroFrame_t and imuCommFrame_t which look like the structure for IMU data, but I don’t see any place where they are used. Is butterflight master the right branch to look at, or is there a document somewhere that describes the protocol?
Cheers, Tridge


(tridge) #11

I doubt that would work well as I don’t think the IMU on the F3 has any means of doing inertial corrections (which normally come from GPS), so I expect its attitude will go off if you are in a sustained turn.
It would be interesting to log its quaternion solution and compare it to the quaternion from the ArduPilot EKF though.
Cheers, Tridge


(rs2krs2k) #12

tridge, thanks for the input, I’ll definitely make sure you get some Helio Springs to help out with this. I’ll PM you for details.

I was thinking the same thing. Inertial corrections aren’t present in the IMU-f as there’s no mag or GPS data for the F3 to work with right now. The two ways to handle this would be to send them to the IMU-f or to just send Arducopter the gyro and ACC data only. Since the gyro data is pretty accurate coming from the IMU-f, my thoughts were filtered gyro and raw ACC would provide best results.

We’re lacking protocol documentation since butterflight has been changing quite a bit, but I can get you whatever details you need and can make changes if necessary to make this work well.


(tridge) #13

yes, that would be the best approach for an initial port at least. It should be pretty simple.

ok, thanks!