The plane was flying well all the time. Just the Bad AHRS messages in Yaapu telemetry were annoying.
Anyway, most probably the plane was flying with DCM only, because the EFK3 was already switched off. I’m not sure, I would have to try to simulate it once again.
I use the OmnibusF4PRO and GPS with no compass with 4.10 DEV to 4.11 and I have not experienced the Bad AHRS issues even under windy conditions and zero ground speed.
Hi @tridge,
Thanks, I am aware of the custom build server. Here I will get a AP_4.20dev version not the AP4.1.2 stable one. Most of the time I am not brave enough to fly with the latest dev-version.
Maybe it would be a nice feature for the custom build server to be able to build the latest stable version next to the latest DEV.
Otherwise in my use case I like to be able to apply a few of my local changes.
1 Like
Hi @_sobi
I did not want to break any dreams. You can easily check the use of EKF2 in the log files.
The presence of a bunch of EK2* parameters is good indicator for the EKF2 too.
Nonetheless if the plane flies fine with DCM nothing to worry about…
This will be fixed in the 4.1.4 release. My apologies for not getting the fix into 4.1.3
No problem! Thank you for fixing!
Do you have an idea what happened here? Plane losing position and drifts away - EKF/GPS failure?
I hate to bombard a release thread with a potential user error, but I just cannot seem to figure out why my aircraft keeps resetting on the ground with a 0x800 Internal Error whenever I attempt to trigger my camera (via relay). This same setup has been working reliably for a long time, but this is a major headache. Seemingly randomly, I can do a fresh boot without this problem and my camera triggers normally. 95+% of boots though, as soon as I attempt to trigger, it appears that the entire autopilot reboots with an internal error. I know the cabling is good as a few boots it acts as it should.
HW: mRo Pixracer Pro. Relay Pin Channel 7, Feedback Channel 8. Servos Channel 1-4 and Dshot out on 5-6. Parameter list and log attached.
4.1.3_PixracerPro_CameraTriggerCausingReset.param (17.7 KB)
00000082.BIN (219 KB)
Have you got a catch diode across your relay coil?
I’ve tried to reproduce the issue on a mRoPixracer pro with no luck so far. Can you explain what you mean by “attempt to trigger my camera (via relay)”. A relay is an output to the camera, not an input trigger, so I presume you are triggering with RC channel 6, which then fires the camera using servo output rail pin 7 as a relay?
Can you post a log showing the internal error? The 82.BIN log only last 2 seconds and doesn’t contain any internal errors.
Also, please try and reproduce on the bench with latest master firmware. If you can reproduce with master then we may be able to use the new hardfault diagnostic code to find the issue.
I’ve just released plane 4.1.4 stable. This is a minor release with some important bug fixes and small number of new features.
- fixed RC parachute release to only trigger on RC input channel above 1800, fixing an issue with trigger on power on
- added QRTL flight mode as an RCn_OPTION
- display VTOL position1 state change when landing approach and airbrake logic is disabled using Q_OPTIONS
- limit Q_VFWD integrator to be below TRIM_THROTTLE to prevent very high forward throttle building up in some landing approach conditions
- fixed an issue with high position1 landing approach target speed causing the nose to dip when going between VTOL approach and position1 states
- allow for a wider range of Q_A_THR_MIX values to be configured, to better support landing quadplanes in high wind
Happy flying!
6 Likes
I love this! With the sub-version numbering, Mission Planner/QGroundControl now know that there is categorically a new update and pops up a prompt when I connect to the plane.
Previously they would show multiple updates with the same version number, with nothing to distinguish them.
In this case I know I don’t need this update for what I’m doing. Thanks!
1 Like
Dears
Pitifully, I crashed my quadplane yesterday. I am very interested to discover the causes. The problem occurs in the last part of the landing process. I tried the new QRTL mode 3 (Q_RTL_MODE = 3), with the last firmware 4.1.4. As you know in the new method exists the “airbraking” phase in order to make a fix wing approach.
The plane reached to ALT_HOLD_RTL (65) in good shape, made the first “airbrake” to 80m from home and altitude to 34m ( v=18.1 d=80 sd=81 h=33.8), at this moment the forward motor begin to stop. The Q_RTL_ALT parameter was defined at 20m, but the plane maintain an altitude of 30m for a few seconds. The problem occurred when reaching the VTOL POS1 position (v=16.8 d=49.7 h=32.2 dc=14.0); The plane pitch down suddenly. As you see in the next graph the nose was down all the way (behavior channel C2 and C4, Vtail). In the same way, the quad motors were activated, the front ones (channel C5 and C7) push higher in order to do a final “airbraking”, I think. But the inertial was too high and the plane go strain to the ground. I tried to change to QHOVER mode in order to get out manually the situation but was not enough. The plane crash to the ground at 23m/s, the plane is destroyed.
Here is the time when reached the VTOLPOS1 position and pitch down the nose.
One last detail, when I made the mission I forget to change the command TAKEOFF to VTOL TAKEOFF and RETURN TO LAUNCH to VTOL LAND. The takeoff process was as VTOL, without issues, but the landing was a disaster.
Maybe can improve the Mission builder process, due to VTOL command only being enabled when the quadplane is connecting to MissionPlanner. So, if you work your mission in the office you cannot complete the takeoff and landing part.
Here are my BIN data, hopefully can review it and give me some clue about source of the problem.
can you upload the bin log so I can take a look? (I think you accidentally only uploaded the parameter file)
So sorry, I updated my message, now it is ready. thank
Hello Tridge, Thank you quick answer. I update my message, the BIN are ready now.
You can see what happened in this graph:
ArduPilot put full throttle on the front two motors, and dropped the rear two motors right down, yet the plane kept going nose down. At that point there is nothing more the autopilot can do, it already has maximum pitch up.
I’m pretty sure your front motors did not spin up on the landing. You can see that from the current draw, comparing the takeoff and the landing.
In the takeoff we can see this:
you can see that the current draw (red line) was around 65A when the 4 motors were at 80%. Now look at the landing:
we have 2 motors at 100% and the current draw is under 10A. That is impossible unless those motors have failed to start up.
All you could have done is to switch to FBWA and try to fly it out as a fixed wing, then try the landing again and hope the front motors spin up properly on the 2nd attempt. I know it is almost impossible to think of doing that quickly when something is going wrong.
One of the things we’re working on is to automate this for aircraft that have ESC telemetry so we know the RPM of the motors. We will have an option to automatically abort the landing and try again if one or more motors don’t spin up correctly.
What type of ESC were in the plane?
Hi Tridge
I realized that behavior but never thought that quad motors can fail. Never happened that in the past. But It is true that the current consumption is not expected. I am not sure if the Quadmotor started, all was so quick, but the propellers of the front motors were broken, So I thought that they were rotating. About my quadmotor system:
Motor: T-motor F80 pro KV1900
ESC: Cobra MR30-FPV
The aircraft weighs around 2.5kg.
Thank
Hi Tridge
I wonder if the parameter THR_SLEWRATE can affect the response in this state. I used the value 55 in order to reduce the power request from the battery. What do you think?
no, THR_SLEWRATE has no impact at all on VTOL motors.
you definitely had a hw failure of some sort. The PWM values logged as going to the ESCs should have had them spinning the front motors at nearly full throttle.
Ok…I will change the ESCs, and motors too. And test it, with another plane…thank you so much.