Channel Overrides Don't Hold Value

[dpal887]

Hi, we are attempting to autonomously control a quad-copter inside using the dronekit software but we are having some issues with channel overrides. Obviously being inside we cannot get gps lock so we wanted to set the forwards values and backwards e.c.t. to the drone over the channel override system but the sent values aren't held.

Is there a way to get the sent values to hold their value until we clear it and if not perhaps it would be valuable to have this?

[peterbarker]

On Tue, 5 Jul 2016, dpal887 wrote:

Hi, we are attempting to autonomously control a quad-copter inside using the
dronekit software but we are having some issues with channel overrides.
Obviously being inside we cannot get gps lock so we wanted to set the
forwards values and backwards e.c.t. to the drone over the channel override
system but the sent values aren't held.

Is there a way to get the sent values to hold their value until we clear it
and if not perhaps it would be valuable to have this?

Recent versions of ArduCopter require you to set the channel overrides
every seconds.

You will either need to do that in your control loop, or create a thread
for a vehicle to periodically send any channel overrides (patches
welcome!).

Peter

[dpal887]

I've tried sending these commands in a while loop with very little delay and varying levels of delay but it would appear to be reset almost instantaneously (perhaps it can't be done fast enough using python).

Regardless this results in the quad-copter "bouncing" and eventually crashing.

Cheers
Daniel

[peterbarker]

On Tue, 5 Jul 2016, dpal887 wrote: I've tried sending these commands in a while loop with very little delay and varying levels of delay but it would appear to be reset almost instantaneously (perhaps it can't be done fast enough using python).

Gah, sorry, brain outage. The timeout I was thinking of was for guided-velocity. That timeout is 3 seconds.

Regardless this results in the quad-copter "bouncing" and eventually crashing.

Using channel overrides to control flight, while possible, is not recommended. That being said, this example works for me: https://github.com/peterbarker/dronekit-python/blob/source-system-filtering-tmp/examples/rc_override_flight/rc_override_flight.py

[dpal887]

Thanks.
So just in the last few minutes I've worked it out a little.
First we disconnected any joysticks from the quadcopter.

We then had to use this command in a while loop with a 100ms delay between sending commands:

vehicle.channels.overrides[3] = throttle

It would appear that there is very little interference when using it this way. I will have a look and see if I am able to create some sort of library that deals with non-gps movement.

[AndrewOak]

I have been using Dronekit-Python to do RC_overrides for a while, I am now able to arm, take off, hover, and land in a GPS-denied environment. I am currently working with Pixhawk v2, and a Raspberry 3B, but I will probably move onto APM2.6 for some other reasons.
My questions are:
1.By lots of experiments, I found out that the minimum time interval between each overrides is 0.393s. Once set shorter, some values will be ignored. But my project concerns some real-time controls, so is it possible to cut down the time intervals?
2.And since setting RC_channel values is not equal to setting the attitudes (yaw/pitch/roll), a specific override, for example, with channel 2, will cause the UAV to go forward or backward(depending on your value) at a different speed. Can you provide an example concerning the control of movements via setting attitudes(yaw/pitch/roll)?
3.I understand that in a GPS-denied environment, I can not arm in guided mode. Hence, I can not take off using simple_take_off or do any velocity controls. But I am up to modify and compile the source of AC 3.2.1, can you give me some hints to start with. I want to take off using simple_take_off and hover at a desierd altitude. My quad has a sonar (MB1240 to be specific), so it should have the necessary feedback to do the trick.

Thank you.

[dpal887]

Hi Andrew,

1. Have you considered using some kind of FIFO queue? Perhaps with a timeout.
2. I can't really provide that example yet. I will once I have finished writing some libraries. You could try running multiple threads (i.e. one for each channel) and then having a main program which sets these values based on user input commands. I aim to have something that writes say unguided_movement( direction, distance) or unguided_movement (direction, velocity) or something like that.
3. If you start in stabilize mode and have all the controls set to their respective (center) positions as they would be on your radio, then your quad-copter should hover relatively well. Of course you can read in the inputs from your altitude sensor (I think its an ADC of some kind) and then implement a PID controller that helps it maintain altitude. We are actually going to be using that in conjunction with image processing to give us a more accurate altitude stabilization.

[lroberts99]

@AndrewOak Perhaps this is a basic question, but what is your range of RC values? My range is 1000 - 2000, but it appears this only corresponds to one direction, i.e. counterclockwise yaw and not clockwise yaw. I'd like to reverse the RC input, but it cannot accept negative values due to the range and I am not seeing any method to reverse the channel. I'm using Dronekit. Any ideas? Thanks.

[jmachuca77]

So the range of 1000-2000 comes from the RC world. Where the RC Receivers would output PWM values in that range. 1500 would be center stick, 1000 would be full Left and 2000 would be full right. Best regards, Jaime Machuca Mercado CTO | Droidika | www.Droidika.com Mail. Jaime@Droidika.com Tel. +52 (33) 3777 5327 Cel. +52 1 (33) 3945 3350 Este correo electrónico y cualquier archivo transmitido en él, son confidenciales y para uso exclusivo de los individuos y entidades a quienes está dirigido. Si usted no es el destinatario previsto o la persona encargada de recibirlo, y tiene por error este mensaje, queda prohibido y sin validez el uso, difusión, re-envío, reimpresión o copia. Toda oferta y/o aceptación de propuestas comerciales, celebración de contratos u otros actos tendientes a la adquisición de bienes o servicios, así como el establecimiento de cualquier clase de obligación legal para Droidika S.A. de C.V., deberá confirmarse por escrito firmado autógrafamente por funcionario competente, excepto que se cuente con un contrato vigente que autorice el uso de este medio para tales fines. Si usted recibió este correo por equivocación, favor de notificar inmediatamente por este medio a su remitente, y después borrarlo de su correo

…

On Apr 4, 2017, at 12:03 PM, Lexie Roberts ***@***.***> wrote: @AndrewOak <https://github.com/AndrewOak> Perhaps this is a basic question, but what is your range of RC values? My range is 1000 - 2000, but it appears this only corresponds to one direction, i.e. counterclockwise yaw and not clockwise yaw. I'd like to reverse the RC input, but it cannot accept negative values due to the range and I am not seeing any method to reverse the channel. I'm using Dronekit. Any ideas? Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#643 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABlllcXpS_KIWmp00LJpztsPB76fK7Ctks5rsnf_gaJpZM4JFq2f>.

[lroberts99]

@jmachuca77 Thanks for your reply! In testing my Solo 3DR drone, however, it appeared that an RC value of 1000 was a minimum value. The motors were not spinning very quickly. As the RC input increased, the speed also increased. Any insight on this? Thanks.

[jmachuca77]

Same thing, low throttle would be 1000, and the motors will spin at the THR_MIN parameter setting. 1500 would be 50% and 2000 would be 100%, Though this is not directly related to motor speed if you are in a flight mode other than one that controls the throttle directly (like loiter, alt_hold, etc…) In this case 1500 would mean hold current altitude, values lower would mean descend at a speed proportional to how big the difference is from 1500. And higher values mean ascend at a proportional speed to the difference from 1500. Best regards, Jaime Machuca Mercado CTO | Droidika | www.Droidika.com Mail. Jaime@Droidika.com Tel. +52 (33) 3777 5327 Cel. +52 1 (33) 3945 3350 Este correo electrónico y cualquier archivo transmitido en él, son confidenciales y para uso exclusivo de los individuos y entidades a quienes está dirigido. Si usted no es el destinatario previsto o la persona encargada de recibirlo, y tiene por error este mensaje, queda prohibido y sin validez el uso, difusión, re-envío, reimpresión o copia. Toda oferta y/o aceptación de propuestas comerciales, celebración de contratos u otros actos tendientes a la adquisición de bienes o servicios, así como el establecimiento de cualquier clase de obligación legal para Droidika S.A. de C.V., deberá confirmarse por escrito firmado autógrafamente por funcionario competente, excepto que se cuente con un contrato vigente que autorice el uso de este medio para tales fines. Si usted recibió este correo por equivocación, favor de notificar inmediatamente por este medio a su remitente, y después borrarlo de su correo

…

On Apr 4, 2017, at 12:12 PM, Lexie Roberts ***@***.***> wrote: @jmachuca77 <https://github.com/jmachuca77> Thanks for your reply! In testing my Solo 3DR drone, however, it appeared that an RC value of 1000 was a minimum value. The motors were not spinning very quickly. As the RC input increased, the speed also increased. Any insight on this? Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#643 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABllleSXEs4PJVVyvfNQbY3ZL4zqNwfNks5rsnnhgaJpZM4JFq2f>.

[jmachuca77]

By the way using RC overrides is the worst way of controlling a copter. It is better to use guided mode and send position or velocity commands. Best regards, Jaime Machuca Mercado CTO | Droidika | www.Droidika.com Mail. Jaime@Droidika.com Tel. +52 (33) 3777 5327 Cel. +52 1 (33) 3945 3350 Este correo electrónico y cualquier archivo transmitido en él, son confidenciales y para uso exclusivo de los individuos y entidades a quienes está dirigido. Si usted no es el destinatario previsto o la persona encargada de recibirlo, y tiene por error este mensaje, queda prohibido y sin validez el uso, difusión, re-envío, reimpresión o copia. Toda oferta y/o aceptación de propuestas comerciales, celebración de contratos u otros actos tendientes a la adquisición de bienes o servicios, así como el establecimiento de cualquier clase de obligación legal para Droidika S.A. de C.V., deberá confirmarse por escrito firmado autógrafamente por funcionario competente, excepto que se cuente con un contrato vigente que autorice el uso de este medio para tales fines. Si usted recibió este correo por equivocación, favor de notificar inmediatamente por este medio a su remitente, y después borrarlo de su correo

…

On Apr 4, 2017, at 12:12 PM, Lexie Roberts ***@***.***> wrote: @jmachuca77 <https://github.com/jmachuca77> Thanks for your reply! In testing my Solo 3DR drone, however, it appeared that an RC value of 1000 was a minimum value. The motors were not spinning very quickly. As the RC input increased, the speed also increased. Any insight on this? Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#643 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABllleSXEs4PJVVyvfNQbY3ZL4zqNwfNks5rsnnhgaJpZM4JFq2f>.

[lroberts99]

Yes, I understand RC values are not the best way to accomplish this. But I am not able to use GPS and the ArduPilot software on Solo does not support the positioning command I need, SET_ATTITUDE_TARGET.

So, if I am understanding correctly, the meaning of the values differs between yaw and throttle? I am mostly concerned with pitch and yaw. The yaw is at maximum left speed at 1000, and maximum right speed at 2000, correct? Is it the same for pitch? Please correct me if I'm wrong, I need a good understanding of this so I can implement this in code. I haven't found much documentation on RC overrides.

[lroberts99]

The reason I am unsure about how the RC values are behaving is because during testing, I only saw the drone yaw counterclockwise, and never clockwise. Likewise, it only pitched in one direction. When it was given a command to yaw clockwise, the drone appeared to instead yaw counterclockwise much too quickly. So it seemed that the yaw values corresponded to the maximum and minimum of counterclockwise yaw only. It's possible something else went wrong in the code, though.

[jmachuca77]

Let me check on this, but it should be as follows Throttle 1000 - Min Throttle or Decend at the fastest rate (depends on flight mode) 1500 - 50 % Throttle or Hold Current Altitude (depends on flight mode) 2000 - 100% Throttle or climb at the fastest rate (depends on flight mode) Yaw (direction might be backwards but logic is fine, Rate of yaw depends on the difference from mid-stick) 1000 - Yaw counter clockwise (Full Left Stick) 1500 - Hold current Yaw (mid stick) 2000 - Yaw clockwise (Full Right Stick) Pitch (Again direction may be reversed) 1000 - Pitch forward up to max angle or move target position forward (depends on flight mode, full forward stick) 1500 - Hold position (mid stick) 2000 - pitch backward up to max angle or move target position backward (depends on flight mode, full backward stick) Roll (Again direction may be reversed, angle depends on how far it is from 1500) 1000 - Roll Left up to max angle or move target position Left (depends on flight mode, full Left stick) 1500 - Hold position (mid stick) 2000 - Roll Right up to max angle or move target position Right (depends on flight mode, full Right stick) For pitch and roll on flight modes like Loiter what is really happening is that you control the target position you want the drone to loiter at. So if you push forward (pitch) a little, the target position starts moving forward slowly, and if you push the stick further forward then it moves away faster. And the Pixhawk controls how far the drone has to lean to reach the target position. For flight modes like stabilize, it controls the angle the drone will have, so 1500 would be 0 deg. 1000 would be max angle (usually 45 deg) and values between that would give a proportional angle. You can check the values using Mission Planners RC Calibration Screen. There you will see the values each of the sticks has. If you move a stick you will see the value change. That way you can check which value is for which direction. Best regards, Jaime Machuca Mercado CTO | Droidika | www.Droidika.com Mail. Jaime@Droidika.com Tel. +52 (33) 3777 5327 Cel. +52 1 (33) 3945 3350 Este correo electrónico y cualquier archivo transmitido en él, son confidenciales y para uso exclusivo de los individuos y entidades a quienes está dirigido. Si usted no es el destinatario previsto o la persona encargada de recibirlo, y tiene por error este mensaje, queda prohibido y sin validez el uso, difusión, re-envío, reimpresión o copia. Toda oferta y/o aceptación de propuestas comerciales, celebración de contratos u otros actos tendientes a la adquisición de bienes o servicios, así como el establecimiento de cualquier clase de obligación legal para Droidika S.A. de C.V., deberá confirmarse por escrito firmado autógrafamente por funcionario competente, excepto que se cuente con un contrato vigente que autorice el uso de este medio para tales fines. Si usted recibió este correo por equivocación, favor de notificar inmediatamente por este medio a su remitente, y después borrarlo de su correo

…

On Apr 4, 2017, at 12:35 PM, Lexie Roberts ***@***.***> wrote: The reason I am unsure about how the RC values are behaving is because during testing, I only saw the drone yaw counterclockwise, and never clockwise. Likewise, it only pitched in one direction. When it was given a command to yaw clockwise, the drone appeared to instead yaw counterclockwise much too quickly. So it seemed that the yaw values corresponded to the maximum and minimum of counterclockwise yaw only. It's possible something else went wrong in the code, though. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#643 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABlllT1DqCEpnV9DEOXVC05lmrwHGG4sks5rsn9UgaJpZM4JFq2f>.

[AndrewOak]

@lroberts99 The answer above by jmachuca77 is really explicit. Though I'd like to add that you can always change those default settings by digging into the Full Parameter List[1] of your flight control firmware once your drone is connected to your computer with Mission Planner.
However, If your drone behaves strangely, you should always calibrate all your sensors, controls, and ESC first (though actually all those calibration is done by tuning and updating the Full Parameter List).
If you are interested in how RC values are translated into ESC control signals based on various feedback on board, understanding the source code of the ardupilot firmware is your best option.
Good luck and be careful!

[1]http://ardupilot.org/copter/docs/parameters.html
P.S. Also, please check out this page for further information: http://ardupilot.org/copter/docs/common-advanced-configuration.html