Some thoughts about new features for Copter

ArduCopter Copter 4.6
1

Yesterday I finally made a few real world test flights in the mountains (midrange, midaltitude, 12…14 km at 2000 … 3000 m).

I discovered that there is really no good mode for flying longer range… Loiter mode sucks because you have to push the stick forward all the time, and it is not very precise, i.e. finding the best speed is very difficult. Also loiter mode is inefficient, because if you release the stick pressure, it brakes and looses effciency.

I ended up flying Acro mode all the time, because you set it up, and do not have to touch the controls. However, there is one problem - the throttle, it was very delicate, you lower it by one or two notches, and the copter goes down 2…3 m/s, you move it up, and it goes up. Also, I had a lot of thermals and downdrafts, so that you have to play with the throttle all the time.

Thinking about it, I feel there is a need for something similar to ACRO mode with Altitude control, i.e. you would set the attitude with the roll/pitch stick, but the throttle would maintain altitude like Alt Hold mode.

Acro Mode is very useful for longer range flights, especially if you have a crosswind (I had it between 25 and 40 km/h), as it allows to compensate for it by just rolling against it.

Another thing which immediately jumped into my mind is Efficiency Optimizer

The efficiency of the copter (energy per distance) depends on speed. Most copters are more efficient at moderate speeds than at hover, in my case that is about 15 % at about 30 km/h. From there the efficiency begins to drop, and from a certain speeed upwards, in my case above 70 km/h, it becomes really bad.

One cool feature would be speed control which would try to optimize automatically the speed so as to obtain best range. It is not as simple as selecting the best airspeed, because you have to consider the wind speed and direction.

The idea could be that the AP would try in a certain mode adjust the speed (copter inclination at constant altitud) so as to obtain the best efficiency per ground distance covered. It would constantly try to make small adjustments to speed and than check the efficiency, and based on that make again adjustments.

If the climb or descent rate is constant, that optimization would still work

Line of Sight Loss Warning Another interesting option is to implement a warning when the copter will fly behind mountain. Basically, you have to draw a line between the copter and home point, and check the ground elevation along that line using the terrain data. Once the ground elevation comes close to a preset value, a warning is issued that the copter is about to loose the Line of Sight.

I have implemented such a feature on my Ground Station for planes a long time ago, but it runs on Raspberry Pi and Python, so I am not sure if the STM processors would have enough spare computation power to do something like this on the FC side.

On the other hand, I doubt that we need to have more than 30 km of distance, so that at about 30 m/point, you need only to check about 1000 points max every 500 mS.

2 Likes
2

Had similar thoughts about first point. Personally I would really like to see something like Cruise Control that can be enabled in AltHold/Loiter just to maintain speed without pushing pitch stick.

3

https://ardupilot.org/copter/docs/sport-mode.html#sport-mode

4 Likes
4

That is EXACTLY what I wanted…

5

That one can be easily implemented using LUA…

The way to do it: we need a spare switch. We set the correct speed and flight direction in Loiter mode using the stick. Once we are satisfied, we flip the switch. After that we have to release the stick within the next 5 seconds.

LUA reads the switch state, once it is activated, it reads the stick position, i.e. roll and pitch PWM. After a short time, 1…2 second, it would begin to stream those PWM values for pitch and roll and throttle directly (using SRV_Channels??) to FC. At the same time, LUA would begin to read the pitch and roll after some 5 seconds. If they become different from 1500 ±25, then that means that the user moved the stick, and the LUA will cease to send the saved values, and reestablish normal RCIN behaviour. The same would happen if the switch is flipped back.

If we would use both sticks for cruise control, and since it is difficult to activate a switch without loosing the position of the sticks in the process, LUA could use the stick positions which were 2 seconds prior to activation (using a table with maybe 10 sets of stick values), i.e. the user would set the sticks to the desired position, wait and hold them for 2 seconds, and then release and activate the switch within 2 seconds…

If I wanted to use the Loiter/Alt Hold mode, I think that writing that Lua script would take just acouple of hours. But I would prefer to try the Sports Mode…

6

Use the custom firmware builder and give it a go then. It still exists, but a lack of regular use by most users relegates it to a special feature to free up flash space.

1 Like
7

I set up a few logical switches and mix on my radio so under the correct conditions one of my sliders acts as a forward pitch input when in Loiter. I use the slider to set the speed and then just steer around with the yaw. I might try the same again in Lua some day, but the radio method means it works on my all my quads, including those that are still on F405 boards.

8

For plane, I used both sliders for pitch and roll trim control, but when I started with copters, I often got the RC not centered message during arming, so in the end I switched off the slider options. But, yes, with another switch to activate and deactivate the trims, that would work better.

9

I can think of one feature - ability to assign function to rc channel for each state low/mid/high
Something like RCx_OPTION_LOW, RCx_OPTION_MID, RCx_OPTION_HIGH

Would bring a little flexibility in using not so many of RC channels available.

And one more - not tested that, but documentation is not very clear with that.
For flight mode CIRCLE it would be nice to have option to set center of the cirle to point where camera is pointing to.
Guess that is some trigonometry - altitude combined with gimbal angles and copter angles.
Also limitation to not exceed some configured radius and in case making circle around desired center point is not possible some message and just not switching to CIRCLE or something…