I have just bought the ArduPilot Mega 2560 Full Kit... plus the Triple Axis Magnetometer HMC5883L. I should have it built over the weekend.. then i'm off to a my mates machine shop, and i'll make the splitter plate for the lower frame onto which i am going to fit the Ardupilot. the magnetometer i'll put on the tail as suggested. I am going to use my X-cell Razor 600E. For those that dont know its around the 50 size nitro heli.
Do i need to buy any other sensors i.e. the Sonar... i can fly a helicopter all day long but this is my first time flying one with stabilisation so any tips would be gratefully appreciated.
If this works well then i am going to try and use it on my x-cell gasser. i can get up to 20 minute flights with this. But i think for the time being a battery 600 is the way to go.
i'll post some pictures when i have it all together.
Wow, thanks for the input.
#1 - we could add in an offset to the roll to account for the tail. Actually I had it in there but took it out 'cuz you can accomplish the same thing with the trim. The only advantage is that we could only use the lean if you're actually in the air which might be a good way to stop the I term in the roll/pitch controller from building up before take-off. which I've seen it do.
#2 - I'm not sure about the configurable setting but I believe that the rate of decent is limited in the alt hold code for exactly this reason for the quad (which is fix pitch). Basically it can climb faster than it can decend. It doesn't currently know if you're moving or not but that could be added if enough people found it necessary.
#3 - in the latest versions of the code (for both quads and helis) the position hold code and the alt hold code have been changed to be nested PI controllers. the outside controller is a location (or alt) error, the inner one is a rate (i.e. speed) controller. I believe this will allow the control to be good near the hover and decent at getting to the next way point as well. That's my guess because I haven't tested it on the heli but we saw what you're talking about in alt-hold at least!
The external gyro is still required but that's more of a cop-out until time can be invested to get rid of it. Gyros are only $30~$50 which seems like a bargain compared to the time to reproduce the same level of accuracy in our code.
Regarding code stability - it's technically in "beta" because it's very new so the danger of a crash is real. The idea is to keep the code in the AP_MissionPlanner stable and only update it after it's been tested. Also there's a discussion around getting a simulator working that would allow us to test the lastest code without actually putting it in the air.
Re throttle control - I really like having it under direct human control. As a minimum this prevents fly-aways. You can be 100% sure that no matter what happens, your heli will come down. A bit like the decision to use an external gyro...moving the throttle code into the APM is very possible but not sure it's worth it when ESCs with good governors can be found easily. I.e. let's focus on the stuff that's not readily available.
These are my responses to your second post above.
1)How will the ACM deal with the fact that, in order to hold position, it will have to be off-level?
So you're assuming that there are two separate controllers that don't know what the other is doing, one is trying to hold the heli level, the other is trying to make it lean to control the position..but that's not how it works. The control is nested. There's a low level controller that's responsible for holding the heli at a defined roll and pitch. That defined roll/pitch comes from a higher level controller. If you're in stabilise mode it comes from the human's radio inputs. If you're in autopilot, it's from that autopilot code controller. So the positoin hold is one of these autopilot controllers. The only fighting that can happen is when we merge two higher level controllers together...that's in the code too..so even when you're in position hold, the human can say "lean 20deg!" and the pos hold will say, "no! lean -10 degrees"...and the heli will end up leaning at 5 degrees.
Thanks again for the input and discussion points!
Ok, good stuff Randy, thanks for explaining all that.
#1, Ok, so what you're saying is, the I term of the higher level position hold code will settle in to a number that will be commanding a little roll angle from the low-level controller. This will happen automatically. Sounds like that would work. The only thing I can say is that being able to input a fixed variable... or rather I should say, an adjustable variable, will help stabilize the helicopter whenever it enters Pos-Hold, or moves to a new waypoint, because you don't have to wait for the I term to stabilize. It will always be there as soon as the high level PID loop is activated.
You mention about the PID building up while you're on the ground. Have you got it set up where the PID only enables once the helicopter is "armed"? Not sure what you'd use to signal to the ACM that the pilot is intending to actually take off... Can't be simply anytime the collective is above it's bottom signal, because then PID control would deactivate on an autogyro. Maybe a combination of collective and sonar height? Just something to signal to the controller that you're off the ground.
If I understand what you said, and the PID builds up when the heli is on the ground, it will behave similar to the Flymentor. If the heli launchpad is off-level, the heli will take off off-level, requiring the pilot to force it level with the sticks, until the integral term decays back to zero.
#2. I think it would be a great addition going forward. We know it's a very real phenomenon, and a greater rate of decent when we have ground movement would enhance manoeverability during fast forward flight.
#2a. Does the code understand that the lift is a vector (roughly) perpendicular to the X and Y axis of the machine? So, if the machine is inverted, and the pilot commands a "bailout", (release the sticks, or flick the pos-hold switch?) it won't go to full-power to try to stop the fall until it has rolled right-side up yet?
#3. Ok, sounds like you have essentially already done what I was suggesting. Almost exactly the same thing, just a different way of writing the code. The only issue I see is if the commanded speed (I assume it's a configurable variable?) is outside of the physical capability of the helicopter, you might still get Integral build-up as the machine falls behind? Have you considered what would happen to the code if say... say the heli is capable of 40mph airspeed, which might be the transit speed that you enter. What happens if the next target is upwind with a 30mph headwind? The machine can't achieve it in that direction, so what does the code do?
Sounds like it would be helpful to put a heli on a turn-table to sort out the tail control.
Throttle control: Understood.
I supposed I should have a look at the program myself and see if I can understand it. I've done "Basic" programming language ~20 years ago, and have had some experience writing code programs in an industrial controller, so I understand the general structures of code, but obviously syntaxes are always different. Currently most of what I do is "ladder logic" in PLCs or block functions in motor controllers. They're sort of simplified ways of programming that are easier for industrial electricians to understand.
Currently I'm in a somewhat unusual position of understand controls pretty well, but not your software at all.
You're right about #1 except that the user's controls get mixed in with the autopilot's anyway, so if the user sets trim of say 4 degrees, that "4" will get added to whatever the autopilot sends the lower-level attitude controller.
Re the PID I term build-up. It would be good to only enable it when we're off the ground but that's currently hard to determine! The sonar cannot sense less than 20cm so it's hard to be sure if you're landed or just low. The barometer has a bit of a "random-walk" behaviour so can trust it even less.
#2a - not exactly. It's quite straight forward to make it work like that...or to even make it apply negative collective when you're up-side-down. The code is 90% the same as the quad so it only has "throttle boost"..which means it will crank up the collective as you lean over. But it won't get too big and it will never be negative. By the way - the code won't let you become inverted at the moment..it'll let you lean over a maximum of 45 degrees. That's a bit of an arbitrary limit to keep things safe.
#3 - i haven't thought about what it would do...but first we better get the PIDs right for loitering! (Actually Malcolm's done it but I haven't got my set correctly yet).
The code definitely takes a while to get your head around. There is more to getting it working than just coding though. Malcolm for example has brought us forward by leaps and bounds over the past 1~2 months primarily through testing and tuning.
The code as it stands is more than capable of holding a heli in a 3 meter box, the 600 size is probably easier to GPS hold due to the size of the rotor disc and the weight of the heli. You just have to spend time tuning it. You can do a whole lot of bench testing (which is not a bad thing to do) but actually getting to the field and flying the code is worth so much more.
The way i have been testing the code is to have a goal for each flight. I try to tune one mode and find how it flies and how the pid loops control that part of the code.
So far i have had really good results with stabilise. That part as far as i'm concerned has been sorted out.
Altitude hold works well to although i have yet to try the latest code.
Loiter mode seems to be a little wayward, sometimes it feels really locked it. other times it wanders. But yet again i haven't tried the code 2.0.43, the quads have been recording some really good results with this. So i'm hopeful i should too.
RTL worked really well, flew straight to the home way point. wish i had filmed that.
My next flight will be another GPS hold/Loiter test. I have a new sensor to try. but first i'll tune the airframe for the new code.
At first it all seems a little daunting but once you have a feel for the code, Loops and setting up procedure then it becomes a whole lot easier. Its worth trying the code as it stands, If you then feel then you need to change it then do so.
Your input already has Randy thinking and thats a good thing :)
I am building a new HK450 as listed on the wiki for my ACM project and have one short question.... which servos (or what type) do you use?
I just bought an align 3g unit to test the mechanical setup before mounting the ACM. The align unit needs digital servos as align ds-410/ds420.
The wiki link to the trex450 which lists ds-410/ds-420 as servos. Can anyone confirm that these servos does work with the ACM please?
Hi Arild i haven't tested them but if they are digital then they should be fine. Its only analog servos that are causing issues.
Great idea :) its well worth getting a 3g unit and testing the helicopter before fitting the ACM.
I use those servos on my trex450 and they're a-ok.
If you're building an hk450, I'd very much like your input on the parts listing wiki page. I.e. whats missing, what else should people get? For example I've heard that the screws that come with the hk450 are very soft and it would be worth buying the stock align screws.
I'm going to give 2.0.45 a flight to day and see how i get on will report later.
Yes I can confirm that something is soft in the hk450, but I do not know if it is the cnc parts or the screws that are soft. I disassembled everything preassembled and used medium threadlocker on every screw. Also I am not sure about the swashplate. It seems very sloppy, but I have seen the hk450 in hover impressingly stable (with flybar and only tail gyro) so it seems not that critical when flying "really traditional" heli :-)
I have also the cheap hk fbl head linked to at the part listing wiki page. Interestingly the manual for downloading at the hk site seems to be the manual created by rjx.... so I am not sure where the two plastic washers are to be placed. Otherwise I have managed to assemble the unit - I think :-)
The winter is coming very soon here in Norway, so I am not on the cheap route anymore... The DS410M/DS420 servos are ordered. Hope I can mount them on Tuesday.
As ESC I have CC Phoenix Ice 50A and after reading your problems with brownouts I also have mounted the CC Bec Pro as listed on the part list page on the wiki. Just to eliminate possible problems...
As frame mounting plates I have used 3mm "plexiglass" (Sorry I do not know the English word for this very hard plastic/composite). This weights more than cf, but are very easy to work with.
If it is important that the servos are digital, I think this would be nice to point that more clear on the part list page on the wiki. I have burned a hitec hs50 servo and have other servos that also are very jittering. However I have also found the cheap Esky servos for the BeltCP not to be jittering on the ACM... but it did not fly well.... but which BeltCP has....
Following the link for the hxt900 servos I did not understand if those are digital or analog... but according to http://www.servodatabase.com/servo/hextronik/hxt900 they are analog...
Will update when I have flown the bird on the align 3g system. By the way - those systems are very cheap second hand (at least here in Norway). I got mine for usd 68 - including the usb dongle.
Will report back when I'm in the air.
Hoping to hear great news. How did you get the 2.0.45. I read that only the 2.0.44 is available thru the mission planner?
i loaded up via arduino :)