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.
I concur. This is the best 30x30 FC you can buy. The IMUF gyro filter is really amazing at rejecting noise.
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. 
I am also one of the engineers on the Helio team and will do what we can to help.
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.
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
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.
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.
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.”
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
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
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.
yes, that would be the best approach for an initial port at least. It should be pretty simple.
ok, thanks!
Any update on the build for the Spring? I’m excited! 
sorry for the delay, I did start on this, then some other urgent things came up I needed to deal with. I hope to get back to it in a couple of days time
Man, I’ve spent too much time away from ArduPilot. I’ve been thoroughly enjoying the last few weeks of playing with ArduPlane and ArduCopter. I’m dying to see how the IMU-f works with it. Thanks for your help, @tridge! 
@rs2k his so great news IMU-f spring maybe get support in ArduCopter I have so many people waiting to test it and I would like to say a very big thanks to you Andrew Tridgell you can make it happen and all the hard work you do in the rc world
many thanks, 3dracingman
@rs2krs2k after a busy few weeks I finally got some time today to look at the HelioSpring board. Sorry for the delay!
I’ve put an initial branch here:
https://github.com/tridge/ardupilot/tree/pr-helio-spring
the bootloader works fine, and I can build and load the INS_generic IMU test firmware. It doesn’t talk to the IMUF though. I have a few questions for you:
in the doc you sent me the SETUP command (122) has 11 words total (command + 9 params + crc). In the butterflight code it has 13 words (command + 10 params + crc + tail). Can you check which is right?
the doc doesn’t mention the commands sending replies. Does the setup command send a reply? If so, how do you check the reply? The butterflight code assumes it does get a reply, and that the reply command should equal the sent command, and reply CRC is correct (calculated against 11 words)
The (non-working) driver is here:
That’s great! Thanks for taking the time to do this and Happy New Year!
I’m sorry for the trouble. I neglected to put the information about the replies and I missed param 10 and tail. I’ve fixed the IMU-f documentation. Please let me know if there’s anything else I can help you with.
Adding in the 10th’s param and tail will probably fix it. The IMU-f won’t communicate correctly if the CRC is wrong, and the CRC will most definitely be wrong if only 9 params are being sent.
There are two replies for every command sent to the IMU-f in setup mode. The first reply is included in the data received from the IMU-f when the IMU-f is first sent a command during a full duplex SPI read/write. It will either read 108 “IMUF_COMMAND_LISTENING”, or 32 “BL_LISTENING” and is there to tell you the IMU-f was listening for a command when the command was sent.
When the SPI read/write completes and you received either 108 or 32 then set the command word to 0 “IMUF_COMMAND_NONE”, recalculate the CRC, and do another SPI read/write to verify the IMU-f got the command successfully. The IMU-f will set the command word in that reply to the command you originally sent.
Example:
I send IMUF_COMMAND_SETUP along with a setup packet and a CRC and during the SPI transaction the IMU-f sends IMUF_COMMAND_LISTENING.
I then send IMUF_COMMAND_NONE with a CRC and during the SPI transaction the IMU-f sends IMUF_COMMAND_SETUP to verify it received and was able to work with the command you sent it.
When you send the second SPI transaction you can just set the command word and calculate the CRC. What’s in the packet and tail doesn’t matter but the CRC should still be calculated based on what’s in the entire packet.
While SPI is full duplex due to the speed of the STM32F3 and the rate the SPI can run at it was important to break up commands into two SPI transactions since trying to handle the setup data during an SPI transaction running at 24 MHz was pretty much impossible on an F3.
Thanks for the doc update!
How much of a time delay is needed between the two commands?