It should be enabled on Pixhack if you load the Pixhawk1 firmware
it is very close. With the recent flash savings in master the kakutef7 does fit, but it doesn’t fit with plane 4.0.0.
For 4.1 I will try to re-enable full features for KakuteF7 and OmnibusF7V2
I have solved the problem, thank You.
I have a little problem with u-blox ZED-F9P (simpleRTK2Blite from Ardusimpel ) when trying to arm.
When trying to arm, the following error message comes up:
“GPS 1: u-blox solution rate configuration 0x1008
PreArm: GPS 1 failing configuration checks”
Otherwise, the GPS works perfectly including RTK injection through Missionplanner NTRIP client.
Does anyone know if it is due to the GPS configuration?
Here are the parameters: 00000007.BIN.param (19.9 KB)
MatekF405-Win
ArduPlane V4.0.0beta1 (3084a152)
I had a very successful Quadplane built and working on a dev build from about a month ago. Initially I had problems trying to autotune and then fine tune but a second attempt of autotune made a very stable VTOL flight and transition. Once I saw that beta 4.0 was out I decided to move to this and checked all the parameters for consistency and found all the features that mattered were there. The real difference was the SCHED_LOOP_RATE that went from something fairly low to 300. I didn’t think anything of it. Today I tried a flight and took off in QHOV. Everything initially seemed OK but I noticed something very odd as I tried to climb out. I did make a transition and everything in fixed wing worked the same and was good. Comeing back and transitioning back into QHOV I noticed that I had a bad oscillation. I was able to get it to calm down and as long as I kept the throttle up it was stable enough to land. I decided to try an autotune starting with roll first and this is where I lost the aircraft. I took off and it started to twitch roll but I needed to make a correction to keep things in the middle and for some reason it rolled in the initial direction but I could not correct to save it. I will post a link to both .bin logs to hopefully help find out what happened. Thanks again for your help.
The default for SCHED_LOOP_RATE in quadplanes has always been 300. For planes without Q_ENABLE=1 the default is 50Hz. The higher loop rate for quadplanes is needed for good stability.
Do you have logs of previous good flights for comparison?
Here is a link to a successful flight just before the move to 4.0beta.
https://1drv.ms/u/s!AnKjVxm8Uzokh-xa-IljL3h2U6CMHw?e=PQZchq
I remembered another change I made to the parameters when I upgraded. A few days before this successful flight I did another autotune and afterwards found that the controls were really sensitive. So following this thread Quadplane Hover Tests Done, Tuning Advice Needed Please and when I moved to 4.0 beta I lowered Q_A_ACCEL_P_MAX and Q_A_ACCEL_R_MAX a little which seemed to help earlier when I ran into the same problem. I’m not sure if changing this contributed to my problem that caused the crash or not.
Edit - I just realized that also yes both have 300 for SCHED_LOOP_RATE. Not sure whey I thought it was 50. Hopefully something in the logs from today will stick out to point me in the right direction. I do plan to rebuild…
I’ve just released plane 4.0.0beta3, with the following changes:
- added Pixhawk1-1M build (for Pixhawk1 with 1M flash bug)
- fixed a bug handling UART corruption for u-blox driver
- fixed a CAN ISR latency bug for STM32H7 boards
- fixed FMU channel mask to correctly obey SERVO_RATE
- fixed use of DMA on Pixracer WiFi UART
- reduced flash size and memory usage with EKF optimisation changes
- fixed a BLHeli bug when no motors enabled
- raise default LOG_FILE_BUFSIZE on boards with more memory
- fixed units of custom AHRS orientations
- fixed LOG_FILE_DSRMROT with delayed log stop on disarm
- fixed block flash logging
- fixed SLCAN bug on Pixhawk1 and fmuv2
- added check for airspeed and Z controller active for hover throttle learning
- enable hover learning by default in quadplanes
Happy flying!
4 Likes
Four missions using Plane 4.0 beta 2. Maiden for a new Bixler 2 with HolyBro Durandal. The aircraft flew well in manual and didn’t miss a beat in autotuned, FBWA and auto. It gave such confidence that I used it in FBWA for ab initio pilot training today on only it’s third mission.
Brilliant work as ever @Tridge and the Dev team! If the logs are of any use they are here:
Plane 4.0 beta 2 logs
Cheers
Jimmy
1 Like
@tridge Loading Plane 4.0 appears to break out mavproxy connection. Is this a known issue? Not sure where to start with debugging this, as returning to 3.9.11 repairs the problem. Attached screenshot of the error thrown by Mavproxy
1 Like
Tridge, is the In Flight Compass offset learning in the current version of Mission Planner. This feature is very useful to me as I fly in an area that has some compass interference around. How do I activate the feature? JEFF
I’ve just released 4.0.0beta4 with a small set of improvements over beta3:
- fixed time race in airspeed driver (thanks to liang)
- fixed uninitialised bytes in send_named_float()
- added TAKEOFF flight mode (thanks to testers!)
Happy flying!
1 Like
So with TAKEOFF mode does it follow all the parameters for Auto takeoff and then run to the TKOFF_ALT and TKOFF_DIST and Loiter? IOW the same functionality as an Auto Mission Takeoff and then Loiter Unlimited?
This would be nice to have as an RCx Option.
yes
It is only a flight mode so far, but we should add it as a RCn_OPTION too
Henry found a bug in the new TAKEOFF mode. It will takeoff to the TOFF_LVL_ALT and loiter there, rather than TOFF_ALT. I’ve fixed it in master and the 4.0 branch ready for next beta.
Is it possible to add other Q flight mode options for RCn_OPTION? Right now option 4 gives us RTL and this works great for Quadplane if the Q_RTL option is set but having QLand would also be great.
Another quick question - I am currently building a QuadPlane Tilt rotor that tilt the front 2 motors. In a Tilt setup does this free up the Servo 3 for throttle to be reassigned for other purposes?
yes, we should really have all flight modes available as RCn_OPTIONs
yes
I am trying to get passthrough telemetry (10) on my radio using the Frsky X8R receiver which has a smartport which provides an inverted signal.
In the past it was necessary to hack inside receivers or use a converter cable to provide a non-inverted signal.
I would like to know if the new SERIALn_OPTIONS parameter can perform this capability. I have tried it without success so far on Matek F405-Wing.