Discussion of application of UAV Dev Board to CCPM RC Helicopters
There has been increasing discussion of application of the UAV Dev Board IMU approach to CCPM RC Helicopters. Bill and I thought it would be useful to start a thread on this specific topic and see what interest there might be.
My particular interest is to initially implement a stabilization system on my TREX 450SE Heli. Loftier goals of AP with RTL and WPs may well follow.
If you are interested in something similar, please post and describe your interests. Perhaps we can help Bill on some of the CCPM-specific issues.
John
My particular interest is to initially implement a stabilization system on my TREX 450SE Heli. Loftier goals of AP with RTL and WPs may well follow.
If you are interested in something similar, please post and describe your interests. Perhaps we can help Bill on some of the CCPM-specific issues.
John
Replies to This Discussion
-
Permalink Reply by WayKewl on -
John and Bill,
I am also interested in bringing my TREX to a good autonomous hover. I am a rather novice in embedded design world and have studied the basic stamps. I thought about designing a UAV board myself, but I was happy to discover the Bill's UAV board which should do basically what I wanted to do. I am not sure how capable the board would be, but I believe it has (almost) enough horse power to program auto-hover, take off/land, and simple WPs. It is my very first attempt in PIC controller though. I know I have a lot to learn, but willing to put some time into this for years to come. I'll take small and easy steps. I thought about starting out with a single axis gyro and getting accustomed with PIC programming, but I did not see much advantage, so I decided to jump into the full IMU. Like Bill, this is just my hobby. I have background in rotorcraft control design, and been flying RC helis for years.
As discussed, the current 3 PWM outputs can go to 3-servo CCPM swashplate. The issue is the tail rotor which can be stabilized with a RC gyro like Futaba 401, but cannot be guided autonomously unless Bill can suggest a way to implement an extra output.
The ESC can be set in governor mode, so no active control is necessary for the throttle.
-
Permalink Reply by John_Mac on
-
WayKewl
I have to do a little catch up as well. I have played around with mid-range PICS in assembly and PicBasic Pro, as well as programming in Visual Basic, but not C...so learning as we speak. I have a couple RC Helis and an RC airplane and have done some aerial photography with both...always wanted to get into AP. My background is in Physics.
I still have to buy the UAV board and a few of the components, but going thru the code and documentation to try and understand what Bill has done. His documentation is exceptional. I eagerly await their next set of documentation on the direction cosine matrix approach.
I wonder if as a first goal we could think about just pitch/roll stabilization, with the ability to manually adjust throttle/blade-pitch and rudder (using existing rudder gyro for yaw stabilization). This would allow for stabilized forward flight with manual throttle adjustment.
John
-
Permalink Reply by William Premerlani on -
WayKewl,
Based on a suggestion from Ben Levitt, I think it is possible to achieve 5 PWM inputs, and 6 PWM outputs with the UAV DevBoard. For sure it can do 6 PWM outputs. Ben is going to see if he can get and extra PWM input working.
Best regards,
Bill Premerlani
-
Permalink Reply by matthewlim on
-
Hello,
Thanks for showing me this thread. Our group is composed of mainly programmers, none of which have any helicopter flying experience. I actually crashed the helicopter into a coffee table the other day, and one of my partners is replacing the broken parts on the helicopter as we speak... the dsPIC controller is a pretty complicated device... Right now we've been able to monitor the outputs of the three gyros and accelerometers over a serial connection, but all of the data is pretty noisy and we're a little bit cloudy as to choosing a proper sampling rate/conversion method.
We're all undergraduate computer engineering students in an embedded systems design course, so this is really more of a difficult project than a hobby, haha.
Matthew Lim
-
Permalink Reply by John_Mac on
-
Great to have you on board.
Can you tell me what kind of Heli you are using? Is it CCPM with three servo swash? WayKewl and I may be able to help you with some of the control issues related to this type of Heli. Bill is clearly the expert on the programming and Physics/Engineering.
I agree the dsPIC is pretty complicated (at least from what I am used to...mid-range PICs like 16FXXX), but the performance is impressive...so worth learning.
Just some info on RC Helis...
1) The joy of Helis is 10% flying and 90% fixing
2) Flying Helis is more suggesting the direction in which to crash
Thus you see our interest in stabilization:)
Best,
John
-
Permalink Reply by matthewlim on
-
Oh man.
Points 1 and 2 are a little less than encouraging, haha.
We're using an Exceed-RC Genesis 450, i believe it is CCPM and it does have a 3 servo swashplate.
Right now, all of us are pretty bad at flying it :/
-
Permalink Reply by John_Mac on
-
Don't be discouraged!
Have to wait to see the Direction Cosine code, but in general the Pitch and Roll outputs would be mapped into inputs to the 3 servos...something like:
Servo 1 (forward) = Del_Throttle + Del_Pitch
Servo 2 (Rear Left) = Del_Throttle + Del_Roll + 0.5*Del_Pitch
Servo 3 (Rear Right) = Del_Throttle - Del_Roll + 0.5*Del_Pitch
Where Del_* is the correction applied for Throttle/Roll/Pitch
The order of Servo 2/3 will depend on how your Tx/Rx is hooked up and how the corrections are calculated (sign)...might have to reverse.
Basically this reflects that the Throttle requires all servos to move up/down together for collective pitch, Servos 2/3 will move equal but opposite amounts for Roll, and Servo 2/3 will act together but opposite to Servo 1 to accomplish Pitch. The 0.5 factor is just the fact that Servo 2/3 are only 1/2 way back on the swash due to the 120 degree layout.
But details await Bill's code.
-
Permalink Reply by William Premerlani on
-
John,
I was not planning on writing any helicopter code, but if there is some interest, I might change my mind. However, it might be a while before I got to if, I have a fair backlog right now. Two things that I am focused on right now are documenting the direction cosine matrix (DCM) algorithm, and finishing up "MatrixNav" firmware for planes.
So, here are two suggestions:
1. If someone else wants to design and implement the controls to build on top of DCM, I could mentor them, they could start as soon as they want. The "observer" portion of DCM is already done, its the roll-pitch-yaw demo. The next step is to use the elements of the matrix as inputs to the heli controls. I was not planning on doing this, but if someone else wants to do it, I could help them.
2. If you are willing to wait a while, I might eventually implement the controls for a heli, but I cannot promise anything. If I were to do that, I would want to test the code before releasing it. I have a helicopter (Hirobo shuttle), I have flown it a bit, but as you say, mostly I just give it suggestions on where to crash. It has been sitting on my shelf for a few years. Possibly I could fly it with the aid of my board, but it would take a while, because I am NOT a very good heli pilot.
-
Permalink Reply by John_Mac on
-
Bill
I was assuming that I would just mod your code once I saw it. I did look at the r-p-y demo and I think my approach would work fine with it.
Sorry, I should have been more clear.
-
Permalink Reply by William Premerlani on
-
John,
I apologize, I misunderstood you.
Your general approach will work just fine. Obviously, there are some details to be worked out, such as how you are going to blend manual signals and stabilization signals, the dynamics of the feedback controller that transforms the direction cosine elements into feedback signals to your servos, and feedback gains.
-
Permalink Reply by John_Mac on
-
Bill
In looking at your GentleNav code, it appears that you have "fly by wire" mode (radio_on flag set) where you take the Rx value and add the corrections to it to get the final servo PWM (elevatorCntrl.c and rudderCntrl.c). So I thought would take the same approach in taking the pitch, roll, and throttle Rx values and add your corrections to them in a similar fashion. That is why I was awaiting your new code to see if it would still fit.
Do you think that would work?
John
-
Permalink Reply by William Premerlani on
-
John,
What you have in mind should work. My new code, "MatrixNav", will be very similar to GentleNav, except it will use direction cosines for navigation and control. In manual mode, the Rx values will be passed straight through to the servos. In stabilized mode, the Rx values will be added to the stabilization signals. In RTL mode, the trim values measured on power up will be added to stabilization and navigation signals.
MatrixNav will control rudder and elevator only, no throttle control. Throttle is controled directly from the Rx. For those who want to control throttle through the board as well, it will be a simple matter to write some code to do that. I will eventually do that, too, for the time being I am willing to control the throttle myself.
So, you might well ask, what do I do when I lose signal? I happen to be using an Rx with programmable fail-safe mode, so my firmware does not directly detect loss of signal. Instead, when my Rx detects loss of signal, it shuts down the throttle, and sends the board a loss of signal indication on channel 4, just as if you had commanded RTL manually at the transmitter via channel 4.
If you are not using an Rx with fail-safe mode, and decide to control the throttle directly from the Rx, be sure to find out what happens when you shut the transmitter off, before you take to the air.
best regards,
Bill Premerlani
© 2010 Created by Chris Anderson.
