How can I estimate IMU and baro _NSE paramters for potentially getting better dead-reckoning without GPS?

Hello,

So basically what the title says. Should I log the telemetry after keeping the drone still and then do some data processing?

Thanks

Hi @StrikeEagle,

I guess you’re using Copter with Windspeed estimation enabled?

I must admit that I’ve never modified the EK3_ACC_P_NSE parameter but I think it is only used for the attitude estimation. So the attitude estimation is done based with the gyros and then the accelerometer values are only used to slowly correct the attitude estimate. So I don’t think changing this parameter will affect the position or velocity estimate… I think those always use all the IMU data.

If you’re trying to do high-altitude non-GPS, I think the best solution we have is high-altitude optical flow which I demonstrated at the latest dev conference and there’s a blog here about it.

Well, no, it’s for an indoor drone. Will also eventually use optical flow so I guess it would be best to also estimate it’s noise parameter?

Now, the barometer altitude estimate seems more important for me because that’s the only primary altitude sensor so I was thinking I can keep the copter still for about half a minute or so and then compute the RMS error considering the starting altitude as the baseline

So you mean that it only matters when the IMU is off-center because that’s probably when there’s also a considerable amount of acceleration in addition to rotation?

Hi @StrikeEagle,

hmm… I don’t quite understand the assumptions behind these questions.

I suspect you’re not actually talking about ā€œdead reckoningā€ which involves estimating the position without an absolute position source. You probably just mean that you want the copter to not drift very much when its flying in AltHold indoors.

To keep it simple, updating the noise parameters is very unlikely to help.

For a vehicle to fly in a controlled way indoors (e.g. Loiter, Auto, etc) the vehicle really does need to have an external sensor like an optical flow or one of the other sensors listed on our non-GPS navigation page. An IMU alone is not enough to estimate the vehicles velocity and position. This question has been asked many times and the answer is always, the IMUs in today’s autopilots have too much noise to allow estimating velocity and position on their own. Only very very large and expensive IMUs (like those in submarines and space stations) can do it all on their own.

1 Like

Well, I was just asking whether these paramaters do improve the EKF estimate as it can fuse the sensor readings better.

Yes, I know you can’t navigate with just an IMU. I will add an optical flow sensor. Just wanted to have a good pose estimate as much as I can from the EKF

Maybe a bit, nowhere close enough match navigation grade IMU that cost as much as a car and weights more than most indoor drones.

Yeah I don’t certainly need that level of estimation. Like I said, its the baro data I’m most interested about. I see that ā€œAHRS2 Altā€ in the tuning tab does fluctuate but the average value over 5-10s seem to show the exact altitude the drone is at. I don’t know whether this is also the vertical position used by the EKF or if it does a better estimate than AHRS2 (I do not see an ā€œEKF altā€ parameter). Anyway when I tried althold manually, the drone seems to hold altitude pretty well, but I don’t know if it will correctly move to the correct altitude indoors autonomously, so I was just asking this question to potentially obtain better flight performance indoors.

Any idea if I can adapt the RealSense navigation algorithm for a single RGB camera on a ground station based companion PC running a monocular depth estimation model so I can use the depth estimate from the model and then send navigation commands back to the drone instead of doing it onboard? Or would other SLAM methods be better?

I have also been trying to get reliable baro readings for altitude hold when lidar is unreliable flying indoors with cluttered floors.

There are some params that helped the baro, but ultimately it came down to baro temp calibration which, according to Andy Piper, is not where it needs to be.

Why not just use a good 360 lidar unit and one for altitude?

You need moderately flat floor (or ceiling) for lidar for altitude to work or it will jump up and down when overflying obstacles.

That’s our project. Navigation using just a single camera

To be honest my drone’s altitude holde which primarily uses the old MS5607 inside the Pixhawk 2.4.8 has turned out to be really accurate both indoors and outdoors. But I see oscillations in the barometer (with the average altitude being stable) logs but I guess it’ll only be good if you try to bring the expected error to a more real value. Now that I have a rabgefinder, I am thinking of using its altitude as the ground truth and calulationg RMS of the baro from the logs although this is not a priority for me now.

About the baro calculation, I managed to be able to do it once but since then, I had to reset that parameter and am not able to do it again. Maybe baro calculation required a wide range of temperature to be logged and the needs to be placed in a very calm environment? The docs say that Pixhawks do not need to do baro calibration maybe because the MS5607/5611 come calibrated from factory?

@StrikeEagle the baro temperature calibration uses the exact same principles as the IMU temperature calibration:

  1. configure it to do the calibration ( set TCAL_ENABLED to 2) and power it down
  2. cool down the board
  3. power it up in an environment with no movement whatsoever and no air pressure changes what so ever ← this is very important and not stated enough in the wiki
  4. wait 30 minutes
  5. set TCAL_ENABLED to 1
  6. done

As always AMC lets you do this and guides you step-by-step.

I tried this many times. TCAL completes way less than 30 minutes though. Is that a problem?

No, none whatsoever. But you must avoid moving the board and opening/closing doors or windows in the proximity.

Did you cool down the board to -10 °C or so?

1 Like

Nope,

So maybe the one time this worked was when I did cool ot to -20 deg.

I’m not inclined to do this again because 1) I have already attached my autopilot and 2) I’m not exactly sure that the high humidity levels here at my location would be good for the electronics as they come out of the fridge. I do have a packet of silica gel but even then I’m not really confident to do it.

Would have been good if I could change the barometer calibration parameter manually to the old value but it’s read only

I now got it again. I went for a temperature delta of more than 20 deg and kept the drone in a place with no disturbance and now the baro calibration is done