Given the following snippit of C code we are attempting to add damping or differential correction to the pitch stability. The values gain and DiffPitchRoll are constant doubles used to adjust the various gains. This chunk of code runs 75 times a second and er.Pitch is the IMU raw pitch output. Given we want rate damping what should the sign of the differential correction be ?
/*****************Code Snippit *******************/
static double pitch_prev;
double cur_pitch=PitchConvert(er.Pitch);
double pitch_err=Target_Pitch-cur_pitch;
double pitch_change=(cur_pitch-pitch_prev);
Elevator_Correction_Cmd=(-((pitch_err)*gain))?(pitch_change*(double)DiffPitchRoll);
pitch_prev=cur_pitch;
/*****************End Snippit *******************/
What should the Red ? Be?
If you choose ‘-‘ goto this video: Minus Video
If you choose ‘+’ goto this video: Plus Video
(We have a tethered burn time waiver inplace.)
The vehicle was undamaged in both videos above, We need to work on the altitude control a little bit more and we did eventually tangle the ropes around the the GPS antenna mast 3 flights after the “Plus” video and broke it off….all in all a good day.
14 comments:
Nice! That had to have felt good watching that! Looked very well controlled. At the end i couldn't tell from the video if it hit the ground. Sounded kind of bad though... Did the vehicle come through ok? If i may ask how did you get your waiver when the team at armadillo struggled? Is it location? I know FAR is out there...
-scott
Great hover, congrats on a nice milestone! Was the precession of the craft towards the end a result of the PVC tether-covers laying over to the side and messing up your vehicle balance?
Wow, positive feedback's killer huh?
No damage, The weirdness at the end is because it got to high and was fighting the tethers.
It held heading reasonably well until it tangled with the tethers.
The Waiver,we applied for a flight waiver 4 months ago and the tether is just an additional condition on the already in process flight waiver.
Also we are in the middle of nowhere.
Congratulations!
I've got to admit I flinched when the engine was shut off that high off the ground - that must be some rope. What's your tether setup's envelope of motion?
The Tether is Three 9.5KN dynamic climbing rope.
Yeouch! I definitely winced when the vehicle hit the end of the tether; glad nothing was damaged!
Good luck getting the altimeter working right; that will definitely be important! :)
Also...nice 360' flip there on the minus flight...
Great looking flight, its fantastic to see your work progressing so +vely.
Phil.
About your code snippet question:
Elevator_Correction_Cmd=(-((pitch_err)*gain))?(pitch_change*(double)DiffPitchRoll);
Why do you have a negative sign before ((pitch_err)*gain)) ?
You have already defined pitch_err to be negative by defining it as the commanded value, Target_pitch which I presume is zero, MINUS current pitch. If this is true, then that negative sign before ((pitch_err)*gain)) is superfluous. My guess is that your '?' should be a negative as well since it's a feedback to stabilize the system, but b/c of the sign error on pitch_err, your sign convention turned out to be stable when '?' was positive: I think it should be negative.
Just my thoughts...feel free to let me know if I am wrong. :)
Happy Monday!
Congrats for this first controled flight...
Anonymous commenter: No, your logic is flawed on the sign issue. You can see this with a quick thought-experiment: Simplify ((pitch_err)*gain) to a scalar value like "5". Also, simplify (pitch_change*(double)DiffPitchRoll) to a scalar value like "2".
So using your logic we get either:
(-(5)) + (2) = -3
OR
(5) - (2) = 3
...As you can see, they are NOT equal. :-)
--Noel
noel.wade,
He didn't say they were equal, just that they were apparently stable.
The danger of this is that the dynamics of the system can drive that equation unstable under certain conditions, while being stable under others.
I believe there may be something here...
Assume for a minute that the system is a straight zero order gain at low frequencies, commanded pitch is zero, and the current sensed pitch is -5 degrees.
Paul has defined error as (Target - Sensed). Thus, pitch error in this case is +5. Assuming a positive proportional gain, Kp, this will result in a positive elevator correction command. To me this makes sense... if we're below the target, the correction is positive.
Paul is negating that, such that if the error is positive (as he's defined it), the proportional component is giving a negative correction. I don't know how he's defined actuator polarity, but to me (and the other Anonymous) this is backward.
Now, for the damping gain stage, he has the pitch rate defined naturally as current minus previous. To damp rates, this should be a negative term.. I find it more clear to have every gain stage stated as a '+' stage (ie. summation into the overall output), with negative gains as required.
One problem I see with the correction equation is that a proportional gain stage can never completely remove steady-state errors. An integral stage is required (acting on the integral of pitch_err for example) to drive steady-state error out.
It may also be beneficial however for Paul to consider a differential gain stage, acting on the error differential, rather than absolute pitch differential as he has it now. That is, Curr_err - Prev_err. Before doing that, if I were Paul and co., I would try to understand the behavior of the system at the frequencies of interest.
I have never tried to design a controller for the rocket problem (or the pendulum), but it may be that a straight P-I controller will stabilize the system.
Disclaimer: I could be wrong in any of the above. :)
Addendum to my above:
I don't want to take anything away from what you just accomplished.. having a craft hover stably like that is a great accomplishment, only recently achieved by anyone in the world at any funding level. Congrats!
One other tip: clearer variable names will help you keep your sanity as you add layers of control.. eg. position-hold gains, trajectory tracking gains, etc.
I fail it! :)
I clicked on the video I selected (no spoilers here) while using a Terminal Server. The video is choppy that way, but usually good enough, especially for things like hovering rockets. In this case, though, the flip happened so fast I could barely see what happened!
I figure that the existence of that video means that you too failed it the first time you tested it, too, so at least I'm in good company!
Congratulations on the successful hover. Your continuing sucess, coupled with the additional time you're going to get and the possibility of spectators at LLC makes me wish I lived somewhere the Southwestern US... Michigan is just too far away to get there to see this. Wish I was there!
Post a Comment