search

ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source
http://ardupilot.org/
GNU General Public License v3.0
10.91k stars 17.41k forks source link

Arming check for mission sanity-check #4701

Open magicrub opened 8 years ago

magicrub commented 8 years ago

Add an Arming check that checks for things like:

some items should be allowed but produce a STATUSTEXT warning such as:

WickedShell commented 8 years ago

I think flying below ground is enough of a corner case that you should probably need to disable the check. If they're is opposition I could see it as an extra ARMING_MIS_STRICT that defaults to disabled, but it set to 1 checks the altitudes for not being below ground.

Re landing waypoint altitude, I'm working on a pr that uses landing to do deep stalls where the altitude is the entry altitude, so this would be a problem for me. I could probably just add a new MISSION_CMD though for deep stall as a workaround.

On Aug 19, 2016 13:44, "Tom Pittenger" notifications@github.com wrote:

Add an Arming check that checks for things like:

  • takeoff alt that is underground (accidental absolute alt)
  • negative takeoff pitch

some items should be allowed but produce a STATUSTEXT warning such as:

  • land point alt is not 0
  • any waypoint is under-ground. This is OK if launching off a cliff and you're flying down, we don't want to prevent that.. right? or maybe we do and the mission check needs to be disabled for that corner case?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArduPilot/ardupilot/issues/4701, or mute the thread https://github.com/notifications/unsubscribe-auth/AAipiGRisEfbyEHGW5ZZkhBURo_b_hLeks5qhhWUgaJpZM4Jo1n1 .

charleslinquist commented 8 years ago

MP should warn for route lengths greater than set length and missions that don't include a LAND command.

magicrub commented 7 years ago

I plan to implement this soon. Any last minute requests? We can, of course, add more later too.

WickedShell commented 7 years ago

Land point alt not 0 should be a flag/possible to disable, as there are normal missions that can be flown that rely on that behavior and a user shouldn't have to see a warning if it's intentional.

Sanity check that all jump targets in the mission exist.

Sanity check that if rally points are planned that the planned flight path will be in range of at least a really point. (This one is potentially quite computationally intensive, in fine with saying this should be managed by the gcs.

Loiter radiuses that are unachievable based on bank/airspeed settings.

Loiter radiuses that have exceeded the maximum possible storage (this is also a generic AP_Mission problem. It needs to intelligently clamp the radius and earn if it did that)

Endless jump sequence with no nav waypoints inside it.

Landing start maybe wapoint, but no actual nav land waypoint.

Unachievable glide slopes (ie running says the aircraft can't have done the decent from WP 4 to work 5 because the slope exceeds the limits in the tuning) this should maybe be optional, but it would be a nice way to let users know they planned the impossible.

On Aug 19, 2016 3:07 PM, "Michael du Breuil" wicked.shell.scripts@gmail.com wrote:

I think flying below ground is enough of a corner case that you should probably need to disable the check. If they're is opposition I could see it as an extra ARMING_MIS_STRICT that defaults to disabled, but it set to 1 checks the altitudes for not being below ground.

Re landing waypoint altitude, I'm working on a pr that uses landing to do deep stalls where the altitude is the entry altitude, so this would be a problem for me. I could probably just add a new MISSION_CMD though for deep stall as a workaround.

On Aug 19, 2016 13:44, "Tom Pittenger" notifications@github.com wrote:

Add an Arming check that checks for things like:

  • takeoff alt that is underground (accidental absolute alt)
  • negative takeoff pitch

some items should be allowed but produce a STATUSTEXT warning such as:

  • land point alt is not 0
  • any waypoint is under-ground. This is OK if launching off a cliff and you're flying down, we don't want to prevent that.. right? or maybe we do and the mission check needs to be disabled for that corner case?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArduPilot/ardupilot/issues/4701, or mute the thread https://github.com/notifications/unsubscribe-auth/AAipiGRisEfbyEHGW5ZZkhBURo_b_hLeks5qhhWUgaJpZM4Jo1n1 .

magicrub commented 7 years ago

Several of those seem reasonably easy to implement. The hard ones I'll push for next round.

magicrub commented 7 years ago

also check if first waypoint is very far away from home. This is common when you boot up in auto and launch using an old mission designed for a different location

juvinski commented 7 years ago

Hi @magicrub, maybe - a altitude takeoff complete to - I'm using qground and now there is a feature to change altitude for all elements on the mission - including takeoff - and how the takeoff complete altitude can be a value around 40 or 50, if the takeoff near to 100 mts an alert can be triggered ?

magicrub commented 7 years ago

@juvinski I think I'm missing a detail. A takeoff of 100m is OK. No alert should be given for that.

magicrub commented 7 years ago

Good example of where this would come in handy https://youtu.be/lwazVDZwrK4?t=60

juvinski commented 7 years ago

Hi @magicrub,

sorry for the delay. I know the 100 meters is possible but in my point of view 100 meters is excessive once the mission will not start before takeoff finished. It's just my opinion

magicrub commented 7 years ago

What if the mission is takeoff=1000m? That could be OK in certain scenarios. This needs to be a generic check. Perhaps a better check is (takeoff.alt <= firstNavWaypoint.alt*1.5) I can't think of any good reason to have the takeoff drastically higher than the next NAV_WAYPOINT point. Can you?

juvinski commented 7 years ago

I think would be perfect.

magicrub commented 6 years ago

another one: inhibit NAV_TAKEOFF takeoffs when VTOL is configured, we expect to be NAV_VTOL_TAKEOFF . Same goes for NAV_LAND and NAV_VTOL_LAND. @tridge wants to allow NAVTAKEOFF because there are rare instances where a VTOL aircraft could indeed do a "fixed wing" horizontal takeoff but that can be handled a different way with some Q* params

peterbarker commented 6 years ago

@magicrub Anything you can get into a PR for this?

magicrub commented 6 years ago

added https://github.com/ArduPilot/ardupilot/issues/1348 to the list at the top