By chance I noticed that there is a notice on the CubePilot “discus” forum about required ArduPilot settings for Copter. Mine were correct except for EK3_IMU_MASK - mine was set to “3” - the CubePilot cautions says it should be “7”
The language on the CubePilot warning has language about ArduCopter 4.x. I don’t understand this - does this warning apply only if 4.x is being used?
There’s also mention of SB2 parameters. I don’t know what these are - can someone please explain what SB2 parameters are?
I’d be embarrassed if there was something in the docs or ArduCopter 4.x release notes that explains this. Can someone point me to a reference I may have missed?
It is related to that Service Bulletin number.
So you should have
EK3_IMU_MASK,7 (or EK2 if using EKF2)
INS_USE,1
INS_USE2,1
INS_USE3,1
on any Cube whether it is Orange, Black or Blue
Thank you Shawn. I had suspected this might be the case.
I’m glad that CubePilot releases Service/Safety Bulletins. I’m not familiar with other hardware vendors doing so - so didn’t think to check.
I did a google search of “ardupilot documentation ek3_imu_mask” and got no hits. I know ek3_imu_mask on the parameter’s list documentation - but its listed as For Advanced Users.
Since so many ArduPilot users use CubePilot flight controllers, it might be worth a mention here:
This is now default for CubeOrange on master. Along with a change to ensure the non-isolated IMU gets used according to the service bulletin for every single cube.
Thanks for adding the PR! This begs one further question - in a moving base configuration (GPS-for-yaw) with EK3_IMU_MASK=7, is it also preferable to set the following GSF masks?
The answer to this is likely beyond my scope of practice (yet)
Yuri, I’d trust what you have to say about GSF more than what I know
However, the simple answer is if you want GSF enabled on each EKF lane then yes you want to do this. There could be arguments for not enabling all the exact same sensor_MASK and USE_sensor_ZZZ for each EKF. (But again a bit beyond my knowledge in ArduPilot.) Depending on the vehicle type it could give some safety to failures to have some differences in how the EKF builds its estimate.
And again take this with a grain of large salt as someone more knowledgeable will likely correct me with best practices.
I should think it’s preferable to have all IMUs providing yaw solutions. Resource preservation is the only reason I can fathom to disable GSF on one or more IMUs. I did not yet review any logs, but I noticed no ill effects during several hours of running my mower yesterday with all three IMUs enabled + GSF on each (Cube Orange).
Unless I discover something very strange in a log review or that “more knowledgeable” source chimes in to the contrary, I will enable all 3 IMUs identically and recommend the same to others.
UPDATE:
A review of yesterday’s log shows very good performance from IMU2. The estimates and innovations are near identical overlays of the other two IMUs, which I take to mean that under normal conditions, that IMU provides reliable, predictable output despite its lack of isolation/damping. In fact, a review of IMU2 vibration almost inexplicably shows values generally slightly lesser in magnitude than its isolated counterparts.
Nice! For a mower/rover I can think of no downside.
My caveats were more for flying things An argument could be made that on the hard mounted IMU (the safety IMU in case the ribbon cable gets loose) to use conservative EKF options that will get you home/land/etc. safely.
What conservative means in terms of ekf options would likely depend upon the system use case?? And would require a lot more knowledge on my part to say. I’d lean towards it will be fine.
To me the question comes down to the case when an IMU is not fine or another part of the EKF sensor fusion is not fine. You would want to have a state estimation fallback that is safe even if less accurate.
@rmackay9 Do you have opinions on copter to enable GSF for all IMUs on say the CubeOrange?
My understanding is that the only reason we didn’t enable GSF on all EKF cores is just that it is quite resource (CPU + memory) intensive so many autopilots won’t have the ability to run more than one.
I can imagine that it would work on a Rover with a 50hz update rate (and probably Plane as well) but Copter at 400hz might struggle. The PM messages should show whether the main loop is running slow (aka “long loops”) or not. I also worry a little bit about some of the background task used for Bendy Ruler object avoidance. It is a little tougher to know if these are being impacted or not… but if avoidance still seems to work then it should be ok.
That all makes good sense. I know the Cube Orange is well suited to satisfying heavy resource demand, and I try to take full advantage of that. During my mowing yesterday I had 3 Lua scripts running alongside BendyRuler, all while all three IMUs were unmasked+GSF. I noticed no ill effects. I can go back and look at the PM messages I suppose.
I ran 3 short test sessions today and uploaded a log for each. I ran the first two with scripting disabled just for my own curiosity, then enabled scripting (with my usual 4 scripts running) on the last one. I really don’t see any red flags at all, but maybe someone else will find something noteworthy.
A bit off topic - Randy and I have discussed this briefly before - you’ll see that I have ARMING_CHECKS=0. I just can’t find a way to enable any arming checks whatsoever and use fences without having a prearm check fail until the GPS position is fully initialized. My mower is stored in a garage, and I need to be able to arm and drive in MANUAL mode without GPS.
That might be a project for another day if there’s further interest here. I have a build environment set up, but building, reloading firmware, and re-testing is a little beyond the time I have to devote today.
