As mentioned on the 3.5.2 release discussion we have decided to do a 3.5.3 release to fix a couple of important bugs found by users in 3.5.2.
The main motivation for the release is a problem with flying without a compass enabled. If you fly 3.5.2 with MAG_ENABLE=0 or no compass attached then there is a risk that the EKF2 attitude estimator may become unstable before takeoff. This can cause the aircraft to crash.
The other changes in the 3.5.2 release are more minor:
- fixed loiter radius for counter-clockwise loiter
- fixed the loiter radius when doing a RTL at the end of a mission
- provide reasons to the GCS when a uBlox GPS fails to properly configure
- support a wider variety of NMEA GPS receivers
- use EKF1 by default if no compass is enabled
For those of you feeling a bit more adventurous you might like to try the 3.6.0beta1 release. There is still a fair bit more to do before 3.6.0 is out, but it already has a lot of new features and I have been flying it for a while now.
The biggest single change in 3.6.0beta1 is the update of PX4Firmware. This brings with it a lot of changes, including much better support for the Pixracer flight board.
There has also been a lot more work on QuadPlane support, which a new QRTL flight mode, plus support for using the forward motor in VTOL flight and active weathervaning support. If you are flying a QuadPlane you'll find the names of the copter rate control parameters have changed (just like they have in copter). You should be able to find the new parameters OK, but if not then please ask. I'll provide more detailed documentation with the final 3.6.0 release.
Detailed changes in 3.6.0beta1 include:
- merge upstream PX4Firmware changes
- new AC_AttitudeControl library from copter for quadplane
- modified default gains for quadplanes
- new velocity controller for initial quadplane landing
- smooth out final descent for VTOL landing
- changed default loop rate for quadplanes to 300Hz
- support up to 16 output channels (two via SBUS output only)
- fixed bug with landing flare for high values of LAND_FLARE_SEC
- improved crash detection logic
- added in-flight transmitter tuning
- fix handling of SET_HOME_POSITION
- added Q_VFWD_GAIN for forward motor in VTOL modes
- added Q_WVANE_GAIN for active weathervaning
- log the number of lost log messages
- Move position update to 50hz loop rather then the 10hz
- Suppress throttle when parachute release initiated, not after release.
- support Y6 frame class in quadplane
- log L1 xtrack error integrator and remove extra yaw logging
- limit roll before calculating load factor
- simplify landing flare logic
- smooth-out the end of takeoff pitch by reducing takeoff pitch min via TKOFF_PLIM_SEC
- added support for DO_VTOL_TRANSITION as a mission item
- fixed is_flying() for VTOL flight
- added Q_ENABLE=2 for starting AUTO in VTOL
- reload airspeed after VTOL landing
- lower default VTOL ANGLE_MAX to 30 degrees
- Change mode to RTL on end of mission rather then staying in auto
- implemented QRTL for quadplane RTL
- added Q_RTL_MODE parameter for QRTL after RTL approach
- reduced the rate of EKF and attitude logging to 25Hz
- added CHUTE_DELAY_MS parameter
- allow remapping of any input channel to any output channel
- numerous waf build improvements
- support fast timer capture for camera trigger feedback
- numerous improvements for Pixracer support
- added more general tiltrotor support to SITL
I flew both 3.5.3 and 3.6.0beta1 today and both are really flying nicely. I hope you all enjoy flying it as much as the dev team enjoy working on it!
Happy flying!
Comments
As 3.6 is out now, I take the opportunity to see if the new firmware solve my problem.
Before : Once I move my plane from out door to in door where GPS satellite drop to less then 5 or totally lost GPS, the artificial horizon become hey wire, as well as altitude.
After : I erase the old firmware by upload Rover then upload the 3.6. Now the artificial horizon only move, may be less then 15 degree either way. Never turn more than that. Much improved but I'm not sure if it is safe to fly.
I try with my MTD with CUAV Pixhack ( Aluminium case ), the HUD just display the correct info regardless full satellite or no satellite. So I can confirm that this may not have anything to do with the firmware but a hard ware issue. I'm using original Pixhawk. I recall sometime ago there was IMU issue with Pixhawk. May be mine just happen to that same batch.
Thanks Andrew for his help and very sorry for I may have wasted some of his valuable time. I'll remove the Pixhawk and consider case close.
Dear Andrew
Can I know if any update info available or should I continue to ground my plane until further notice ? Thanks
I agree 3.5.2 and 3.5.3 are very stable and robust. I don’t think that I will be upgrading any time soon. I have many missions on both and all have been perfect.
.
I wonder if that is a hardware issue. I flew 3.5.2 today with a HK Pilot 32 for hours without any issue. I also accidentally " test " the robustness of the navigation code. I set my compass orientation wrong, it was 270 Yaw but I set it as default. It still fly auto mission for about 30 minutes but I notice something wrong with the air speed reading ( no air speed sensor ) where it drop significantly in the up wind leg, I land it, found the problem, set correct compass yaw and it flew beautifully.
@Keeyen, thanks!! that log is exactly what we needed. Paul will now analyse it and work out a fix. I'll let you know once we've got a fix.
Hi Andrew
I set ARMING_REQUIRE = 1, Now it won't go haywire when I put it out door for GPS reception. However, when I take it back indoor and when it start losing GPS signal, it goes crazy again.
If I set ARMING_REQUIRE = 0, I can reproduce the previous problem consistently.
Attach herewith the DF logs.
https://drive.google.com/file/d/0BwRKGgIOJSELVDlhOTZJd0hpVGs/view?u...
https://drive.google.com/file/d/0BwRKGgIOJSELR0l2MW45M1NabEU/view?u...
@Keeyen,
Thanks for that!
It looks like the issue may be related to the arming state. I notice you have ARMING_REQUIRE=0 which means the plane starts up already armed. Can you try with ARMING_REQUIRE=1 ?
Cheers, Tridge
Hi Andrew
Here's the DF file. This time the problem only show once.
https://drive.google.com/file/d/0BwRKGgIOJSELenhPaGpLLVBtTjQ/view?u...
Thnaks
Hi Keeyan,
Paul, Peter and myself have worked on a new logging strategy which should enable DF logs to debug this type of issue. So we are now ready for you to try another test on your plane with the following firmware:
http://uav.tridgell.net/KeeyanPang/ArduPlane-v2.px4
Please also set the following parameters:
these parameters are a special case for this test. You will probably want to change them back before flying. You will need to reboot after setting those parameters.
We are not expecting that this firmware will have fixed the issue you have seen, but we are expecting the resulting DF logs will allow us to analyse what is going on. Then we should be in a position to fix it.
Thanks!
Hi Andrew
No problem. I'll keep it as it where is.
The last two test, air plane was placed on top of my vehicle's bonnet. So there was a big metal underneath. Today I place it on ground, it still show the same problem.
I notice that I can only reproduce this problem when I connect the battery indoor, then put it outside for GPS reception. Once it start detecting satellite, it'll goes haywire. It may not related but if I connect the battery when the plane was in open space, it seems fine, no pitch / roll crazy but somehow the altitude shown variant up to - 8 to + 4.
I attach a DF file which show this problem.
Another issue I notice is the magnetic field. When I connect battery from my office it show 750 + but once I put it outside, it turn to 500 + is this figure acceptable ?
https://drive.google.com/file/d/0BwRKGgIOJSELS29ITjRyOVo1eGc/view?u...
-
1
-
2
-
3
of 3 Next