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.
John, Which gyros did you end up using? ADI ADXRS610? I'd be interested in the new gyro boards, or at least the Eagle files and make some up. Cant wait to see some documentation and code.
We used ADI ADXRS610 gyros mounted on a redboard, just to see how the firwmare would work with good gyros with a 300 degree range.
SparkFun sold me a couple of redboards that they had that did not have gyros, but they made it clear that they did not want to get into the business of selling boards without gyros, mostly because they were afraid that there would be confusion between the two types of boards, and there would be irate customers calling in demanding to know where the gyros were.
Anyway, over this winter I hope to design the next version of the board, that will have vibration-resistant, 300 degree/second, flat mounted gyros. (Probably the Invensense gyros.).
The plan is to continue to sell the "redboard" as well, so there will be two boards available.
I am not planning on using the razor. Whatever we use will be thoroughly tested for vibration sensitivity before the board goes into production, I promise you that!!
I was actually thinking you had some extra gyro boards with the 610's on it, not the main board. I'll wait for the latest and greatest. In the meantime I'll play with the red board in my airplane.
Winter is coming here also, so I'm trying to get in as much flying time on the Heli as I can. Electronic projects get high priority during the winter months. I really like the idea of the gyros to be mounted flat. It will also be nice to have more hardware PWM ports.
After being plagued by mechanical issues on my heli (that are unrelated to the dev board) I finally got some good results. Many thanks to Bill and John for helping me through this!
My setup:
Esky 450 Belt-CP v2
Green Board
NO GPS
In this video, you'll see that it takes off and hovers on it's own for about 55 seconds. During this whole period I do not apply any pitch or roll input - only throttle and minor yaw correction. It does "wander" a bit, as John warned me it would do. Nonetheless, it's very stable. BTW, the video was taken in true DIY style with my camera attached to my head, so it's not perfect. =)
In my testing, I think this is about as good as it will hover without macro level correction from a GPS and compass. It was a near windless day and sometimes it wanders right, sometimes forward, sometimes back, etc. I think it mostly depends on the initial conditions at take-off and other subtle influences. At times it will hover in exactly one place for 5 seconds or so with no input at all from me.
I also attached a picture to show how I've mounted everything. Basically I got a piece of clear acrylic and notched holes for the skid mounts to slide between and then used zip ties to pull the skids back together to keep everything tight. I then attached the dev board, rx, and training wheels to the acrylic. It works quite well. I could probably use a thinner piece and smaller bolt to reduce the weight, but it's a good setup for testing.
So what's next?
My vision of the ultimate helicopter drone is to have it fly itself, and receive commands from a user without using the stock Tx/Rx.
To do this, the following would have to happen:
1) I'll need to add GPS and Compass data. Besides the one suggested on the main page, is there another compatible GPS unit that also has a magentometer?
2) Change the dev board rx inputs to outputs so that it can control the ESC and tail servo. Is this possible?
3) Either the tx or rx is doing the CCPM mixing. If it's automated and that system removed, the dev board will have to do it. Any ideas where to start?
4) I also want to use a pair of 802.15.4 tranceivers and the spare UART to relay information from the dev board back to a PC. This could be used to receive log data and send control instructions.
The GPS resolution is simply not sufficient to keep a lock on hover. Airplanes get good velocity into since they are moving at a brisk rate....a big difference with helis in hover. I don't know of a GPS/magnetometer combo. I was looking into the GPS used in its normal configuration (needed for the centripetal force correction on a steady fast turn) and adding a magnetometer. SparkFun has a couple 3 axis mags. A 2 axis could work combined with DCM info. In any event you need to know the orientation of the heli wrt earth frame.
The next gen board may have more in/out channels. Right now Ben Levit has a scheme to get more channels out of the existing board. You can look that up on this site. Right now we exhaust all of the USB in/out with the 3 swash servos and command channel. But this is enough for stabilization.
The TX does the CPPM mixing. My swash code does some of that in heli version of AileronAssist. It is not that much more work to add the throttle/pitch calc to it if there is a throttle input to the board.
Throttle control is a little tricky too. For an airplane, the GPS resolution is adequate since it is at a high altitude. For a heli hover at say 10' or so, the GPS simply does not have enough altitude resolution. If you fly higher, I suspect our could use the standard altitude control that is in recent versions of the code.
Use of the UART for telemetry is being done now....just search the site.
As we discussed, you are probably going to want to have some foam vibration isolation on the board. I believe we have both seen evidence that the gyros are saturating at certain throttle settings. If this happens in flight, it could be quite challenging to recover from.
I looked at Ben's solution. It looks like it's basically using the spare I/O pins for PWM signal input and output and relying on a receiver for powering the additional 3 servos.
Since I'm looking for a solution that doesn't need the receiver, I'm not sure this is the path to go down.
I was reading the red board manual (even though I have the green) and saw that the radio inputs and servo outputs share a power bus, correct? If so, it seems like the easier thing to do is plug all the servos and ESC into the board and generate PWM pulses using the radio input pins for the tail gyro and ESC control. Or will that not work for some reason? Is there a hardware reason why the radio inputs can't function as servo outputs?
Another approach is to build a "shield" board, such as what Rana has done, or an "oil-pan" board, such as what Dedadz has done. If you are interested in either of those approaches, I suggest you contact Rana or Dedadz through the uavdevboard group. In both of their approaches, they extend the "raw" power and ground bus for the extra channels. That way, you get 5 PWM inputs and 6 outputs arranged as 3 pin channels. This is the "hardware" solution. Ben Levitt wrote the firmware for the extra channels, which has been thoroughly tested.
Regarding the other, hardware, solution that you suggest, by simply using the 7 PWM I/O channels that are already on the board. It would certainly be possible to use some of the inputs as outputs instead, providing the total of inputs and outputs is no more than 7. But, although I did not count up your channels, it seems to me that 7 is not enough for a heli. In any case, it also seems to me that is would be difficult to get by with less than 4 PWM inputs. But if you can get by with less than 4, then it is possible, but the firwmware would have to be extended. If you decide to go that route, I suggest contacting Ben.
Personally, I think the best way to go is to use the spare pins and the existing firmware that Ben wrote. If you don't want to build a shield or an "oil-pan", you can make up special cables, its not hard to do. If you just want another output or two, you could use a "Y" cable splitters to pick up power and ground for each extra output. Cut the signal pin on one of the outputs of the Y, and solder it to the appropriate spare pin on the board. Then, the uncut side of the Y would be carrying the signal, power, and ground, for the channel it is connected to, and the cut side of the Y would be carrying the signal, power, and ground, for the extra servo, controlled by the spare channel.
In any case, I strongly suggest you post to the uavdevboard group, there are plenty of people there who will be willing to help you.
Congratulations to the successful flight! That looks really promising.
I have been sitting on the sideline for a while now, awaiting results regarding the redboard and working gyros, so I have no project of myself to showcase yet.
I can see that your vision of a UAV drone is very similar to mine. I have been thinking for a long time of one and found this page some time ago. After reading a bit of the projects here and mailing with Bill I decided to make a go for it.
My Vision is as I said very similar to yours, but I would like to see the final product "modular". That is taking the "redboard" more er less as it is, and then add peripheral modules to it for added functionality.
Example:
The redboard is today a more or less working stabilizing unit to which you could link a NAV computer for waypoint navigation. This NAV computer should have ports for a larger sensor array as it will need GPS, magnetometer / fluxgate, for positioning and attitude, ultrasonic transducer or laser for near ground altitude, perhaps optical sensors for "on-the-spot" hovering, and so on. The NAV computer should also have a port for wireless link to groundstation.
This way you could build an expandable system that grows from being a simple "stability assisting" device, to a full grown UAV system without being too expensive or complex for people with only the basic needs of a simple flight stabilizer.
I have not studied the hardware in detail, but I guess that this is possible? The MCU have an I2C bus, and that could maybe be one way of building the inter-module communication channel?
What do you think? Have you made any thoughts around this yourself?