These are the bugs found:
--When ArduPilot is pulsing the servos after it's got GPS lock with the bind plug on, it will pulse the motor, too, on some ESCs. This can be dangerous! (FIXED)
--One some ESCs, ArduPilot will not allow the ESC to arm, even in manual mode. This was a weird one, since in manual mode the servo signal is directly passed through to the ESC without touching code, but it appears that we were mixing in some signal from the microprocessor by mistake. (FIXED)
--Stabilization gains were too high for those using the Z sensor. Porpoising and corkscrewing resulted. (FIXED)
--On some uBlox configurations, the GPS parser would fail to read position data in AUTO mode, leading to flyaway behavior. (FIXED)
--Problem reading PWM data from the newer, smaller Futaba 2.4 Ghz digital receivers, like this one. Weirdly, channel one would only read motion to the left, not the right. This is a timing thing, having to do with the order in which pulses are sent in these newer receivers. (Jason now has one of these, and will use logic analyzer to diagnose and fix this one)
--The default loiter/RTL radius of 30m is too small, leading to figure eights, rather than circles. [Expanded to 100m.]
Finally, one bit of very good news: We've finally got rid of the bind plug setup procedure for people with Z sensors. The reason we had to do it before is that the Arduino bootloader overwrites the Atmega registry setting that says whether the last reset was a cold or warm restart. As a result, we couldn't tell if you were starting the autopilot on the ground (cold restart) or whether it had just reset in the air (warm restart). Obviously, we don't want it to record a new "home" position in the air.
Doug Wiebel, Jordi Munoz and Jason Short talked about this and solved the problem with a little AI. Now ArduPilot will measure the GPS data for a few seconds to decide if it's on the ground or in the air. If it's moving, it won't record a new home position; if it's stationary it will. Bye bye bind plug!
Jason will be uploading some of these bug fixes in the next day (when he gets off a plane), and the tougher ones, like the problem with new Futaba digital receivers, in a couple weeks when he's back from a business trip and vacation. The bind plug process should be gone then, too. By then I should have the ArduPilot 2.5 documentation done, and we can formally launch this thing as an easy(ier) to use, more stable and better performing autopilot that works on a wide range of hardware configurations!
Comments
On anything IMU I'll defer to Jose and Doug. Thanks for looking into the code!
Jason
Thanks for doing that. The first one looks like the 7C that I have - the pulses are in sequence.
Are the other sets different Futaba receivers or just examples of other styles?
Jason
For some reason Chris's ublox was configured slightly differently which caused some telemetry issues. Tht was an easy fix once I tracked down the cause.
Chris also had a fasst 6 channel radio which seems to have a different PWM scheme than the 7 channel fasst. That was unexpected.
I also found that the xyz sensors from jordi output differently than fma sensors. It may be a voltage thing as the resistors are different on each. I will set up a rig and calibrate the differences so we can save them to the config file.
I am concentrating on 2.5.1 and many of the new revisions apply. Doug & Jose you really have made ArduIMU system work well in mixing mode, I will try to test fly today, but I may not get to it, My brother and son in law's birthday is today! I am also getting my mom's estate in order..
Great work! Nice realtime debugging effort! Looking forward to the latest code as I have both my EZ* and Twin Star II models ready to go.
Regards,
TCIII