Took the F550 out on a one way (take-off/ land) spline mission going downhill following the road.
Initial altitude was 150 feet (45.75m)
This time, I used terrain on drop-down to plan.
Also had the altitude warning set for -150 so it would allow me to plan going downhill that much from home.
3 minutes later, I had to gain manual control because it was quite obvious the craft was no longer at 150 feet.
Also attached the pic when I took over auto control.
On 14:37:04 is when I switched according to the log.
No way I was at 150ft.
And finally attached the waypoint file. FM1888.zip (326 Bytes)
Doing the math (which I was never good at) at the point of regaining control, there was only -183ft difference between takeoff (higher) and the area of landing.
Mission Planner telemetry said I was 151ft below home.
But the log shows I was -43ft
Obviously not 150 ft:
Same thing that happened on the December 17 loop flight described in the link first posted- first spline waypoint mission…barely cleared a grove of trees when altitude was set at 125ft.
And this effect most likely contributed to a quad I lost recently - sent out on a mission and never came back.
Apparently the crash disrupted telemetry and I cannot track it down for further investigation.
How fast was it going (can’t open the log at work)? Did you have the terrain parameters enabled and allow it to retrieve and upload terrain data? Does terrain following even work in 3.4 (I don’t remember)?
As far as I know terrain following is supposed to work in Copter in 3.4, but it only works with downward facing LIDAR or sonar.
I flew about 200 hours of spline waypoints last year with the helicopter, and about 70 hours so far this year. Using manually adjusted waypoint altitudes calculated from ArcGIS/USGS elevation models, I have never had this issue flying at 45-50 mph with the helicopter on missions up to 30 miles total flight distance, doing surveys on one section at a time. Some with terrain elevation changes up to 90-100 feet. But I do not use “verify altitude” because I don’t trust it. I know from experience it is not accurate.
I thought it would work with a cached map? One is written to the SD card if Terrain is enabled and I can see the parameters being updated on the status screen as it’s doing so. But I should say I have never actually flown a mission with it as its flat as a pancake here. Of course it would be the same data used for “Verify” so I take your point about accuracy but my question is about basic functionality.
I do not use it because I do not trust the source of the data. I do not know about the basic functionality of the terrain following because I don’t use that either. My aircraft is too expensive to risk it. I do all the calculations in the office from known good data (that is freely available to the general public) on each waypoint, and I use the waypoints to adjust the elevation on a spline turn because I don’t think the software has any way to calculate that. It can only go waypoint to waypoint, and you can have a terrain feature on a spline turn that the aircraft may collide with.
Here is an example, flown late yesterday afternoon, of a 17.1 mile flight, 34 minute flight time, total terrain elevation change (with obstructions, which were trees) on the flight was 41 feet, 100% spline waypoints. The plot of GPS vs barometric altitude:
An arrival back at home before it started its descent, flying over the road and powerlines - you can plainly see there was no loss in altitude during the flight from departure to arrival back at “home”
What I’m saying is that unless you use a laser altimeter, there is limitations in what the software can do to automate flight planning.
I learned that Google’s stuff is to be taken with a grain of salt when I flight planned a mission for a Phantom 3 using Litchi’s features for terrain avoidance, a couple years back. And flew it right into the side of a hill where all of Google’s data said it should’ve had 40 feet to terrain. Compared later against ArcGIS data, which said it had zero altitude to terrain, right where the Phantom crashed. That was the last time I trusted anything Google says without comparing it to a surveyed terrain elevation model contour map.
YMMV, but that’s what I would recommend doing, based on a lot of experience flying terrain. Depending on the performance limitations of your aircraft, the ground track on splines is not always even the same as depicted on the computer screen, much less trusting the altitude part.
When I get home tonight I’ll get a chance to look at your log and mission file. It’s kind of interesting to see how the ground station software is applying the altitude correction. I flew the above noted flight with two do jumps a total of 34 minutes to get the imagery I needed, and it was perfect every time. So I don’t think it has anything to do with time. I think when the FC is armed it establishes an absolute altitude based on the barometer (I’m pretty sure). With a full-sized aircraft, as I’m sure you’re aware, the altimeter is adjusted for field altitude and current barometric pressure reading. I’ve never been able to figure out how ArduPilot can do that when flying MSL altitudes, without the correction that is applied to real altimeters.
That is sort of why I don’t trust it. I prefer to base everything off the relative from takeoff point.
@pmshop - I see everything going very well to waypoint 5. Elevation change of -204 feet. The flight plan calls for reducing altitude from the takeoff position 189 feet to waypoint 5.
That’s where everything goes bad. From waypoint 5 to 7 the elevation change is -34 feet. Your flight plan calls for reducing altitude by 80 feet. Total elevation change thus far is -238. Total altitude drop on your flight plan to waypoint 7 is -269. A discrepancy of 31 feet (too low) if you intended to stay at 150 ft above terrain. I’m guessing that’s where your picture was snapped on that leg of the flight?
From there to landing the terrain drops another 39 feet. Your flight plan (sort of) compensates for the previous mistake at waypoint 7 by climbing 7 feet.
Total elevation drop is 265 feet. Total altitude change on your flight plan is -262.
The elevation data for waypoint 7 in your ground station software is wrong - likely derived from Google’s method of averaging SRTM data over several points, which is only accurate +/- 30 meters at 3 arc-second resolution.
Please note these limitations when using terrain data. The SRTM data used is accurate +/- 50 feet or so in most areas. But in some more rural areas it may not be available at all, or the accuracy can be +/- 30 meters, or +/- 100 feet. That is simply not good enough resolution for flying terrain at altitude of 150 feet if there are obstructions like trees that may be 50 feet high. Google makes it worse by average points to “flatten” their terrain maps so they have considerable less resolution that a real survey topo map.
So once you understand the limitations due to the data accuracy, you have to use your own judgement on whether or not you want to accept what MP comes up with, vs checking the terrain elevations yourself against a surveyed topo map. I have found enough serious discrepancies in Google’s data that I refuse to use it. If I was planning this flight, I would definitely have not set the altitudes to what MP set them to to maintain 150 ft above terrain. It got the altitudes right from the start to the end. But there was a quite serious discrepancy in the middle, and that’s all it takes to crash
@ChrisOlson My point exactly…no one is sure of what is going on.
From your interpretation, all is well until WP5 - do I understand that right?
I had to land approximately 1650ft after WP3.
The picture attached is the instant I flipped to PosHold mode before I hit the tree 800 ft further in the pic on the left of the road.
Your flight plan is ok to that point. Now that I have a better understanding of what was flight planned, vs what actually happened, I can look at the log again and see if I can pick out any discrepancies there. I’m not at home right now, and only have my Android tablet here, which is harder to look at a BIN log with using Tower.
From waypoint 5 to 7, I don’t trust what Mission Planner did for programmed altitudes because it doesn’t agree with surveyed topo data for that location. Your county surveyor must’ve surveyed that area because of the road and residences before, and you will likely find the red survey signs on the Section corners that says do not disturb under penalty of law, as the survey data was available in ArcGIS.
Later this evening when I get home, I’ll have another look at the BIN log.
The altitude drop from waypoint 2 to 3 is 45 feet (flight planned). Actual drop was 45 meters. The drop from from waypoint 3 to 4 is 144 feet. Doing some rough calculations on the speed vs altitude, and interpolating it, after the point where you hit Pos Hold at a total altitude loss of 89 meters, the aircraft was descending at a rate that would hit waypoint 4 at 144 meters altitude loss instead of 144 feet.
My best guess is that there is a problem with metric to imperial unit conversions there. The aircraft was using meters. Your flight plan was using feet? Now, this is a question I am not able to answer - all the terrain data (SRTM) is metric. When using terrain following, is there a bug when trying to flight plan in imperial units, but the FC will only use metric? It would sure appear that could be the case.
I can’t verify that this is the case. I tried a short auto flight this morning (although with helicopter) at a safe altitude to recover if it starts rapidly descending, and I can’t duplicate it. I was a little concerned that if metric units are being used with a flight plan done with imperial that it would be pretty serious. But it seems to work normal here.
Did you say that if you use regular waypoints, that it works fine? It’s just spline waypoints this happens with, and it’s repeatable? It still seems a little strange to me that the altitudes observed in your BIN log correspond to meters of descent instead of the flight planned feet.
Do you happen to have the telemetry log from this same flight?
Yes, this does not happen with regular waypoints.
And totally repeatable.
Here was the first case - AGL set at 125ft - observe much less than 125ft @ 3:30
Switching back to total metric units within Mission Planner and adding @Michael_Oborne to this chain.
Michael,
When mission planner is in imperial units and a spline waypoint mission is planned, looks like the planned reduction in altitude by feet is interpreted by the FC as meters.
Maybe Michael can offer some insight. I think with any terrain following, it still must kept in mind that the accuracy of the data is usually considered +/-30 meters using the SRTM dataset. And Google “flattens” that with their point averaging method. The Google terrain maps are not near as defined on the contour lines as a real survey map like you can download from your county GIS website, or any of the thousands of surveys done with ArcGIS.
So I think anything below 60 meters AGL, it is recommended to use downward facing LIDAR instead of terrain following with SRTM data. Or do like I do and map the whole ground track against a survey topo map and adjust your waypoints manually, and do not use terrain following.
Still an interesting thing. Just got your other log downloaded and going to look at that.
Is that the right tlog? It just shows a bunch of prearm throttle below failsafe messages, and it stops at 369 seconds. Like the ground station lost contact with the aircraft. I can see your terrain grid spacing was set to 100 meters, but don’t actually see if the terrain data got uploaded from the ground station to the aircraft? It normally holds (I think) 12 grids in memory, that is constantly updated from the ground station when using terrain following. But really can’t tell if that was happening from this log.
And if that is the case about constantly updated from the ground station when using terrain following, then that will not suit me.
I run missions out of range of MP
It pre-loads the terrain data for the whole mission from the GCS. So it only needs to load data in flight is you attempt to fly to an area outside of the pre-loaded grids.
