it still flies the LOITER, but you use the stick mixing functionality (ie. with STICK_MIXING=1) to allow you to do temporary overrides of the control. So just move the roll stick right/left, and when you let go it continues to loiter. Same with pitch. It is best done when you have a clear view of the plane to make sure you don’t override the path so much it goes somewhere where you don’t want it to go.
1 Like
Does this result in EKF2 available on 1MB F405 boards?
Or will it fall back to DCM only?
I have a few well behaving planes with different versions of AP3.9 and AP4.0.x on omnibusf4pro and MatekF405Wing. I should give this build option a try.
After a few tests:
To answer my own question:
No, it will not make the EKF2 available on the omnibusf4pro. It falls back to DCM only. For me it’s too 2013 when we flew 8-bit APM’s.
Thanks a lot for your work an the new AP version! I had a few problems with EKF2 before and I hope they will be solved with EKF3 now.
One thing I see is that since AP4.1 the parachute function does not work anymore. I used it with AP4.0.9 before and when I update to any more recent version, parachute gets released when I switch my radio on.
I don’t quite understand this,could you provide more detail about this ，I am not a developer，I just a user，i don’t know the code
you can build for EKF2. You also then need to set AHRS_EKF_TYPE=2.
The easiest way to build is using the custom build server at https://custom.ardupilot.org
You’ve probably just broke my dream that I’m using EKF2 
I need to check it once more. BTW, I’ve set AHRS_EKF_TYPE=2 as tridge wrote, but I’m not sure if it’s used yet.
How to make the code to APJ file after custom build?
Have you just tried to walk around with the plane a few meters? The Bad AHRS message comes rather only if the FC has no direction information yet. Move the aircraft a bit and the message should be gone. Anyway no reason to switch back to EKF2 …
1 Like
Click “go to build directory” and download
How long do these files remain in the build directory?
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.