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.
You need to be a member of diydrones to add comments!
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.
I dug around in the code a little bit and saw the states.c file where control is passed between the 3 modes.
I hacked it up a bit so that it's looking for input on pwc2 (Ch. 3) instead of pwc1 (Ch. 4). I also re-connected everything so that it lines up with John's setup in the progress report.
This seemed to work pretty well. The green light stays on and pitch inputs from the transmitter are responded to mostly by the front servo and roll inputs mostly by the right and left rear servos.
However, the next problem is that the servos don't respond at all to the dev board deflections. Thinking this must mean it is in manual mode, I put some breakpoints in the states.c file as it was running. In the state_machine function it seems to reliably hit the 'else if' clause that is commented "Auto, stabilization mode".
Also, the interrupt handler in analog2digital.c seems to reliably run as well, which I believe is the handler for the gyro and accelerometer inputs, correct?
Is there something else that is causing it to ignore the gyros?
Bill helped me get the issue with the servos worked out...although it was a rookie mistake of having the pins connected backward. =)
John,
Can you describe how you've connected your receiver to the 4th input channel? Bill mentioned that the code won't work unless it's receiving input on all 4 in a post above.
I've loaded up your v6 code on my green board. I have the 3 channels from the receiver that would normally go directly to the servos connected (properly this time) to channels 1, 2, and 3 of the dev board. It powers up but only the red light comes on, which indicates that the firmware thinks the receiver is off, according to Bill. Moving the receiver sticks doesn't move the servos at all.
I'm trying to get started with my own green board by replicating your results. I have an Esky Belt-Cp 450 v2 with the 3 outputs from the radio connected (that were originally connected directly to the servos) to the first 3 input channels on the board. The 3 swashplate servos are connected the 3 servo outputs on the board.
I loaded up the Self-Test code and stepped through it with the debugger such that I can see the LED lights go on and off, so I'm pretty sure my environment is working.
The problem is that the servos (Esky EK2-0508 Digital Servo) do not respond to either movements of the stick or movements of the board. I also tried it with your Heli_v6 code with the same result.
Breakpoints in the interrupt handlers for all 4 receiver channels never seem to get hit.
I can measure about 3.2 volts across the receiver inputs and servo outputs on the board when everything is connected up and powered on.
Any idea what I'm doing wrong or what I can try next to troubleshoot?
I was reading the thread content with regard to the issue of vibration "noise" clouding the sensor inputs and how you are trying different ideas to isolate the components from the vibration.
To think somewhat outside the box (marginally) I imagined an alternative approach to solving the issue by perhaps trying something odd.
To illustrate my thought I will use a non-elegant example:
Suspend, by a line, a "box" containing all of the sensors (gyros, accelerometers, etc.) perhaps by a few feet so that it follows the aircraft like a target drone (or flying box much like the fuel nozzle used to refuel aircraft in midair) and let it hang (while hovering) or trail while in forward flight.
Suspending the box by a single cable may isolate this blanket of "noise".
Then - the odd bit - fly the box - not the helicopter. In other words, make the goal to stabilize the box (ultimately using the control inputs to the helicopter) much like a pilot uses their sensory input to stabilize their environment in reference to the horizon or perhaps intruments.
The problem you are describing is much like taking a VFR pilot and immersing them into an IFR condition. The clouds make them blind to what their "sensors" need to fly the helicopter, much like the vibration is creating a "cloud" around your sensors.
Again - not meant to be a particular solution to be followed verbatim, however just a thought about changing the enviroment variables a little.
Without a compass, how do you keep the Yaw under control? If you're just using gyros I'd expect it to drift pretty quickly. I think you can't rely on the gps if you're not moving around.
Marcus,
any chance of a picture of your rig for holding the heli whilst testing? I have been thinking of options for my own and have some ideas but it would be interesting to see what you have done and whether it works?
Well, I must say there have been some hours of interesting reading, reading this thread!
I found it by doing some research for a project that I think everyone here can relate to:
I have been flying RC gear for many years, including RC copter, but that interest cooled down almost 20 years ago. Recently I was browsing the web and came across some articles regarding RC copters and I was amazed of how far the development has gone!
Due to newly awaken interest for the hobby, I bought not one, but two helicopters. (2 Kyosho Caliber 5) whereof one is built and flight calibrated, and the other is un-opened in box for spares. Maybe I will convert one of these to electric, I am doing research for this at the moment.
When reading about how this RC-helicopter marked has exploded the last years I realized the need for a stabilizing system that could be implemented to almost every "decent" chopper. This for helping fresh pilots avoid the most unnecessary crashes. Since I have some experience in PIC programming and prototyping, I decided to give it a go, and here I am. Doing research...
My original thought was to develop a stabilizing system for the roll and pitch axis since a standard yaw gyro works well. If successful I was going further from manual, to assisted, to an-assisted autopilot. I was going for a PIC based design utilizing 3xgyro and 3x accelerometers for base, and perhaps some other sensors for redundancy. Now I realize that all the hardware development is already done, and the firmware is about to mature. This is actually VERY close to what I was intending. I understand that the development have been VERY fast on this "heli-port" of the firmware for the UAV Dev Board, and that it has run in to a difficult problem, namely vibration problems in the gyros used.
I would love to get started on a board myself, trying to help you out with this issue, if I can... I will at least give it a serious go...
Is there any chance to get the latest version of the firmware for helicopter, ported by John Mac. (3 servo swash)? In case I can get hold of it I will buy a board at once and do some testing of my own.
Is there any more of the "green boards" floating around, I will buy one of those as well to do comparative tests in a lab that I have access to. (Institute of Physics at the university here in Tromsø).
Bill and I pretty much determined that the problem we were seeing where the swash servos would run completely in one direction at moderate to high RPM was due to vibration effects on the gyros (not accel's). Bill loaned me his Green board with the ADXRS401 gyros to test.
With no vibration isolation, the Green board showed no signs of the saturation effects.
With minimal gain tuning I was able to get the board to completely stabilize the heli. Since there is no compensation for lateral displacements, I still had to correct somewhat to keep it from drifting off in the horizontal plane, but the attitude was rock solid in the horizontal. In some sense it behaved much like a Blade CX2 that quickly regains a vertical attitude after removing pitch or roll inputs.
I did notice that I had to input a lot more pitch and roll to make small correction over manual mode. This is an artifact of how the Tx inputs are added to the correction signal to the servos and can be tuned to provide more gain to Tx inputs. The net effect was after carefully tuning the hover in manual, I had to trim much more to get the same hover performance.
I still have a lot of tests to do, including vibration damping on the Red board to see if this cheaper board can still be made to work.
Bottom line is the Green board does a great job of stabilizing the heli! And also confirms it is the gyros, not the accel's.
Replies
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
I dug around in the code a little bit and saw the states.c file where control is passed between the 3 modes.
I hacked it up a bit so that it's looking for input on pwc2 (Ch. 3) instead of pwc1 (Ch. 4). I also re-connected everything so that it lines up with John's setup in the progress report.
This seemed to work pretty well. The green light stays on and pitch inputs from the transmitter are responded to mostly by the front servo and roll inputs mostly by the right and left rear servos.
However, the next problem is that the servos don't respond at all to the dev board deflections. Thinking this must mean it is in manual mode, I put some breakpoints in the states.c file as it was running. In the state_machine function it seems to reliably hit the 'else if' clause that is commented "Auto, stabilization mode".
Also, the interrupt handler in analog2digital.c seems to reliably run as well, which I believe is the handler for the gyro and accelerometer inputs, correct?
Is there something else that is causing it to ignore the gyros?
Getting closer....
Justin
Bill helped me get the issue with the servos worked out...although it was a rookie mistake of having the pins connected backward. =)
John,
Can you describe how you've connected your receiver to the 4th input channel? Bill mentioned that the code won't work unless it's receiving input on all 4 in a post above.
I've loaded up your v6 code on my green board. I have the 3 channels from the receiver that would normally go directly to the servos connected (properly this time) to channels 1, 2, and 3 of the dev board. It powers up but only the red light comes on, which indicates that the firmware thinks the receiver is off, according to Bill. Moving the receiver sticks doesn't move the servos at all.
Thanks!
Justin
I'm trying to get started with my own green board by replicating your results. I have an Esky Belt-Cp 450 v2 with the 3 outputs from the radio connected (that were originally connected directly to the servos) to the first 3 input channels on the board. The 3 swashplate servos are connected the 3 servo outputs on the board.
I loaded up the Self-Test code and stepped through it with the debugger such that I can see the LED lights go on and off, so I'm pretty sure my environment is working.
The problem is that the servos (Esky EK2-0508 Digital Servo) do not respond to either movements of the stick or movements of the board. I also tried it with your Heli_v6 code with the same result.
Breakpoints in the interrupt handlers for all 4 receiver channels never seem to get hit.
I can measure about 3.2 volts across the receiver inputs and servo outputs on the board when everything is connected up and powered on.
Any idea what I'm doing wrong or what I can try next to troubleshoot?
Thanks,
Justin
To think somewhat outside the box (marginally) I imagined an alternative approach to solving the issue by perhaps trying something odd.
To illustrate my thought I will use a non-elegant example:
Suspend, by a line, a "box" containing all of the sensors (gyros, accelerometers, etc.) perhaps by a few feet so that it follows the aircraft like a target drone (or flying box much like the fuel nozzle used to refuel aircraft in midair) and let it hang (while hovering) or trail while in forward flight.
Suspending the box by a single cable may isolate this blanket of "noise".
Then - the odd bit - fly the box - not the helicopter. In other words, make the goal to stabilize the box (ultimately using the control inputs to the helicopter) much like a pilot uses their sensory input to stabilize their environment in reference to the horizon or perhaps intruments.
The problem you are describing is much like taking a VFR pilot and immersing them into an IFR condition. The clouds make them blind to what their "sensors" need to fly the helicopter, much like the vibration is creating a "cloud" around your sensors.
Again - not meant to be a particular solution to be followed verbatim, however just a thought about changing the enviroment variables a little.
any chance of a picture of your rig for holding the heli whilst testing? I have been thinking of options for my own and have some ideas but it would be interesting to see what you have done and whether it works?
Thanks,
Mike
Well, I must say there have been some hours of interesting reading, reading this thread!
I found it by doing some research for a project that I think everyone here can relate to:
I have been flying RC gear for many years, including RC copter, but that interest cooled down almost 20 years ago. Recently I was browsing the web and came across some articles regarding RC copters and I was amazed of how far the development has gone!
Due to newly awaken interest for the hobby, I bought not one, but two helicopters. (2 Kyosho Caliber 5) whereof one is built and flight calibrated, and the other is un-opened in box for spares. Maybe I will convert one of these to electric, I am doing research for this at the moment.
When reading about how this RC-helicopter marked has exploded the last years I realized the need for a stabilizing system that could be implemented to almost every "decent" chopper. This for helping fresh pilots avoid the most unnecessary crashes. Since I have some experience in PIC programming and prototyping, I decided to give it a go, and here I am. Doing research...
My original thought was to develop a stabilizing system for the roll and pitch axis since a standard yaw gyro works well. If successful I was going further from manual, to assisted, to an-assisted autopilot. I was going for a PIC based design utilizing 3xgyro and 3x accelerometers for base, and perhaps some other sensors for redundancy. Now I realize that all the hardware development is already done, and the firmware is about to mature. This is actually VERY close to what I was intending. I understand that the development have been VERY fast on this "heli-port" of the firmware for the UAV Dev Board, and that it has run in to a difficult problem, namely vibration problems in the gyros used.
I would love to get started on a board myself, trying to help you out with this issue, if I can... I will at least give it a serious go...
Is there any chance to get the latest version of the firmware for helicopter, ported by John Mac. (3 servo swash)? In case I can get hold of it I will buy a board at once and do some testing of my own.
Is there any more of the "green boards" floating around, I will buy one of those as well to do comparative tests in a lab that I have access to. (Institute of Physics at the university here in Tromsø).
Kind regards
Marcus in the very northern Norway.
Bill and I pretty much determined that the problem we were seeing where the swash servos would run completely in one direction at moderate to high RPM was due to vibration effects on the gyros (not accel's). Bill loaned me his Green board with the ADXRS401 gyros to test.
With no vibration isolation, the Green board showed no signs of the saturation effects.
With minimal gain tuning I was able to get the board to completely stabilize the heli. Since there is no compensation for lateral displacements, I still had to correct somewhat to keep it from drifting off in the horizontal plane, but the attitude was rock solid in the horizontal. In some sense it behaved much like a Blade CX2 that quickly regains a vertical attitude after removing pitch or roll inputs.
I did notice that I had to input a lot more pitch and roll to make small correction over manual mode. This is an artifact of how the Tx inputs are added to the correction signal to the servos and can be tuned to provide more gain to Tx inputs. The net effect was after carefully tuning the hover in manual, I had to trim much more to get the same hover performance.
I still have a lot of tests to do, including vibration damping on the Red board to see if this cheaper board can still be made to work.
Bottom line is the Green board does a great job of stabilizing the heli! And also confirms it is the gyros, not the accel's.
I will post further test results as I get them.
-
1
-
2
of 2 Next