I had a full afternoon of test flights this weekend, with mostly encouraging results. I flew ArduPilots (with uBlox) on the EasyStar (rudder and elevator), EasyGlider (ailerons and elevator) and SuperStar (a high-wing trainer with ailerons and elevator). The good news is that the default easystar.h config file will fly both the EasyStar and SuperStar pretty much out of the box. Navigation isn't as tight as it would be after you tune the settings, but it works.
I also flew a GWS Formosa with AttoPilot. Stabilization worked fine, but the plane kept descending in automode, requiring a manual takeover before it hit the ground, so I've got a message into Dean to see what's wrong.
With ArduPilot one weird issue showed up. With the EasyStar, altitude hold didn't work. The plane kept rising and rising, requiring me to eventually switch into manual. But altitude worked great with the EasyGlider and SuperStar, with an identical setup and code. Odd. We're trying to diagnose this, but one thing that may be meaningful is that altitude readings aren't showing up in the Ground Station software (it just shows 0, regardless of the vertical position of the plane). Maybe a bum uBlox module? Some strange code bug? Not sure....
I don't see any effected while flying my EZ* either in cloudy or clear day now. I have enlarge my rudder. Change radius limit to 80m, get best flight results until now with v2.3.1 code. But with v2.4 I get FULL throttle all the time. Maybe have some bugs with airspeed sensor code.
I have an out-of-the-box easystar (no ailerons or rudder modification) which has flown well on RTL and waypoints in clear sunny weather however it required fairly large changes to the h file settings to work. For example roll gains had to be increased (#define roll_P 1.0) otherwise no appreciable roll stability and heading gains had to be reduced (#define head_P .3), any higher would cause a spiral dive. Also flight results have not always been consistent and there seems to be less or no roll stability in cloudy conditions. Any thoughts on whether environmental factors such as flying in a wooded valley vs open country or cloudy vs clear day can have this much impact?
uBlox from DIYdrones store are programmed to only lock in 3D mode (no 2D)... So if you seee the nice blue LED is because you have enough sats for 3D mode. If i bind several times my easystar the altitude problem disappears, but then for no reason (in another day) the problem comes backs, weird..
I did a test flight with the 2.4 code today, this time the altitude was showing correct on the ground station software:-) Altitude hold, WP, and RTL all work fine
Here is the header file I use. easystar.h
Can the ublox give you a valid lock with only 3 satellites? Some GPS units can be configured to give a "2D lock", assuming the WGS-84 geoid altitude as the fourth sphere. That could explain the behavior, and why it might not repeat.
I've got some more diagnostics to do. On the Superstar, with the exact same Autopilot hardware and code, the altitude shows up fine in the ground station. But not with the EasyStar. I tried changing all sorts of settings in the altitude and pitch PIDs configurations, but it made no difference. The throttle stays at one setting (possibly the max) and the plane keeps climbing. Meanwhile, the EasyGlider and SuperStar with the same hardware (actually the EasyGlider doesn't have a pitot tube, but they're otherwise the same) handle altitude fine.
I'm working with Jordi on this. We'll figure it out....
I did have the same issues, was your airspeed ok? if the ardupilot thinks the airspeed is to low it will set full throttle and will rise, my Easystar holds altitude ok now.
I also have the isseu that the groundstation is not showing altitude, I think it's in the code of the ardupilot because the plane is holding altitude so it gets altitude from the gps but in the xbee data the altitude is 0.
Comments
Here is the header file I use. easystar.h
I'm working with Jordi on this. We'll figure it out....
I also have the isseu that the groundstation is not showing altitude, I think it's in the code of the ardupilot because the plane is holding altitude so it gets altitude from the gps but in the xbee data the altitude is 0.