Spline mission looses altitude

It lost connection with the ground station for a few seconds between waypoints. But here’s where the confusion in waypoints is coming in - I’m looking at it in Tower, which I always use in the field. Tower numbers the waypoints different, using command sequence. So Waypoint #4 in Tower is Waypoint #3 in your MP ground station.

Using the Tower numbering schema, the total programmed altitude drop should’ve been only 14 meters, or 45 feet, to waypoint 4. What I saw when I played back your telemetry log is that the actual drop in aircraft altitude was 45 meters. Total terrain elevation change on this stretch of the flight was -34 meters, leaving you at roughly 35 meters AGL. Desired Altitude above terrain was 46 meters.

From waypoint 4 the aircraft continued to descend at the maximum allowed descent rate set by your WPNAV_DN param at a flight speed of 12.8m/s with 991 meters to the next waypoint.

  • Just about hit some trees on the right side of the road
  • Total elevation drop waypoint 4 to waypoint 5 is -25 meters for a total of -59 meters from Home
  • At roughly 450 meters past waypoint 4 you hit Pos Hold, at which point the aircraft was 10 meters from terrain.
  • Aircraft descended an additional 45 meters, for a total of -90 meters, to the point where you hit Pos Hold.

The flight planned altitude drop was -58 meters from Home to waypoint 5, or 189 feet. This corresponds with elevation change nicely (which is what I was saying about your flight planning looking good to waypoint 5).

The problem comes in where if I take the actual descent rate and plot it against flight speed and distance to the next waypoint, the aircraft was trying to hit a target altitude loss from home of -189 meters instead of 189 feet. If left unchecked, it would’ve impacted terrain 7 seconds after you hit Pos Hold.

IMO, this all points to a problem with the flight planning being done with feet. And the FC using the imperial values as meters. The numbers come out too close for it to be anything else, and I’ve run the math on it three times and came up with the same results.

I have never done flight planning with imperial units, so it took me a bit to piece it all together. But once I converted your flight plan to metric units in Tower it became pretty evident

Thanks!
Learning metric the rest of the way now and keeping MP in metric units.

I appreciate your time.

That will likely solve the problem with not crashing your aircraft, if it’s doing what it appears to me. But I think there’s a problem in terrain following with the FC using imperial units from the ground station’s flight plan. At least that’s the way it would appear to me. I assume the flight plan was the file that MP created to upload, and I did not really see anything wrong with that (other than a ~10m discrepancy at one waypoint, which is normal ‘within allowable error’ with SRTM data). The FC did not execute it properly. And I don’t know why.

If it was me, I’d try doing one in metric values and test it at a higher altitude in a safer environment where you can easily take over control, and using the spline waypoints, to make sure it works. You caught this one just in time. Within 10 seconds it would’ve been all over.

Does it in metric units as well.
Just performed a flight using metric units plotting the same course + 7.6m altitude.

Log, tLog and wp attached
https://drive.google.com/open?id=0Bztl55fVbGtCYy1zM0dIcjBFVlk
2017-07-20 12-05-12t.zip (231.3 KB)

Der Stadt Friedhof MetricC.zip (340 Bytes)

At the 3:45 mark of the following video is right after WP5 - that is not 57m

Also, not sure what happened at WP5
It should have turned less than 180° to face an ROI behind the liftoff point.
For some reason it stalled on its way to WP5 then turned up to 270° - 300° and corrected
Also noted, the slew rate was much faster than the programmed 3000 centi deg/s

Outcome of this flight - battery severely puffed and lost power - soft crash in hay field.

I am at a loss to provide an accurate or reasonable explanation. I’ve done hundreds of flights using spline, but never actually used terrain following. Mainly because the ground station software I primarily use (Tower) doesn’t support it. So I’ve always done the altitude calcs manually from the survey maps.

I never hit anything with the helicopter until a week ago, when I hit a tree with it. Didn’t cause any damage to the heli, but the tree is two feet shorter now. And the heli’s flight path was supposed to miss the tree. But I found out what the problem was with that - it was a new 900 helicopter and when I configured it I neglected to set the WPNAV accels properly. So it kinda chopped off a corner going 20 m/s and flew thru the tree.

I wish somebody that’s 100% familiar with the terrain following feature would chime in on this one.

You might have a powerful and well built vehicle if…

[quote=“ChrisOlson, post:25, topic:18887”]
Didn’t cause any damage to the heli, but the tree is two feet shorter now.[/quote]

Actually, this one was programmed “relative” 100% metric.
I’d like to solve the relative spline waypoint altitude issue before I go onto terrain following.

This is what I’m saying. My ground station software only supports relative, and doing the calcs on the altitudes has never been a problem. It appears to me that terrain following sort of does the same thing, just using the SRTM data to program the proper altititude into the flight controller’s waypoints.

For whatever reason, your aircraft is not following that flight plan. I was probably just coincidence when I looked at the previous flight and it appeared Imperial units might be miscontrued as metric. The numbers just worked out. But what your aircraft is doing makes no sense. It thinks it’s doing the right thing. The video and photo evidence shows it’s not.

Thinking back, I had a flight once with the 700 helicopter, all spline. I don’t remember how long it was. The helicopter was gone for like a half hour. When it came back in I know I had the final waypoint set at about 10 meters. The helicopter was coming in on final and was supposed to stop at that final waypoint and go into hover so I could take over and land it. The glideslope didn’t look quite right on final approach, coming in at about 20 m/s. At about my height off ground (6 feet), and still a good 50 meters short of the final waypoint it was obvious it was going to fly into the ground. I grabbed Acro flight mode and slammed in a bunch of collective and took over and landed it.

At the time I attributed it to possibly the barometric pressure changing or something from the time it took off to the time it came back and forgot about it. But seeing what yours is doing makes me wonder about that.

32lb helicopter. Some sort of fast-growing scrub tree with softwood branches. Lots of excitement when the top of the tree suddenly turned into flying branches and leaves and the helicopter comes out of it sideways. From the time I realized it was going to hit the tree to when I shut it down in-flight and switched to Acro so I could autororate it, my reaction time was just too slow to catch it before it hit the tree.

Some sort of sticky sap and green stains on the blades. But otherwise it was fine.

Anyone else have any ideas?

In Mission Planner, did you have it set for verify height, where it automatically adjusts the relative altitude based on SRTM terrain data? Or was the relative altitude 7.6M relative plain and simple?

Are you sure you weren’t exceeding the copter’s ability to maintain altitude by going too fast?

I am at work and therefore unable to open the logs and look for myself to answer these questions. But those are the two things off the top of my head I can think of that would cause undesired loss of altitude.

Matt, excellent observation. The RC OUT is not being logged to see what the throttle level of the motors is. So let’s look at watts instead.

I did notice in the flight log that the low battery battery warning went off at 388 seconds in in the log timeline, and altitude steadily deteriorated from that point. It is entirely possible the voltage is sagging attempting to fly a multi-rotor at 12-13 m/s continuous. Helicopters can do that, but there is few multi’s that can. So it runs out of power and starts going down.

At 408 seconds in the log the voltage is 7.9 volts and continues to drop to 4.9 volts just before the crash. I see current steadily rising all this time, approaching 45-46 amps. It looks like a 4S battery system, and I would say those batteries have been transformed to junk at about the 425 to 430 second mark on the log timeline.

It looks like hover power is about 450 watts at takeoff. Halfway between where the low battery warning goes off, and the crash, the power output of the battery is down to 360 watts. Definitely not enough power to maintain altitude. I would say you hit on the likely cause - the aircraft is running out of power, attempting to fly at speeds that are well beyond its maximum continuous capability.

I went back to the logs posted in the early part of the thread to see if the same loss of power was happening there. But I do not have those logs in my downloads folder, and they are no longer available from the link on the thread. So can’t tell much about that one.

In the most recent log, I see that as the battery maxxed out, the aircraft did slow down to reduce the power requirement, and attempt to maintain altitude. But it was too far gone.

Sorry about not having access to the logs.
ArduPilot Discourse did something screwy with their upload database.
I have been having trouble uploading anything and in a few times, resulted in uploading OneDrive or Google Drive links.
I will try to edit the links.
UPDATE* links working now.

Just FYI, the Turnigy 4S 5200mAh Graphene battery “puffed” in flight and got close to burnout.

Speed set to 1350cm/s and verify height is always selected since my first auto mission 2/12/16

I will make another flight down that first mission I posted on with full logging on.
Just worried about our current temperatures - 93° to 97° actual with 30% or less humidity coming up.

I think the heat had something to do with the inflight battery puff as there were only 92 cycles on it.

Also, same F550 craft with dual 5200mAh batteries (heavier).
5.38 miles (8.66km) trip. WPNAV_SPEED set to 1500cm/s but average speed according to logs 1050cm/s.
It can handle it…:smiley: :


Video 2.8x faster

The thing to remember with multi’s and power is that their power requirement goes up in forward flight due to frame angle. Helicopters, the power requirement goes down in forward flight due to ETL. As you draw more amps from your battery it wastes more power in heat generated in the LiPo chemistry. It takes a specific amount of watts to fly your aircraft, and watts is amps x volts with DC power. So as voltage goes down, amps goes up to keep it airborne, the amount of power wasted in heat in your battery increases, and it does into a “death spiral”. That’s exactly what happened in the last logs I looked at.

If the power is insufficient, and can’t hit the waypoints because of the acceleration limits with available power, the software will slow the aircraft and try to maintain altitude. That’s why you never reach a very high average speed. I think you are maxxed out on speed for the design. I will look at those first logs and see if the same thing appears there.

On that first flight, the aircraft was consuming ~500 watts, and continued to consume ~500 watts right up to where you switched to Position Hold, and battery voltage was still within safe limits. Loss of power was not the cause of that incident.