In several posts about using LOITER without GPS, the requirement of setting the EKF Home Point is mentioned.
I don’t understand why this might be necessary - and in fact, how it is possible?
Without GPS, there is no latitude or longitude data. So even if the EKF Home Point is set on Mission Planner - it seems to me that this has no use to the Autopilot.
So for example, if a copter were to operate in an indoor arena with no GPS, but using any of the optical/rangefinder devices - how would EKF Home Point be necessary or applied?
This is mentioned in the Optitrack page but I have never tried to do it.
I agree that I’m not sure how to do it either.
" In order to take off in guided or auto mode, you need to use GPS_GLOBAL_ORIGIN to set the GPS location of motion capture system origin. It is not need to be accurate, any valid lat/lng is ok."
Try right clicking the map in Mission Planner and using Set Home Here → Set EKF Origin Here.
Again, not my specific area of expertise, but in the interest of giving you a potential path forward without waiting for more replies, I think the above works.
And the point is to give the EKF a place to start. So like @Tristan_Redish says, it need not be perfectly accurate unless you are trying to do dead reckoning nav with absolute accuracy.
I appreciate your efforts to help - even if not your specific area of expertise.
I don’t know who is such an expert, but I tend to address questions on this area to @rmackay9 because he has been involved in demonstrating optical flow.
OK - so here’s what happens:
I set GPS_TYPE=0 - to disable the GPS.
(BTW - After disabling the GPS, if I don’t also change the references to GPS in the EK3 parameters to something else, I get errors)
The proscribed EK3 Parameters for optical flow are this:
I go head and use Mission Planner to set the Home Point - to the place the copter is depicted on the map. Now I get a new message: “Need Position Estimate”.
Notice that selecting Loiter is allowed, and the EKF status is showing green.
So at this point I’m stuck - the copter can’t be armed.
I have a feeling when this is sorted out, we’ll benefit from what we’ve learned. If you know of anyone who might be able to help, I’d really appreciate your reaching out to them.
I’ll defer to Randy, whom you’ve already tagged. Your Copter appears configured correctly as far as I can tell, and you’ve done everything I’d try to make it work.
AP needs to have an EKF origin set so that it knows where it is on Earth for a few reasons:
so that it can run Auto missions (these are always in lat,lon,alt), use RTL mode, etc
so that it can check if the compass vector length is sensible or not
It’s possible that we could remove these dependencies but it could be tricky.
It’s not necessary to set the home location manually. It’s set automatically once the EKF origin has been set and the vehicle has a position estimate.
So the real issue is that the EKF doesn’t have a position estimate. There’s a decent range finder connected and working? The rangefinder on most optical flow sensors is not usable due to its short range. I honestly wish the manufacturers would not even include them because it just leads users astray thinking they can actually be used.
As I recall it was a graduate student of @tridge who wrote EK3. We may need their help.
Indoor navigation - or any navigation without external references such as GPS - can be handled by an Extended Kalman Filter.
The difference is that with external references, you can determine “absolute” positioning. And without external references, positioning is relative. Also - without external references, position identification degrades over time.
My understanding of how Optical Flow works - it detects change. This should be perfect for Extended Kalman Filter processing without an external reference.
To that end - all that should be required is a starting location - and that location can be anywhere - it’s simply the 0,0,0 point on the X, Y, and Z axis. The autopilot can simply set that at the beginning of operation.
If ArduPilot is to handle this - the EKF “home” should simply be any point where a mission starts.
As I illustrated in my series of screenshots above, I am unable to get ArduPilot to ARM with the GPS disabled. Until I resolve that, indoor navigation is impossible.
So if indoor navigation is to be accomplished - either I’m doing it wrong - or ArduPilot does not have that capability.
Instead of guessing at what’s possible, and what’s required, I think we need help from the DEV team members who are most familiar with this topic.
Other than @tridge I don’t know who those people might be. Can you please reach out to them for their help?
Before calling for graduate work, multiple developers, and code changes…confirm the rangefinder is working and is outputting a valid value on the ground.
I have one that likes to show nonsense on the ground due to the close proximity. But as soon as I take off, it works. Something like that would very likely cause a position invalid flag for optical flow.
There are many examples of indoor navigation scattered about the community here. It’s definitely possible.
The prearm error is a position one. Lack of proper rangefinder data when using optical flow may cause that. So if it wasn’t working or was outputting erroneous values, it would account for the position invalid flag that is preventing you from arming.
The input I’ve received is that FlowHold doesn’t require a rangefinder. Loiter doesn’t either - but when using optical flow, it works better with it.
I’ve read nothing to suggest existence of a rangefinder affects arming. But no doubt - I’m hoping learn how this is supposed to work. I appreciate your enthusiasm for the topic.
Could you provide an onboard log? I think it may be necessary to set LOG_DISARMED = 1 in order for it to appear without the vehicle being armed.
A few corrections and clarifications:
the EKF was written by Paul Riseborough not a graduate student of Tridge’s. I suspect you’re thinking of the more recent work with ANU to create a DCM replacement
we don’t need an EKF expert to resolve this. Optical flow is well understood and as Yuri says many users are using it successfully.
The home point is different from the EKF origin. Home is where the vehicle returns to when doing an RTL. Users can freely move home around and it has no effect on the EKF. The EKF origin is set once either manually by the user or automatically if a GPS is present
As mentioned above, AP does require an actual lat, lon, alt because the compass may be used (even for indoor flights) and it checks the magnetic field strength vs a small built-in database that helps protect against magnetic interference
to use an optical flow sensor with Loiter (or any other mode that automatically holds position) a rangefinder is required. Flow Hold is the exception but it’s not recommended in any case.
I’m sure we can get this all working and the issue is most likely with the sensor (optical flow and/or rangefinder) or a parameter configuration issue
I’ve collected a BIN file from the procedures outlined in the screenshots above - plus I included movements that verified the function of the optical flow sensor and the rangefinder.
To help with this, I made a video of the session and have uploaded it to YouTube.
Regarding EKF’s need to know Lat/Lon in order to consider magnetic variance around the world, this is entirely unnecessary for indoor navigation. In fact, the magnetic disturbances from metal in the environment are likely more of an issue.
Using relative positioning (dead reckoning) the starting point and be defined as ANY Lat/Lon - as navigation will be relative to that point. When Lindbergh flew from New York to Paris using dead reckoning he did need Lat/Lon in order to correct for magnetic variance - and he had to continue to adjust for magnetic variance as the flight progressed. But in a gym, arena, tunnel or cave - the distances simply make changes in magnetic variance undetectable.
Regarding magnetic interference, you may find it interesting that airline pilots have to disable their compass when departing runways known to have a great deal of rebar in the runway structure. They use gyros aligned with the compass heading until after the takeoff. (I always felt this was a pain in the ass to do.)
Thanks for the log. I think the issue is the RNGFND1_MIN_CM is 5cm but the rangefinder is reporting 2cm when on the ground. This means the rangefinder is out-of-range and so the EKF will not use its readings and then cannot fuse the optical flow measurements to calculate a position estimate. Could you try changing RNGFND1_MIN_CM to 2?
Changing RNGFND1_MIN_CM to 2cm did indeed resolve the problem. (I also tried raising the copter to above 5cm and that also solved the problem.)
I had selected 5CM because the CubePilot docs stated that the HereFlow had a range of 5cm to 200cm.
I’ve uploaded a video showing that the copter can now arm in Loiter with the GPS disabled:
And I’ve uploaded the log from this event:
This is a great step forward for our mission of equipping STEM students with ArduPilot copters for indoor flight.
There are two further hurdles I’ll be trying to resolve next - and as your time and interest allows, would greatly appreciate your further assistance:
How to set EKF Home without a physical connection to Mission Planner. Wireless telemetry enables this - and there are several options for that. But as I mentioned in my previous comments, the magnetic variance is not an actual issue for navigation. It certainly is important for GPS navigation beyond a few yards. But for indoor navigation in small spaces - it’s irrelevant.
I would propose a possible work-around. I propose adding parameters that allow the operator to enter the local magnetic variance and a parameter to use that entry instead of it’s own look up table based on lat/lon.
An alternate might be to have parameters allowing the operator to enter the initial lat/lon.
The ArduPilot wiki states that AUTO modes are not recommended for indoor flight:
For STEM students to create projects where their copters act robotically, some level of autonomous flight will need to be enabled. Basic movements in the X, Y, and Z axis, along with yaw, need to be enabled.
I have a few ideas about this - but I’d like to have the benefit of the others who’ve worked on autonomous indoor flight before initiating work on my own ideas.
Once again, thank you for your support on getting this issue resolved. I’m hoping the efforts on this work will benefit many others.
I think that wiki page is intended for users who don’t have any position or velocity sensor.
Auto modes will all work with the optical flow. I’d recommend putting an additional rangefinder on the vehicle - perhaps the lightweight benewake TFmini which has a 7m range.
I did a fair amount of code searching throughout this exercise and feel fairly confident now in my understanding.
I think the best way forward is to use the script to set the origin and perhaps make some wiki updates to reflect the lessons learned here. The fairly minor doc updates can easily be done with the quick edit instructions.
At the end of the day, ArduPilot’s autonomous and semi-autonomous modes are generally position dependent, and the codebase along with this configuration underscore that. Rather than making a bunch of nuanced software changes for a fairly small/niche use case, we have a script that provides a solution, which is in line with AP philosophy when handling such use cases.
EDIT: @rmackay9, I can think of a potentially simple software change to consider, since indoor flight is likely to be attempted by those with the lesser capable autopilots. We could provide an aux function that would set the EKF origin to the home waypoint of an uploaded mission. That would avoid the need for a script…but still require a GCS. However, once any mission is uploaded, its persistence across reboots would provide an easy way to initialize in the field with minimal hardware at hand.
The aux function setting the EKF origin is an interesting idea. On it’s own I’d definitely support that but I think we’re at the point now that if the user is going to try and do anything non-standard they need to invest in an H7 based autopilot. There are very reasonably priced H7 autopilots these days so I don’t think it’s too much to ask
