Altitude as a part of a waypoint

I have been poking around, but cannot seem to find the info on this - which means that as soon as I psot this, I will stumble across it --- but...

When setting up a multiple waypoint mission, how do I make it so that the altitude of a waypoint must be reached before going to the next waypoint? For instance, if I want to loiter at a waypoint at 5 meters then ascend at the same Lat/Long position to 20 meters, then when I get to 20 meters, fly to the next set of coordinates?

WP1: LAt1, Long1, alt:5M

WP2: Lat1, Long1, Alt:20M

WP3: Lat2, Long2, Alt: 20M

When I try this, it seems to only be considering the Latitude and longitude for determining if it is at the waypoint. So what ends up happening is that when it tries to go to WP2, it sees that it is already at the correct lat and long, and starts off to WP3. So instead of ascending in place, it angles up to WP3.

Is there not a command somewhere to set altitude directly? If not, is there a way to have 3D instead of 2D Waypoint conditions that must be met?

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Scott, for ArduCopter 2.9.1 it separates navigation of waypoints and height. So, it is trying to attain the height, but as you say, that's not a requirement of considering a waypoint to have been reached. In AC3.0 I believe they've changed it so that it is attempting to track directly toward each 3D waypoint rather than treating 2D position and height separately, though I haven't tested to verify if that's actually working.

    Not sure about ArduPlane.

  • I asked a similar but not identical question. I got this answer from Art Whaley. It may help you....

    First off - I fly in Oklahoma where the ground is flat and so I haven't USED verify height.  But according to the manual, it doesn't exactly do what you want, because it only checks and adjusts the ground altitude at waypoints.

    By default, the mission planner uses 'above launch site' as the reference for all altitudes, and with 'verify height' turned on it uses 'above current ground level'.

    so with verify height turned on, you could set

    WP1 at altitude 100' a little bit upwind of the takeoff site

    WP2 at altitude 100' on top of the mountain

    WP3 at altitude 100' at the target site

    WP4 at altitude 100' on top of the mountain

    WP5 at altitude 100' a little bit downwind of the takeoff site.

    or with verify height turned off you would set

    WP1 at 100'  (above launch site)

    WP2 at 1100' (above launch site)

    WP3 at 500' (above launch site)

    WP4 at 1100' (above launch site)

    WP5 at 100' (above launch site)

    or with absolute altitude turned on it would be

    WP1 at 1100'

    WP2 at 2100'

    WP3 at 1500'

    WP4 at 2100'

    WP5 at 1100'

    All of these three courses are exactly the same - they're just different ways of entering the values.  If you do this, the aircraft will take off at 1000' ASL, fly to 1100'ASL, ascend to 2100' ASL to cross the mountain with 100' of clearance, descent to 1500' at the target location, climb back to 2100' to get back over the mountain and then return to 1500' and lined up for a landing.

    If you just set WP 1 and 3 and 5 from the above example, even with verify height turned on, you're going to crash into the mountain.  The MP only checks and adjusts for terrain height at waypoints.  To my knowledge there's no way around this right now.  Maybe in the future the Sonar sensor or a machine vision system could let you actually see the terrain, but right now we just have to plan ahead for it ourselves.  There's not enough memory in Ardupilot to store the terrain height values for every place we could possibly fly it, and the programming doesn't RELY on the base station for anything when on an Automatic path - all of the decisions are made in the air so if telemetry is lost, the vehicle tries to complete the mission.

    Is there a reason you don't want to give it a couple of extra clicks to make sure you get over the mountain?   I'd personally set my 2100' ASL waypoint in FRONT of the mountain and another 2100' WP substantially BEHIND it to make sure I'm up high way before I need to be and back down after all risk of collision is passed.  And for that matter, I'd want more than 100' of spare clearance going over a mountain, but I'm just using that number for easily following the discussion!

  • In case I am not being too clear, what I am looking for is either a setting that says "Hit the altitude to consider the waypoint reached" or else separate "AscendTo" and DescendTo" commands. This may exist, but I cannot find it. 

    WAYPOINTS.png

    https://storage.ning.com/topology/rest/1.0/file/get/3692747443?profile=original
This reply was deleted.

Activity

DIY Robocars via Twitter
RT @chr1sa: Just a week to go before our next @DIYRobocars race at @circuitlaunch, complete with famous Brazilian BBQ. It's free, fun for k…
Saturday
DIY Robocars via Twitter
How to use the new @donkey_car graphical UI to edit driving data for better training https://www.youtube.com/watch?v=J5-zHNeNebQ
Nov 28
DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
Nov 26
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Nov 25
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Nov 23
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord: https://discord.gg/EPsZHkg9Nx) https://t.co/PNDewvJdrb
Nov 23
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Nov 23
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar https://www.youtube.com/watch?v=9yy7ASttw04
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge https://t.co/nZQTff5…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉 https://t.co/NtKnO…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch http://indyautonomouschallenge.com/stream
Oct 23
More…