I’d be very interested on using Reach for walking people in urban environment. First of all, is it suitable for this kind of application? IMU integration during GNSS outage would give to the unit the required position accuracy. When will be available this integration, within next 6 months or later? Which kind of integration have you in mind (e.g Extended Kalman Filter or other)? Will be the heading, included at static conditions, and the person speed available at the output during GNSS outage and which will be the respective expected accuracies? Thank you
2 Likes
Hey Emlid,
any news on the IMU integration? If I remember correctly you said you are likely to do the integration in he future…
Hey,
No news so far, we still aim to do it, but there are other priorities at the moment.
Thanks for your reply. I can understand your priority was/still is RTK application in UAV/drone sector where there mostly is clear sky and no obstructions so the RTK solution is stable. However, I am not the part of the numerous drone crowd and am interested in urban ground applications where the sky is usually not that clear. I hope you will integrate the IMU soon :).
Side note: I asked Swiftnav the same for Piski Multi and they told me the target their IMU integration for mid next year.
I carry an Oblu (https://www.oblu.io/) when doing foot surveying and integrate the tracks in post processing. It is particularly useful for working in and out of trees. Over short distances the oblu works really well and most importantly confirms when you are stationary. I develop an error estimate for the reach position (the estimates from RTKLIB are not realistic for float, but good (most of the time) for fix) and when it exceeds a given threshold go back to last good (within threshold) position and use the inertial navigation from there with an error estimate that increases with time and distance. For mapping of field archery ranges I try to keep the overall solution to within 1m. That gives me about 80-100m from a GNSS FIX solution that I can ‘fill in’ with oblu data and in theory another 100m if I am sure of a fixed solution at the end. I.e. the uncertainty is constrained at both ends.
The oblu has 4 imus onboard and uses the zup point every time you put your foot down to reinitalise the problem. Having a single IMU on the reach is unconstrained and noisier, so not sure how much help it would be except as part of the RTK calculations, maybe constraining acceptable solutions? As part of an EKF you are in danger of needing two position log files. The RTK only solution and the EKF solution as the latter would not be reproducible in the current post-processing software.