Hello,
So basically what the title says. Should I log the telemetry after keeping the drone still and then do some data processing?
Thanks
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.
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?