I built my own quad from scratch using an alu frame and decided to control it using the ardupilot mega that I have lying around. I loaded the arducopter NG2 code on this and took it for a couple of flights, noting its behavior and how it felt like controlling it. My intentions are to make this a platform that is really easy to control from first person video too, as well as 3rd person "in the field" of course.
Although the AC code is already more than suitable for video flying, I conspired with my colleagues. They gave me some tips and the result is the most boring quadcopter ever :)
The video above shows some progress in that direction.
To describe the changes: I prepended a 'velocity' controller before the orientation controller that was already there. The arducopter measures the angles of orientation and continuously updates motor speeds to ensure it maintains some desired angle, set by the sticks. So in this case, I don't control the angles directly, but I control the velocity projected onto the xy plane that I want this quad to have. Altitude is still managed manually.
The GPS controller in turn is now attached to the velocity controller. So any offset in the position results in some desired velocity towards the waypoint. The quad starts to accelerate by outputting some angle, maintains the velocity towards the waypoint and as it approaches, starts slowing down such that when position == waypoint, speed == 0 too. Using angular control only this is much more difficult, because you have to play around with aggressive D-gain settings to get the quad to stop closer to the waypoint.
The quality of your experience using the velocity controller is dependent on the quality of the GPS (doppler effect speed readings?), the quality of the GPS signal that you are receiving, the quality of a magnetic compass, the frequency of the GPS output (5Hz is a bit low) and of course as usual the PID settings. So quite a number of factors there.
I use a switch on the tx to control the mode I want to fly in, or switch back when it behaves erratically, indicating some possible problem with GPS reception or compass readings.
Comments
I've submitted to the arducopter project in this issue:
http://code.google.com/p/arducopter/issues/detail?id=201
Be sure to take into account the observations.
Can I get your current code? I'd love to compare with existing code.
I'm relying on the output of the ground speed+course of the GPS at the moment. I'm only interested in the velocity in the xy plane, since altitude is managed by different means. I did another test today with some adjusted PID settings, Bf. 2. With attitude control only, the quad drifts slowly in the wind. With the velocity control on, it basically stays in the same position, so very little additional GPS Hold control is needed. That's why my current implementation uses a tuned down GPS Hold P-controller, chained to a relatively nice velocity PI-controller, chained to the attitude PID controller.
I did notice an issue today. 3 out of 6 times, the quad started a circling motion growing ever more aggressive and larger. This could indicate some problem like 20/45 degree offset in the compensation it is achieving. More likely is that (at least) the course output from the GPS is somewhat lagging behind the real values.
I don't know if all GPS receivers today use doppler shift to calculate course and speed. I'm using the MTK3318 chipset. There's no explicit mention in datasheets there. My guess is that the cheaper modules do not use it, whereas the more expensive ones do.
Some people also report problems or inaccuracies starting to appear @5Hz update rates versus 1-4 Hz. I should probably attempt 4Hz as well at some point and see if things get better. The 5Hz update rate is a bit slow for such important control, so the controller cannot be set too aggressive. Getting a 10Hz GPS with doppler shift speed readings than becomes less of a luxury.
If anyone has any good tips and datasheets to good GPS's, I'm all ears!