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.
Replies
Getting close to actually buying one so I can join the fun. Not sure what to do with the old Flymentor...
I tried "simple" mode for the first time today. For those who aren't aware, simple mode is a mode in which heli's yaw is used to translate the roll/pitch commands so they're relative to the pilot's point of view. Hard to explain but basically pitching forward makes the heli go away from you no matter which way it's actually facing. Pushin the roll control right means the heli will cuts across in front of you from left to right.
Before flying in simple mode it's important to 'arm' the motors. Throttle all the way down, yaw fully right for 2 seconds. This reset the barometer and also locks in the direction required for Simple mode. Also note that the heli needs to stay basically in front of you for the controls to remain natural. Also try the control while the heli is on the ground facing in various directions to ensure it's working ok.
You can set-up simple mode in combination with any other mode..in the CLI, setup, modes menu you'll see it appears off on the right..I think pushing the yaw left switches it on/off for the mode.
Sorry all will be away until Saturday 01/10/11 so will not be able to post any updates.
Does anybody know, are there any plans, or any hope, that the Arducopter will be able to do an auto-autogyro? If you're flying outside of visual range, or not paying enough attention, and lose power... Just wonder if the program will ever get to that point?
Also, what about failsafe? Is that built in yet? Will it RTL if radio signal is lost?
I'm going to give 2.0.45 a flight to day and see how i get on will report later.
Hi all!
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?
Best Regards,
Arild
Hi guys, new around here. Just as a quick introduction, I've been into RC a long time, pretty decent airplane pilot, raced cars for a while, got into helicopters just last year after dreaming about it for 20 years. The price of the Hobby King stuff finally made me take the leap.
I'm not sure if this is the best place to put this, but it seems like the active thread.
I've got an HK600GT, and I was using Flymentor with it. Had mixed results with that. I crashed the heli pretty good due largely (I think) to a flaw in the way that system works. Basically it's just a 3 axis gyroscope operating in something like a heading hold mode. The flaw is, that the "level" state slowly decays as you fly off-level. If you boot it up at 45°, it thinks that is level, and will try to return the helicopter to that level. If you boot it up level, it takes off and hovers fine, and stabilizes really well. But, if you fly forward for a long time, it begins to think the pitch forward is now level. So if you stop flying forward, and release the sticks, it pitches forward again to where it thinks level is... In my case, I flew to the fringe of visual range, and was trying to come back to myself. I flew backwards for a bit, got into some altitude trouble, released the sticks so that it would return to level, but it did not. This phenomenon was not known because not many people fly their helis a long distance such that the FM resets it's level. Anyway, I went in tail first at full power.
Anyway, I'm interesting in trying the AC because I'd like a more advanced system. I'm a mechanical engineer specializing in industrial machine controls, so this stuff is right up my alley.
I've read all the way through this thread and had a few somewhat random comments:
1)Drift due to tail rotor thrust. It was mentioned that compensation for this might be worked in the future. Just as a point of note, the FM system had compensation for this. On setup, you specified whether the main rotor was LH or RH rotation, as this would effect which way it would get pushed by the tail rotor. It also had a setting to guess at how much static tilt you would get from the main rotor.
2)One thing I thought of by myself, is a concern over decending while in Alt-Hold mode, or descenting to a waypoint. Is there anything in the program to slow the descent rate of the heli when the groundspeed is zero? As you may or may not know, when you are not moving forward or back, and you descend quickly, the heli starts falling into it's own wash, and can fall quickly out of control. Not a huge problem for a lightweight machine, but it will be when people start loading them up with AP gear. If there isn't already, there should probably be provision for a slower descent rate when ground speed is zero. Ascent rate can be as high as you want. This type of situation might cause problems with loitering, causing a bouncing due to the need for extra power to stop the fall, then overshooting at the top.
3)As a general comment on PID programming, I do this with industrial machines. One thing that I have found is some of the machines we use which have PID control, but which require large excursions for a change in position, then return to PID control used to give us problems. If you tuned the PID to be responsive enough at steady state, then tell it to step-function move to a new position, the integral term would build up as the machine traverses to the new location, then it overshoots the new location until the integral term can decay enough to allow the machine to return to the new location. Sometimes the machine would crash due to the overshoot. For a while we dumbed down the PID curve, but then it would never be responsive enough for steady state position hold.
The solution was a new way of traversing from one "waypoint" to another. Instead of saying "now go to the new waypoint under PID control", I basically programmed in a path. It tells it, from where you are now, your setpoint (or waypoint) is now moving towards the desired location at a given speed. As long as that speed of movement was within the capability of the machine, the PID never falls behind, never picks up a large integral term, and when the waypoint stops moving at the new location, the machine overshoots very little.
This type of programming probably isn't necessary on an airplane, as they always have to be moving forward, you never expect them to stop on a dime at a waypoint. But a heli can stop at a waypoint, and sometimes you might want it to. This type of programming would allow it to do so, and be more responsive on a position hold.
I think you guys might be trying to work around this by putting in an Integral Max variable. But you're still going to overshoot no matter what (not only because of momentum) but because even with a Imax, you are going to have to decay that buildup on the farside of the waypoint. Another easy way around this problem is to recognize that you are "traversing" to a distant waypoint, and simply nulify the Integral term until you get inside some window.
Anyway, that's enough rambling from me for now.
Oh, a couple questions:
Is it mandatory to have a stand-alone gyro on the tail? Seems like that's what people are doing, but I'm not sure why, and is that the permanent intent?
I've seen a number of incidences of crashes that seem due to people uploading the latest revision, and having unexpected changes. Are there release notes? I'm a little wary of jumping on this wagon if my heli is going to crash because some change I didn't know about or expect occured on a revision.
It seems like the throttle control is not under control of the AC. Why not? My speed controller doesn't have a good governor, so it seems like this would be a problem for me?
I was telling you all earlier about the problems I had with drift (the heli would gradually roll or pitch more and more and would require more stick input just to keep it level). I haven't had a chance to fly it again or try the hardware filter jumpers as previously suggested since I have been on vacation. I have however looked into the logs in more detail. It appears that the accelerometers are the cause and I suspect vibration. See the attached log. It shows the z axis accel (in blue) go from the correct value of 9.8 to an average of ~5 after takeoff. I was only flying in a steady hover so I wouldn't expect this value to change much. The other accelerometer values also shift slightly as well. Therefore I am pretty sure that the source of my issues are erroneous accelerometer values due to helicopter vibrations that cause the gyro drift correction to incorrectly compensate. I checked the gyro values and they seem to be reasonable.
When I get back I will try enabling the hardware filters for the accelerometers and/or eliminate any sources of vibration. Just wanted to share this with anyone who might also be having a drift issue in case it might help. If you have a problem please post you log files or an example plot so we can compare the behaviour we are observing.
@Randy, my ACM does not seem to be logging CTUN, any ideas?
@Malcolm, We have a question. we set the gyro gain to 1836 but the output from the apm is only 1470. Could this be the cause of the twitching?