Does someone know and can share what the difference is between the Altitude settings in Mission Planner for Relative, Absolute and Terrain. I know that the Terrain is for those planes equipped for terrain following, but what about the other 2 settings?  I have had some problems with my X-8 wing holding requested altitude and suspect this might be the problem. HELP and thanks!

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

Join diydrones

Email me when people reply –

Replies

  • I am a bit confused on how Mission Planner itself deals with verify height. If I generate my waypoints via Survery (Grid) then check verify height, all of my waypoint alt values are unchanged. However if verify height is checked before I generate the waypoints, each waypoint alt value is different (higher or lower relative to the initial height I set). So my question is when I write these values to the copter in the first scenario I just described do the values get changed to those reflected in the second scenario I described?

    • Yes, that can really be a trap, if one does not take care. 

      Ideal would be, an already generated grid should update the moment "verify height" is checked.

      What I still do not understand, in the procedure you described @Carlos, the the setting 'relative, absolute or terrain' do not play a role in the creation of the grid, or does it? I do not see any difference in the WP altitudes generated.

  • I'm still struggling to understand it 100%.

    Let's assume the following:

    I take off from home, altitude at ground level is 20 meter. First waypoint is altitude 100 meter, relative mode, but tickbox verify height not ticked. Will I now climb to 100 meter or 120 meter?

    Second assumption:

    I planning waypoint 2, 100 meter, waypoint 3, 100 meter, but there is a hill of 150 meter in between. I select relative, check the tick box verify height and I set TERRAIN_ENABLE to 1 and TERRAIN_FOLLOW to 1. I plan this mission without being connected to the plane. When I done planning my mission, I upload the mission to the APM using MAVLINK.

    Will the plane try to over the hill or through the hill?

    I have a few more scenarios, but these are the most relative.

    • Scenario 1
      If you do not check the box to verify height, the craft will fly to the altitude specified in the waypoint relative to the home altitude i.e. 100 metres above your home altitude. So if your home altitude is 20 metres above sea level that would be 20+100 = 120 metres above sea level.
  • So after reading all this (which is kinda of funny) because I was just on a walk with my dog and we live way up on a hill and I was thinking in my head if I launched my multirotor (APM 2.6) from my house at 100ft and wanted to fly it over to the park which is quite a way down the hill, then I would be at probably 400ft from the ground. So I was trying to think what would be the best way to have it go down to 100ft over the park and then return without crashing into something. Is this even possible or do you just have to guess?

    • @Brad, we've made altitude sensors suitable for 'copters and fixed wings that can give accurate AGL beyond 330ft (SF10/C). I know that many commercial flight controllers aren't able to use this functionality yet, but with the current FAA reg's it's probably going to become critical for all UAS users to monitor AGL.

      • That's a sweet device, I want one!

  • Using relative altitude is the best way to go for more than the vast majority of users.  All one needs to know is how hight above the ground I am on does the vehicle need to fly to not hit something.  Using MSL altitude has too many factors such as pressure system, ambient temperature compensation, and calibration and instrument placement errors which would be unique to every situation and vehicle.  

  • All of this is backwards and sideways from the rest of the aviation world in many ways.  The rest of the aviation world:

    Absolute Altitude = AGL.  You altitude above the terrain below the aircraft. Always referred to as "AGL".
    True Altitude = MSL.  Your altitude above mean sea level.  Always referred to as MSL.
    Pressure altitude, density altitude, and indicated altitude are not really relevant for our purposes here and now, but are all circumstance variations of MSL.

    There is no such thing as "relative altitude" in aviation. This presents an issue for us, since that's what we're using.  The altitude relative to the home altitude.  I would prefer to see the real aviation terms be used correctly, and call relative altitude exactly what it is.

    • I agree.  Relative altitude is the most practical altitude for most of our applications.  Anyone that requires precise AGL and MSL altitudes would be happy to go through those additional efforts.  Relative as a standard basic altitude is fine for 90% of the operators.

      I just want the terminology to be accurate and consistent. Arducopter uses calls altitude above sea level "absolute altitude", and that is wrong.  Absolute altitude in aviation is the altitude above ground.

      I suggest the altitudes reported by arducopter should simply be referred to as: Relative, ASL, and AGL.

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @chr1sa: Our next @DIYRobocars virtual AI car race is next Saturday. Compete from home using the @donkey_car simulator -- no physical ca…
yesterday
DIY Robocars via Twitter
RT @RoboticMasters: Students from @Sydney_Uni working hard on improvements and changes to @donkey_car simulator. @diyrobocars @adafruit…
yesterday
DIY Robocars via Twitter
Practice virtual race this Saturday; the real thing will be on Oct 3 https://www.meetup.com/DIYRobocars/
Wednesday
DIY Robocars via Twitter
Wednesday
Derrick Davies liked lisa TDrones's profile
Wednesday
DIY Robocars via Twitter
Sep 21
DIY Robocars via Twitter
RT @SahikaGenc: AWS DeepRacer & Hot Wheels Track https://youtu.be/4H0Ei07RdR4 via @YouTube
Sep 14
DIY Robocars via Twitter
Sep 8
DIY Robocars via Twitter
RT @davsca1: We are releasing the code of our Fisher Information Field, the first dedicated map for perception-aware planning that is >10x…
Sep 8
DIY Robocars via Twitter
RT @SmallpixelCar: How this works: 1)object detection to find cones in single camera image, 30 frames/sec on @NVIDIAEmbedded Xavier. 2)comp…
Sep 8
DIY Robocars via Twitter
RT @SmallpixelCar: Use two color cones to guide the robocar. No map needed, on onsite training needed. Just place the cones and it will fol…
Sep 7
DIY Robocars via Twitter
Sep 7
DIY Robocars via Twitter
RT @roboton_io: Great to see http://roboton.io running at 60fps on the cheapest #chromebook we could find! #edtech #robotics #educat…
Sep 3
DIY Robocars via Twitter
RT @openmvcam: Crazy in-depth article about using the OpenMV Cam for Astrophotography: https://github.com/frank26080115/OpemMV-Astrophotography-Gear https://t.co/BPoK9QDEwS
Sep 3
DIY Robocars via Twitter
RT @openmvcam: Hi folks, it's finally here! Our first draft of our Arduino Interface Library is out! It works over SoftwareSerial, Hardware…
Sep 3
DIY Robocars via Twitter
RT @chr1sa: Please let them have an open API. This would be perfect for @DIYRobocars races https://twitter.com/NintendoAmerica/status/1301513099707658246
Sep 3
More…