ArduPilot: Loiter item support for 0/0 lat/lon

[marcmerlin]

As explained in ArduPilot/ardupilot#2811, both mission planner and Qgroundcontrol treat a takeoff mission as if it were navigation to gps coordinates 0,0, drawing a long line to nowhere.
Apparently only mission planner gets this right

[DonLakeFlyer]

Can you try with a newer Daily Build: https://docs.qgroundcontrol.com/en/releases/daily_builds.html

[marcmerlin]

@DonLakeFlyer exactly the same problem I'm afraid (just checked)

[DonLakeFlyer]

Can you save the .plan file and attach here. Zip it to attach. A takeoff mission item for ArduPilot should have not GPS location associated with it.

[marcmerlin]

There is is (pasted and attached):
QGC WPL 110
0 0 0 16 0 0 0 0 0 0 0 1
1 1 3 22 15 0 0 0 0 0 50 1
2 0 3 17 0 0 1 0 0 0 80 1

takeoff.txt

[DonLakeFlyer]

This is because you are loading an MP format waypoint file while not connected to a vehicle. Because of that QGC does not know what firmware and/or vehicle type you are expecting to use this mission for. QGC needs to know that because for example the different firmwares/vehicles treat various mission command differently. If you were connected to a vehicle when you loaded this mission it would have worked correctly.

When not connected you need to tell QGC what kind of vehicle you are using through the Vehicle Info section fo Mission Settings. This will then be remember si you shouldn't have to do it again.

[marcmerlin]

@DonLakeFlyer I'm not sure your explanation is related to the issue I reported (although I'm sure it's true on its own). Could you reopen?
Here's what I did, showing that it should know what veihicle it's for:

1. I connect to my aircraft with qgroundcontrol
2. qgroundcontrol downloads all the parameters and mission
3. it displays the flightplan showing a flight to gps 0,0 as per the screenshot above
4. I never loaded the flightplan from disk, it was downloaded from the aircraft
5. the flightplan works fine, the aircraft does not fly to 0,0 and mission planner does display it correctly.

So the problem is definitely there, isn't it?

[DonLakeFlyer]

Are you using a daily build?

[DonLakeFlyer]

Sorry I missed the fact that your screenshot has a vehicle on it.

[marcmerlin]

@DonLakeFlyer, you asked me to try a daily build, I did and still had the problem (comment #3). Do you mind re-opening this issue?

[DonLakeFlyer]

After you connect the vehicle and it loads the mission. From the Plan view, can you tell me that the Vehicle Info section of Mission Settings says?

[DonLakeFlyer]

No wait. Your loiter item has a lat/lon of 0/0 and an alt of 80. The screen shot above seems correct for that waypoint file.

2 0 3 17 0 0 1 0 0 0 80 1

[marcmerlin]

Yes, there is 0,0 in there for sure, but it's supposed to be ignored for loiter since it loiters in place, whereever it happens to be.
You can try it out with mission planner if you'd like to compare.
I can see if I can ask @magicrub to join in (he's not on this project, so I can't summon him :) ).

[WickedShell]

0, 0 does mean use the current location, ArduPilot/ardupilot@bf5005103c although I admit I would have assumed thats:
A) Not the case
B) No one documented that on the MAVLink command anywhere, which makes it entirly fair that QGC didn't catch it
C) This is awful for a GCS as it's hard to show where the point will actually be...

I guess at the end of the day, we explicitly support it, but I'm left with a giant question as to why :)

[marcmerlin]

Thanks @WickedShell . First it confused me a bit, but then I thought about it:
loiter is not a move to command, it's explicitly a command that says "capture current GPS position and loiter here". Given that, GPS coordinates for a loiter command have no meaning, so using 0,0 is not that unreasonable :)
I'm assuming it's the same thing for "takeoff" which basically is "capture current heading, take off at angle X, keep heading until target altitude captured, then switch to next command". There again, GPS coordinates have no meaning.

[marcmerlin]

@DonLakeFlyer another weird one you may not need to support, but I'll mention it in passing.
Ardupilot does not support a minimum altitude to trigger GUIDED mode, unless you also draw a perimeter and set an altitude for it.
Because I don't want the lateral limits for the geofence nor do I want to draw different polygons when I go to different locations, I've just drawn a geofence polygon that is bigger than the US, and set the minimum altitude in there.
This allows me to have an altitude deck (à la top gun :) ), regardless of where I go.
As a result, zooming out to the size of the geofence, at least in my specific case, is not desirable either.
But given that I may be one of the very few (if not only) person doing this, don't worry about that one too much.
Hopefully AP will eventually support an minimal altitude limit for GUIDED.
For now, I've documented the status quo in ArduPilot/ardupilot#2984 (comment)
(this is to explain why you're seeing a crazy big geofence in the screenshot I posted)

[WickedShell]

@marcmerlin The primary way loiters are used is loiter at this location :) The reason I think the current position is unreasonable is more that from a path planning perspective it's hard to say where exactly the aircraft will actually loiter until it flies the mission :) But thats just my opinion as an operator and I have no intention of arguing to remove it from the autopilot :)

[DonLakeFlyer]

0, 0 does mean use the current location

Total bizarreness. I don't plan to support that.

GPS coordinates for a loiter command have no meaning

Yes, they do. They mean go to the specified location and loiter there. All loiter commands work this way and support a gps location.

[magicrub]

Confirmed, all NAV_LOITER* mission items will treat lat,lng (0,0) as current location. Otherwise, what would you do; fly to 0,0? No... Never do that.

[marcmerlin]

@DonLakeFlyer I was wrong about the loiter to GPS location thing, sorry about that.

@magicrub if qgroundcontrol isn't going to support loiter in place, can you confirm that there is no other way to write a generic takeoff flight plan that will just work anywhere and that I should either learn to ignore all the flightplan displays from qgroundcontrol if I'm going to use it, or just use another GCS instead?

[magicrub]

If you do this: TAKEOFF RTL As long as you don't have a DO_LAND_START then it'll loiter above home. Obviously, the best solution is the TAKEOFF flight mode. Not sure if we can get that in v3.8 but maybe we can do a quick v3.8.1 with it.

…

On Sun, Jun 11, 2017 at 10:38 PM, Marc MERLIN ***@***.***> wrote: @DonLakeFlyer <https://github.com/donlakeflyer> I was wrong about the loiter to GPS location thing, sorry about that. @magicrub <https://github.com/magicrub> if qgroundcontrol isn't going to support loiter in place, can you confirm that there is no other way to write a generic takeoff flight plan that will just work anywhere and that I should either learn to ignore all the flightplan displays from qgroundcontrol if I'm going to use it, or just use another GCS instead? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5272 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEj7G5AEyTRzm2Y_JWjlllRwnNqH-6nrks5sDM64gaJpZM4N13gG> .

[marcmerlin]

Thanks @magicrub . Sadly that's not safe for some fields (the trees at baylands are very tall) and others like Rancho San Antonio will get you a ticket from a stupid ranger for overflying the area just behind you which is no fly zone.
The current solution I have (and you gave me) is by far the best and safest, it's just too bad that some GCS don't handle it correctly. Oh well, I'll just do without the GCS, safety goes first.
(I suppose I can probably work around it with rally points for each field, but it's not as flexible and they make me a bit nervous because when I RTL after a total loss of signal and video, I don't like having to look in 2 different places for where the aircraft might come back)
Thanks for your reply.

[WickedShell]

@marcmerlin why is planning a mission with an actual location for the loiter to burdensome? I don't understand how if you already have a GCS with you this is to difficult to do, which has the added bonus of being able to explicitly state where the aircraft will fly?

[marcmerlin]

@WickedShell I use the GCS for track recording and sound feedback of what's going on with the flight until I can get mavlink to go through my openlrsng system via the gitsly branch and directly on my taranis.
I'm sure it's not difficult to use the GCS to plan a flight for each time I fly, I just don't use it for that. For me, AP is there to assist with the flight slightly, but I'm the one hand flying everything otherwise.
I don't have flying robots, I have planes with backup autopilot :) (and use takeoff mostly to throw planes safely and more reliably than me jumping back on the controls after a hand launch that's never quite the same twice and a CG that could be off quite a bit from last flight, something AP deals with much quicker than I can).

[DonLakeFlyer]

There all seems like an uncommon use case which I may at some point try to support. But for now, changing all the algorithms to handle this 0/0 just doesn't justify the work.

[magicrub]

How does the PX4 autopilot handle waypoints and/or navigation points at 0/0? Does it navigate to it?

[DonLakeFlyer]

No special handling that I am aware of.