Progress Report on UAV DevBoard application to CCPM Helicopters
As promised, this post describes where we are in the development of the UAV DevBoard for stabilization of a CCPM Helicopter. It is still a work in progress and should not be regarded as an out-of-the-box ready-to-go system at this point.
First I want to acknowledge all the help Bill Premerlani gave in this development. Without his UAV DevBoard, his innovative DCM control formalism, and keen programming skills, this development would not have been possible.
I will take you through our development process and point out some of the pitfalls and key issues we encountered. Our hope is that others will pick up on the development and bring it to a quicker conclusion.
The progress report can be found here.
Replies to This Discussion
-
Permalink Reply by Justin on -
Hi Bill,
I made 4 changes total, 2 in radioIn.c and 2 in states.c. The whole project is attached. My changes are commented with my initials JTB to make them easy to find.
Where is in the code is the other check against Channel 4 made? I couldn't find it.
Thanks!
Justin - Attachments:
-
-
Heliv6810JTB.zip, 375 KB
-
-
Permalink Reply by William Premerlani on -
Justin,
There are two places where the fast manual override is performed.
One of them is in elevatorCntrl.c:
// WJP added check for fast return to manual control
if ( flags._.pitch_feedback && ( pwc1 > 3000 ))
{
// WJP added pitch damping term, pitchrate*pitchkd
elevAccum.WW = __builtin_mulss( rmat[7] - RTLKICK , pitchgain )
+ __builtin_mulss( pitchkd , pitchrate ) ;
//WJP added pitchboost computation
pitchInput = pwele - elevtrim ;
pitchboost = (__builtin_mulss( pitchInput , boostgain ) >>3 ) ;
}
else
{
elevAccum.WW = 0 ;
pitchboost = 0 ;
}
The other place is in aileronCntrl.c:
// WJP added check for fast return to manual control
if ( flags._.GPS_steering && ( pwc1 > 3000 ))
{
etc..
I think those are the only two places that you missed, but you might want to do a "search in all files" for pwc1.
Unless pwc1 is greater than 3000, the PWM computation, which runs 40 times per second, will simply pass through the PWM input channels to the PWM output channels and ignore the stabilization and navigation signals.
Best regards,
Bill
-
Permalink Reply by Justin on
-
Bill,
I also changed the check in elevatorCntrl.c and aileronCntrl.c to use pwc2 instead of pwc1 and now it's responding to both the Tx and movements of the dev board. Woo hoo!
A couple things:
1) Can you explain further what we're doing when checking for pulse widths above 3000? Why 3000? When I move the Tx stick pitch forward or roll left more than about half way, it fails this check and temporarily goes to "manual" mode for a couple seconds. Does this value just need to be changed for my heli?
2) I currently have the board oriented with the GPS connector toward the rear, as John did. I want to make sure I understand the physics correctly. If the dev board pitches down (i.e. the gps connector becomes higher than the servo connectors) then the swashplate needs to pitch "backward" (the side toward the front becomes higher than the side toward the rear). Or basically, the swashplate should tip in the opposite direction as the dev board.
If that's the case, then it looks like all I'll have to do is change the sign of the front servo so that it's doing the opposite as it is for John's heli.
Justin
-
Permalink Reply by John_Mac on
-
Hi Justin
I have the GPS connector on the board to the front. The GPS just happens to be physically located at the rear for easy mounting.
Let me also give a word of caution. Even with the heli firmly held down to your test stand, you can still get into trouble. If the firmware/hardware is not well debugged, it is possible to get strange behaviors with the servos that could very quickly cause a blade strike. If you are near it (as in observing servo motion etc) you can get seriously hurt. I strongly suggest that you do extensive debugging without powering up the rotor. And always wear eye and face protection if you are up close to the heli when anything is spinning. This is very important.
Best,
John
-
Permalink Reply by William Premerlani on
-
Justin,
1. What is going on is that pwc1 is supposed to be solely the mode control. The way that pwc1 is used by my firmware is that it is both a health check, and a mode control. The value 3000 is the boundary on that channel between manual and stabilized mode. By switching the role of pwc1 to pwc2, you are giving pwc2 double meaning. It is both a servo command, and a mode command. You are either going to have to put it back the way it was, and supply the 4th channel, or "we" (you, John, or me) will have to modify the code to put it always in stabilized mode. That would not be hard to do, but of course you should not fly it that way, it would be for test purposes only.
2. Regarding the physics, you want the servos react in a way to counteract the disturbance. For example, if you pitch the heli forward, you want the servos react to pitch it backward. You want negative feedback. Since the direction of deflection depends in an arbitrary way on how things are hooked up, there are switches on the board for reversing things. However, there is one detail that John and I have put on the back burner for now. We are not using the GPS, but when we do, we will have to come to grips with the fact that my firmware assumes the GPS connector points forward. It has an impact on yaw compensation. There is no switch to reverse that, we will eventually have to modify the configuration file to provide an option.
Best regards,
Bill
-
Permalink Reply by Austin Laws on -
Shame someone couldnt use FMA co pilot 2 which surrports CCPM and adrupilot for the rest. ive no idea if its possible
-
Permalink Reply by Jerry Chapman on
-
Hi, I'm a newbie here but would like to become involved in this project. I'm a sport flyer when it comes to RC helicopters and lots of years flying the RC airplanes.
I have hobby experience with the Microchip embedded processors(mostly 18's and 16's). I have the Microchip Real Ice and the Explorer 16 board and others. Used to design and program Z80 and 6809 designs professionally, 20 years ago. Now I just work as a PC programmer. I know how to use Eagle V5.1. Just had a couple of boards made by BatchPCB for a voltage datalogger and a Current datalogger with USB interface for my Raptor E550 helicopter.
I read how the gyros are having vibration issues on the red board. If somebody wants to specify a better gyro, I would have no problem modifying the design and the board layout to use them. It seems like such a waste to have all the research and software almost there and not be able to use it on a helicopter.
Jerry
-
Permalink Reply by William Premerlani on
-
Jerry,
Once flying season is over for me, I am going to design a new board for SparkFun to produce, probably using the Invensense gyros.
In the meantime, anyone is free to copy the hardware and firmware that is already there. Its all open source. You can get the schematic of the red board from the SparkFun website.
I figured out that you could start with the red board, and substitute any of the latest Analog Devices breakout boards from SparkFun. You would run them at 5 volts, run the accelerometers at 3.3 volts, and use the 3.3 volt supply as a reference voltage, because the 5 volts won't be 5 volts.
We want the 300 degree per second, ADI ADXRS610 gryo.
Best regards,
Bill
-
Permalink Reply by Jerry Chapman on
-
Bill,
I went ahead and bought the red board from Sparkfun. Received the board today and its pretty neat. Of course I went thru all the hassle of trying to make my Real Ice work with the board. I had already read about the trouble that others have had. Went to the earlier version of MpLab 7.5, it still didn't work. I went back to MpLab 8.36 and of course it still didn't work. I have an adapter from Microchip, RJ-11 ICSP adapter (AC164110) that I used and connected directly to the molex connector on the board. The Real ICE works great now. Must be something with the Sparkfun adapter that causes the issue.
So I ran the self-test program and it rocks. All 3 axis work the servos correctly.
At this point I'm just trying to understand your program. The programming is great and pretty easy to follow so far. But one thing I dont understand is the #define indicate_loading_inter. I know how #define works, where ever indicate_loading_inter; is, substitute something. What is that something? I looked at options.h where you declared the #define indicate_loading_inter, nothing follows it. I know how the interrupt routines work, except for that piece. I notice Ben using something similar in his interrupt routines where he saves at the beginning and restores when returning from the interrupt routine. Thanks in advance for answering my question,
Jerry
-
Permalink Reply by William Premerlani on
-
Jerry,
Welcome aboard.
You are right on the money about how #define works...it is a substitution macro.
I use the #define indicate_loading_inter to measure the CPU loading when I am interested in that. Right now, indicate_loading_inter does not have anything defined to be substituted. So it does not do anything in the released firmware.
When I get interested in CPU loading, which I do from time to time, I define indicate_loading_inter to assert 5 volts on one of the spare digital pins. Then, all of the interrupt service routines raise that pin when they are running. I use a #define for the main loop which asserts 0 volts on that same pin. I then filter and measure the output of that pin, and what I have is the CPU loading!
The reason that I do not leave it defined and running is that Ben Levitt has found a way to get 5 PWM inputs and 6 PWM outputs from the board, and he uses all the pins, and I do not want to interfere with that.
The reason that I do not just delete it all together is because then I have a lot of typing to do when I want to use it again.
If you look around my code, you will see several other things like that, such as things that are commented out and #ifdef used to turn some debugging code on or off.
Best regards,
Bill
-
Permalink Reply by John_Mac on
-
I wanted to post a quick update on the Heli development with the UAV DevBoard.
Bill and I have been working on quite a few aspects of this with some good success, but also with some limitations.
Just to summarize, we started with the Red Board and found that the gyros on this board were very sensitive to the vibrations generated by the helicopter. While it may be possible to pursue a vibration isolation project, we decided to go to the Green Board. The Green Board's gyros are much less sensitive to vibrations. I saw no evidence of saturation or instability due to vibrations with the Green Board (that isn't to say there is no effects, just not observed so far).
In going to the Green Board we were able to implement several improvements such as parameters to compensate for both pitch and roll tilt physical effects for a stable hover, improved derivative gain for better damping, to name a few. I was able to achieve a very stable hover with this configuration. I still have to "keep it in the box" since it does not do translational stabilization and there will always be wind effects and non-ideal trim effects. But it was never meant to be a "hands off" system (at least not yet).
The limitation of the Green Board is that its gyros saturate at 75 degrees/sec. The Red Board was at 300. 75 sounds like a lot, but it is rather easy to exceed this if you are making abrupt corrects or a little more aggressive flying. Once the gyros saturate, the swash goes into a very angled configuration and it takes 15 or more seconds to recover. If you do not quickly switch to Manual mode, you will certainly plant the heli in the ground. Even switching to Manual does not guarantee you can recover fast enough.
The final change was that Bill got some Red Boards without gyros and put some 300 degree/sec gyros on it. I am currently flying this configuration and it looks quite good, but my test flights are limited since Winter seems to want to arrive very early here. These new boards are in very limited supply, but there is some possibility to make some more up.
I will post a more detail discussion of the development, as well as the code and documentation, but this may take a while to get together. I just wanted folks to know where we were in the process. All in all, I think it has been very successful and there are many new directions to pursue.
Best,
John
Top Content
Groups
-
ArduCopter User Group
477 members
-
ArduPlane User Group
299 members
-
ArduCopter (traditional …
77 members
-
ArduPilot (legacy) User …
77 members
-
Moderators
50 members
-
ROS User Group
31 members
-
Team Prometheus
11 members
© 2012 Created by Chris Anderson.
