WPNAV_RADIUS Max Speed? WPNAV_SPEED Limits?

Anything we need to worry about when flying at 20 m/s in a mission and flying through small waypoints? Does GPS update quick enough for say a 1ft radius at 45mph?

What is the reason for the 20 m/s limit on WPNAV_SPEED? I’d like to use 27 m/s. What dangers am I looking at setting it above the limit?

It depends on the performance capabilities of the aircraft. I do it all the time with helicopters set to 35 m/s. The default horizontal acceleration limit is too low for high speed flight so that has to be turned up. And you may have to limit the maximum frame angle. Helicopters have cyclic pitch so they are able to maintain stability and roll and pitch control at high speeds under high-G manuveurs, even if they run out of collective pitch. So the only limitation is shaft power and collective pitch range. Multi-rotors must retain a certain amount of headroom for roll and pitch control.

So the danger for a multi is if your aircraft uses all its available thrust to maintain altitude in a high-G turn, or high-speed flight, it could lose stability, and roll and pitch control, and crash. Or it may lose altitude and crash if the frame angle is allowed to exceed that at which the aircraft can maintain altitude at the horizontal acceleration you have WPNAV_ACCEL set to.

The final danger is wind. The speed set in the mission is ground speed. These types of speeds are usually only flown over long distances in wide open areas. Which means dealing with wind. If I’m flying my helicoper at 60 mph in a 20 mph headwind it must be able to fly at an airspeed of 80 mph. Again, if your aircraft runs out of power flying upwind, it will lose altitude and crash.

Typically, in Copter type aircraft, only helicopters or some sort of racing quad with a high power/weight ratio is going to have enough sustained power and the required high-speed stability to fly waypoints at even 5 m radius at speeds beyond 20 m/s, and actually attain the target speed. And it will require the use of spline waypoints.

Thank you for your reply, but what I’d like to know is why the designers of ardupilot typed in a limit of 2000 cm/s for autopilot. I’m asking about any software design limitations, not aircraft.

I’ve found that Ardupilot does a good job of maintaining altitude when trying to fly beyond your copter’s speed limits. No worries about crashing. Just add an extra 50ft of altitude when pushing those boundaries. You can also adjust how well it maintains altitude when hitting these limits with ATC_ANG_LIM_TC.

It is all about aircraft limitations and safety. It is not a software issue. Here’s tridge and the team putting their GX9 thru its paces at 30+ m/s.

To fly faster than than the set limit you have to make settings that are outside the recommended ranges and you are on your own (in unsupported) territory. In Copter you will likely only find helicopter pilots have experience with it.

Thanks again for the reply Chris. Your last paragraph is exactly the question I would like answered. If the reason for the 20 max is there hasn’t been much testing by the devs above 20, then I will venture above 20 m/s. If the reason is there are known cases of loss of control above 20 by the autopilot, then I will settle with 20 as the max.

I’ve tested above 20 a few times and it’s flown beautifully. However, when it begins its coast into the last waypoint from 24m/s, it does a small brake maneuver and then coasts the rest of the way. I haven’t observed this below 20. So the algorithm used to approach a non-spline waypoint doesn’t like 20+. Caveats like this should be known so people can test above 20 responsibly, because we all would love for ardupilot to continue improving especially where speed is concerned.

No, it doesn’t because a regular waypoint is not a fly-thru in Copter. Spline waypoints are smooth fly-thru and suitable for high-speed flight.

The autopilot has no issues with loss of control at high speeds. The aircraft does. Any multi reaches a point where the frame angle required to generate horizontal thrust means not enough thrust overhead for stability control in the pitch, roll and yaw axis. The multi requires throttling motors at different speeds for yaw, pitch and roll since they do not have cyclic or collective pitch control. If all the power is being used to make the aircraft go there is nothing left to throttle to make it stable.

The devs have plenty of experience flying helicopters and planes at high speeds. Multi’s not so much because of their inherent limitations, the fact that they can only do it in short sprints, and they do not handle wind and turbulence very well at high speeds due to loss of overhead in throttling for stability control. And again, that has nothing to do with the software. If a quad-rotor aircraft, for instance, is flying at high speed and encounterss turbulence that causes it to yaw two motors have to speed up and two have to slow down to correct it. If there is not enough throttle overhead to maintain the vertical thrust vector in the yaw correction the aircraft loses yaw contol and turnes into a tumbling mess. Even in hover a multi is recommended to have 2:1 thrust/weight for proper stability and throttle overhead.

Since the software is designed primarily for multi’s that limitation is taken into account for safety of the users. If you want a high speed aircraft, step up to a helicopter or fixed-wing airplane. Otherwise the software is open source and there is no limitations. You are free to modify, add or remove features, and test the limits to your heart’s content. But we must retain defaults that are safe for the majority of users.

Outstanding, that’s great news. You just made my day.

You said “we must retain”, are you a developer for ardupilot? That would make me feel a lot better trusting your answer. I see mackay has a shield by his name. Is that the symbol for developers?

I am not a code developer, although I have written some code for the project. My primary duty is as a test pilot.

Edit:
I’m not sure what the issue is here with ArduPilot, other than the ground station software limiting how fast you can plan a mission. And we are not going to change that.

Again, there is no limits to how fast ArduPilot can fly an aircraft. There is no GPS update problem or anything like that. The calculations are done many times per second. The only limitation is your aircraft and how stable it is in high speed flight in the wind. At the time of this writing, to my knowledge it has only been done successfully with helicopters and airplanes. The sad fact with multi’s is that they are inherently very unstable machines, and folks that have tried it have crashed them. It will either reach its aerodynamic limit and break into an oscillation. Or simply veer off and crash due to getting caught in the wind and running out of headroom to keep it on course. And you can’t blame it on the software because I have flown helicopters WAY beyond the 20m/s planning limit with the same rate and attitude controller, GPS, etc…

So again, I don’t really see the issue here. Just make the setting manually and go out and try it.