As part of my work to fix the RC Map problem for AC3.3, it makes sense to fix the Tricopter tail servo problems at the same time. The timing on this work is really tight as we're down to the wire to make it into AC3.3. Unfortunately I don't have a tricopter to use, so I need help from some keen testers who will be able to load and fly a custom binary that will be based on the AC3.3 RC releases. I have a couple of things I'd like to accomplish:
1) Allow proper independent servo reversing, without the current hack which is to use the Ch7 reverse.
2) Allow proper tail servo endpoint adjustment so that servo will not move beyond mechanical limits, ever.
3) Allow tail servo to always move while disarmed. Currently it appears it doesn't move until it's armed?
Are there any other issues I should be aware of?
One idea I had while looking at the code, was the concept of doing straight control pass-through of the tail servo control while disarmed. It would bypass the PID, and would map the stick directly to the servo. This would allow you to easily check servo operation. The disadvantage would be, you could not see the PID action.
What do you think, which way would be more useful?
Replies
Rob, as I mentioned in the 3.3 thread, I am more than happy to test tricopter-specific builds and to collaborate with you in whatever way is most useful.
As for your specific items, just starting from scratch since I just discovered this thread:
The other thing off the top of my head would be smoothing out the wagging yaw, where there is a bit of rubbery 'give' that it somewhat difficult to account for in flight. I know some other FC's have gotten around it, but I don't know exactly what changes were made to get there.
As for your PID/no PID disarmed servo question, the more I think about it I feel like you should not bypass the PID and just have it work only when armed (if possible). That way, you could check the behavior of the servo when armed, but on the ground with the motors spinning idle. Does that make sense?
You originally posted this in May, anything else you'd like me to try that has changed since then?
Best,
Patrick
Hi Guys,
Sorry, I've neglected this thread for a while. The changes I discussed have made it into RC7, however, there has been no functional testing as I don't have a tricopter to play with. Randy has updated the wiki to explain how the new parameters work:
http://copter.ardupilot.com/wiki/tricopter/
The concept is that your Ch7 on your Tx should now be set to default, don't do the servo reversing in it, or adjust the range, or anything like that. It will only look at those Ch7 on the input side of things. The output servo is now managed by the new parameters. You should now have range limiting, trim and reversing without having to mess with your radio.
Please give it a bench test, and see what you can get working, report on what's not working, videos would be appreciated if they help explain it.
Is there any work still going on for tricopters in AC3.3? 3.3-rc7 seems to have made mine unflyable. Wondering if something was changed recently that I wasn't aware of. Also posted about this in the main AC3.3 thread but that thing is a beast and I figured it might be easier to discuss it in here.
Mine was unflyable with 3.3rc8 as well until I made some Rate Yaw changes suggested by Randy:
If it matters, I'm also using the latest beta Mission Planner. This change really made a huge difference.
One thing I have noticed, though, is even doing a simple accel calibration requires a power cycle before things make sense in flight data display. But once I do that and see things settle down on the GCS, flight is perfectly fine.
Hi Rob....I have a well flying, large, Pixhawked tricopter (17" props) I'd be happy to test on, but I won't be able to do it for about a week due to travel. It suffers from just a little bit of yaw wobble at this point, most of which was eliminated by turning the Stabilize Yaw P way up. I'd be interested if your new code can eliminate that.
My tail servo hinge travel is somewhat limited but I dealt with that by using a HiTech digital servo with programmable endpoints. Works very well. I had first attempted to accomplish the limiting by setting the RC7 endpoints much closer to center (to reduce the throw) but the damn thing wouldn't arm. I finally found in the code a prearm check to verify each RC channel's calibrated range is between coded maxs and mins. But you've probably already dealt with that.
I see no reason the tail servo couldn't be migrated from channel 7. However that's such an unusual channel I always thought whoever wrote that first code had some sort of good reason for it. I'd suggest asking other Devs if they knew why 7 was selected.
Tail servo movement while disarmed would be real helpful. A straight pass through would be fine. No need for the PIDs to see that the servo is working correctly.
That would make sense. I could change that easily, but I fear what would happen if somebody loaded 3.3 without reading the release notes and changing their wiring around.
That's a pretty compelling argument. I guess if you didn't rewire to the correct channel, you'd have the tail motor go to half throttle when you armed. Or even full, since you'd be arming with full right rudder. That could be ugly.
Yeah. It probably would just not arm the ESC as it wouldn't necessarily get the min throttle setting. But it's just risky.
For reasons unknown to me, the tail servo uses Ch7 for output. I think it would make more sense to use 3 (1,2 and 4 are motors right?). Anybody have an opinion on using Ch3?
-
1
-
2
of 2 Next