Tricopter servo yaw issues

[GoogleCodeExporter]

Arducoper NG or ACM?
ACM

What steps will reproduce the problem?
Tricopter, with digital yaw servo

What is the expected output? What do you see instead?
When the throttle is on zero, the rudder servo can't move (this is okay). Now 
sometimes when throttling up the ruder remains unresponsive especially if I 
move the rudder stick while on zero throttle, the only way to get rudder to 
respond again is to put the throttle to zero and throttle up again.

What version of the product are you using? On what operating system?
2.0.23 with 2560 

Please provide any additional information below.
I noticed on the KKuK flight controller that I previously used the rudder would 
move as I throttled up (to keep yaw steady) but when I throttle up with ACM the 
yaw stays the same. 

The rudder servo throw seems quite small, can this be adjusted?

Original issue reported on code.google.com by status...@live.co.uk on 5 Jun 2011 at 2:59

[GoogleCodeExporter]

I have to admit I don't have a TRI copter or know much about them. Can you 
point to any control code that I can adapt?

Original comment by jasonshort on 5 Jun 2011 at 4:15

[GoogleCodeExporter]

I think the main problem is that in a tricopter yaw is corrected by the tail 
servo, but when I try yawing the tricopter with ACM it seems to want to correct 
by adjusting the motor speeds (like a quad) and the yaw servo doesn't move at 
all (or it's tiny and doesn't seem to make a difference). This would probably 
take care of the spinning when the throttle increases. 

Also, in general yaw control from the servo is very small and I can only make 
it work by having stick input, even then the servo only moves about 45 deg from 
the center at max which isn’t enough to control the copter. 

Sorry, but I am not sure where about in the code this is handled. The file is 
of the KKUK code from Tricopters that may be useful. 

Original comment by status...@live.co.uk on 5 Jun 2011 at 5:38

Attachments:

• TriCopterV1_5.asm

[GoogleCodeExporter]

The Yaw isn't sent to the CH_4 motor at all. It's sent to CH7 to the Yaw servo. 
You should see ~ 20° deflection each way on that servo for yaw. Max was able 
to fly it no problem. Are you sure you have it connected correctly?

BTW, I can't read assembly so no luck there.

Original comment by jasonshort on 5 Jun 2011 at 6:08

[GoogleCodeExporter]

Yes, I have the yaw on CH7. I do see about 20 deg of deflection, but only with 
stick input. The yaw response in stabilize is there but it seems slow/delayed. 
From a bench testing perspective the yaw response defiantly appears to be less 
aggressive than what I've seen before. But if the code is flyable I will give 
it try and see how it behaves.

Original comment by status1...@gmail.com on 5 Jun 2011 at 9:34

[GoogleCodeExporter]

Just interested, was there ever a problem (as described above) where the rudder 
on the transmitter became unresponsive when throttle values changed. My setup 
never used to do this, but the rudder input from the transmitter works 
intermittently i.e. the servo won't respond to the input sometimes, even when 
the servo is neutral stabilize mode). I have tried different servos, and the 
all have this problem. 

Original comment by status1...@gmail.com on 5 Jun 2011 at 9:51

[GoogleCodeExporter]

Status1, i remember that a couple weeks ago, a modification has been done for 
Tri : servo output has been put in the 50 Hz loop instead of the 160 Hz.

This is because servos generally do not accept more than 50 Hz refresh rate.

Wich version are you using ?

Original comment by olivier....@helidream.fr on 5 Jun 2011 at 1:51

[GoogleCodeExporter]

That, was with the latest 2.0.23. I tried it with both digital and analog 
servos, but both had this problem. Is there a know servo type that works?

Original comment by status1...@gmail.com on 5 Jun 2011 at 8:58

[GoogleCodeExporter]

I'm not aware of any issues exactly. Try and fly it!
Jason

Original comment by jasonshort on 6 Jun 2011 at 4:36

[GoogleCodeExporter]

Ok, I will give it a go tomorrow and let you know how it goes. In the meantime, 
I have a few Q's: Can the yaw servo signal be reveresed? How do I record useful 
logs (at the mooment there only seems to be one log after multiple start ups)? 
Thanks 

Original comment by status1...@gmail.com on 6 Jun 2011 at 11:20

[GoogleCodeExporter]

erase your logs and try again.

Original comment by jasonshort on 6 Jun 2011 at 4:28

[GoogleCodeExporter]

Here is a video (poor quality, but you can see what's going on). This is with 
2.0.23 in tricopter mode, and you can see the apm 'stall', but throttle etc are 
still responsive during this 'stall' period. This was done under: tests --> tri 
in the mission planner. http://www.youtube.com/watch?v=koZGSb44rf8

Original comment by status1...@gmail.com on 7 Jun 2011 at 2:44

[GoogleCodeExporter]

whoa. Not looking good there. Can you run the radio test and see if you are 
having issues?
Jason

Original comment by jasonshort on 7 Jun 2011 at 2:48

[GoogleCodeExporter]

The radio tests seem to be alright, the rudder input is ranging from -5372 to 
5370 (with a 0 mid point). The other inputs seem fine as well, although they 
are not perfectly symetrical (out by about 2 - 10) but all centred on 0. All 
the channels have diffrent ranges in terms of a min and max value, but I think 
that is normal. Also CH7 is mostly stable at around 500, but every so often it 
drops to 0 and then back to 500, but I don't think CH7 does anything (but I 
have it connected to the reciever anyway). Finally the radio test doesn't 
'stall' like the 'tri' test does. 

Original comment by status...@live.co.uk on 7 Jun 2011 at 4:12

[GoogleCodeExporter]

Have you been able to replicate this error (it genrally only shows up about 30 
sec to 50 after the board is started and calibration finished)? I have my 
config file as well, its stock except mag orientation and tricopter mode where 
changed. 

Original comment by status...@live.co.uk on 8 Jun 2011 at 1:08

Attachments:

• APM_Config.h

[GoogleCodeExporter]

CH 7 is useful for setting your altitude hold throttle manually. I can also be 
used for other things like in-air leveling. 
I ran the tri test. I didn't see any freezing issues. Can you run them from the 
Arduino Serial window just to be sure? 

Original comment by jasonshort on 8 Jun 2011 at 3:28

[GoogleCodeExporter]

The problem is still there, and it seems to be with the APM, as this issue 
occurs during testing and when it's in flight mode (so battery and usb power). 
The Arduino serial window produces the same results.

Original comment by status...@live.co.uk on 8 Jun 2011 at 4:52

[GoogleCodeExporter]

Two prominent observations that I have found are: when it 'stalls' it can 
quickly be recovered by moving throttle to 0, and then raising it again (or it 
recovers over a longer time if you leave throttle where it’s at). Secondly, 
rudder (in flight mode) cannot be used when throttle is 0 (I assume that is 
from quads where rudder is controlled by spinning motors). 

So, is it at all possible that maybe a 0 value for throttle is created (by 
radio communication failure/signal drop or noise?) and passed to APM. This then 
makes APM think that throttle is 0 and it stops output to the rudder servo, but 
the throttle value was only 0 for a fraction of a second so you wouldn't notice 
on the other channels, except that rudder/servo takes longer to get started 
again because it’s in a slower loop than the esc outputs?

This was just a guess, I am not sure if it that justified given that APM 
controls servos on multiple channels all the time, but these are generally the 
first 4 or 5 channels not output 7. 

Also, I don’t think you can tell from the video, but when it ‘stalls’ 
there is ‘ghost’ output in the serial window i.e. a new line quickly 
flashes onto the screen, and then disappears almost immediately, this happens 
sometimes multiple times during the same ‘stall’ period.

Sean      

Original comment by status...@live.co.uk on 8 Jun 2011 at 7:30

[GoogleCodeExporter]

What I meant by 'ghost' output, is that it appears the arduino/APM is still 
writing values via serial, so it hasn't actually stalled. It just doesn't seem 
to notice the change in the input signal from the reciever/radio.  

Original comment by status...@live.co.uk on 9 Jun 2011 at 1:00

[GoogleCodeExporter]

Ok, I think that I have isolated the problem. The issue is with my setup and 
the APM. I had a Turnigy 9x radio with Frsky 2.4Ghz module and receiver 
connected, which works fine (it seems on other rc stuff) but causes those 
'stall' issues when plugged into ACM - only stalling the rudder, not the whole 
system (so if the radio com breaks down its not for long). I just tried the 
same ACM setup but switched receiver/transmitter to my JR 72MHz and the 
problem, as if by magic goes away. I tried again with the Turnigy setup and the 
problem is back. I'll try and run some APM tests on my setup and see if the 
problem still persists.    

Original comment by status...@live.co.uk on 9 Jun 2011 at 3:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Just to add to my earlier comment/observations, if the throttle is moved up 
with the rudder off-centered, and then the rudder allowed to center again when 
the throttle is above 0 the servo will not respond - as if it still taking the 
current throttle value as 0. 

If the cheaper radio gear is dropping signal momentarily, and the failsafe 
kicking in (either in APM or the receiver), dropping throttle to 0 - would this 
make APM thin that throttle was really 0, and ignore the new rudder input 
information (until the throttle is manually dropped to 0 and moved up again, or 
another 0 is recieved by the radio, which seems to free ACM from the 
‘stall’)?

Original comment by status...@live.co.uk on 9 Jun 2011 at 6:47

[GoogleCodeExporter]

Original comment by jasonshort on 18 Jun 2011 at 5:44

• Changed state: Done