Waypoint planning: How to enter altitude data of less than a meter?

Ground Control Software Mission Planner
1

Hello,
I need to set up a waypoint flight plan with Mission Planner (to fly a copter), which will be using terrain data derived from a rangefinder.

Due to the nature of the missions, some of the waypoints need to be very close to the ground, AGL of less than a meter.

So I entered 0.3 meters into the “Alt” column of Mission Planner and saved the WP file. Looking at the resulting file in a text editor, I saw that the save process had changed the altitude for this waypoint to 3 meters instead of 0.3m…

Q1: Can I create a WP flight plan using fractions of a meter for the altitude?

Alternatively, in case this is not possible with Mission Planner as it simply can’t accept fractional entries, I could also envision directly/ manually editing the WP text file to, say, 0.3 m.

My questions in this case are:

Q2: Will the Pixhawk 2.1 (running the latest firmware) accurately accept a flight plan written/ uploaded as a text file an entry of “fractional meter” values?

(In case this is also not possible, a workaround comes to mind:)
Q3: Can I fake-offset a parameter to arrive at the “whole meter” values I need? I.e. to arrive at a (possibly necessary minimum) altitude of 1m, I would add 70cm to the actual mounting height of the range finder of 30 cm above ground)

Two parameters come to mind:

  • RNGFND_GNDCLEAR (Distance (in cm) from the range finder to the ground)
  • RNGFND_POS_Z: Z position offset
    Z position of the first rangefinder in body frame. Positive Z is down from the origin. Use the zero range datum point if supplied.

Q4: Which one should I use to achieve the desired result (in case this workaround is needed)?

Q5: And lastly - will fake-offsetting this have a negative impact on Landing or Autolanding - as I would effectively be landing “below” the ground?

Thanks in advance for your competent insights on how to best solve this.

2

A1:
Use a less buggy GCS for grownups :slight_smile:
Mavproxy , APMPlanner2 and QGroundControl - will all let you fly at low altitudes, and don’t require windows or other mess.

A2: yes.
A3: I would not do that, it may also mess with future missions if you forget it.
A4: , see A1
A5: not really, it would still descend until landed, but it’s not a neat solution.

3

Andre-K,
thanks for your insights. Very glad to hear that entering “fractional meter” values will be accepted by the Pixhawk as such, albeit through another GCS or the use of a text file.

This should make the conceived workaround unnecessary altogether (and staying away from fake-offsets is much preferable anyways for the reason you mentioned).

As far as setting the correct offset is concerned, I don’t fully understand the handling of the two parameters mentioned above…
Say the PH is mounted 50cm off the ground, and the range finder 30cm off the ground, my guess is to set it as follows:
RNGFND_GNDCLEAR: 30cm (above the ground)
RNGFND_POS_Z: 20cm (below the PH)

Is this assumption correct?

Lastly, this situation would leave the apparent Mission Planner mishandling of entering a fractional altitude value to be fixed in it’s output/ conversion routine…

4

You understood the parameters correctly.
As for MP, well, it should not even have an “conversion routine” as the mavlink protocol clearly states floats for altitude.
Feel free to report the bug here: https://github.com/ArduPilot/MissionPlanner/issues

5

MP uses numbers in your native number format.
so if you need to use comma’s use commas, not periods.
also once you use the correct decimal indicator, you can use any number you want. including 0.3m

2 Likes
6

Hello Andre-K,
thanks for confirming my understanding of the parameter offsets.

7

@michael_oborne
thank you very much for the clarification!
Obviously a case of mishandling data by me, the user… Thanks for handling this correctly in Mission Planner!
I indeed have the decimal indicator regional setting set as “comma” on the computer I am working on now.

As I thought about your reply and me entering the altitude data with a period instead, my mishandling must have stemmed from thus far primarily using a client’s computer for generating missions and WP files - which has different regional settings. So I was very used to entering data into WP and home fields in MP (and into Excel files used to generate WP lists) with periods. Compounding to this mix-up: Google maps does not understand coordinates unless they are entered using a period, even with my local regional settings set to “comma” (!).
So thankfully this issue is cleared up and found to be possible without needing a workaround - and a few more facets have been learned :wink:

(Note that in the “Default Alt” box, though, it is not possible to enter fractional values.)

Now, to complete the flight plan creation for this application, I need to mix both relative and terrain-based WPs.
You had mentioned previously, that MP currently only supports a single mission frame per mission. (I.e. on saving the flight plan, all WPs are “equalized” to one type of altitude reference - even those that previously were entered while in another reference scheme.)

If I now manually amend/ create a flight plan, with having either “3” or “10” as frame in the third column of a WP file, as needed, and open such a mission file in MP, it is being completely “erased”, with not even coordinates present anymore…

Is there another way to upload such a “mixed-altitude-reference” WP-file from within Mission Planner or otherwise?

8

again: QGC , AP2, Mavproxy , will let you have any combination of altitude types, the standard does allow for every mission item that uses an altitude, to have any type it uses. such a mission should load into MP, but may be corrupted if you use MP to edit it.

9

@Michael_Oborne
Screenshot%20from%202018-09-18%2019-29-33

Accepting user input with commas and dots , but not handling it properly, should be considered a bug, at least, you could correct by replacing comma with dot or the other way around.

10

Thanks Andre-K.
I have tried it with Mavproxy, and seems to have worked fine - as long as the txt file had periods as a decimal indicator.

11

of course, input methods like files, expect a specific format , for such “plain text mission file” see format here:
https://mavlink.io/en/protocol/mission.html

It’s now described as “non-standard” , but this method is the oldest, most widespread. - and still the best/easiest for missions generated by custom tools, or mass edited… it’s the most human-readable format once you are familiar with the most used command ID’s.
Files will expect a specific format and comma type, only GUI is expected to handle incorrect entry.

12

Thanks Andre-K.
Not having sufficient programming skill to deal with creating a fancy JSON parser, for now I may just have to resort to medium-level sophistication/ automation in Excel, with an output as a txt flight plan, which in turn can be uploaded via MAVproxy.