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.
Only F7 processors support inversion of serial ports:
http://ardupilot.org/plane/docs/parameters.html?highlight=serial1_opt#serial1-options-telem1-options
I read that as swapping the functionality of the TX & RX pins on F7 boards - - not inversion??
What does InvertRX, InvertTX do on F4 boards?