ArduPilot EU Dev Call 2025-12-03

Attendees (unique): 8

UTC0700

Andrew: How long does it take to run?
Peter: About a minute, in parallel.

  • Will integrate will CI once it’s merged it in.

UTC0715

Randy: For some reason EKF failsafe triggers when DCM becomes the active AHRS and triggers HOLD mode.

  • When EKF is configured to use GPS but can’t do it at the moment, it switches to DCM.
  • But when the GPS glitches, the EKF will switch to DCM too eagerly.
  • Rover can’t handle the switch well, so we just set it to HOLD. It is disruptive.

P: We should provide the innovations to save us the HOLD.
A: It’s not straightforward to extract the innovations from the Rover EKF.

Merged!


UTC0720

P: Needs an autotest.
R: I’m going to test this one.
A: Especially what happens when you can’t look up the terrain.


UTC0730

Needs testing from another party.


UTC0733

A: It’s probably not worth using the bitfields.

  • Let’s change the original rangefinder_state bitfields to be their own bytes.
  • Also pick better names if they can fit.

UTC0739

A: What is required from the standard here?
R: Probably it’s meant to host an arrow that points to where we are sampling right now.
P: Bill Boney was trying to draw something, but lacked the information.

  • If we use different messages, then the mismatch in timestamps will cause latency and problems.

R: Let’s just fill it in with the compass vetor.
P: Nah, let’s not.
R: It’s fine, I’ll take this over.


UTC0752

A: The chance of getting a FS when looking for the timesync is much higher. We need to warn people of this.

  • Let’s test on your Bixler perhaps, Peter?

UTC0803


4.7 release

R: We’re waiting for Leonard’s PRs.

  • We don’t have a lot of selling features for 4.7.

Andy: Fast rates.
P: Arc waypoints.
R: Help Leonard along and get the beta out.
P: Why rush if there are no big advertising features?
R: Yeah, I see your point.


Andy: I’m getting very slow frame rates when I’m compiling with Cygwin, around 30Hz.
A: Let me try it out.

  • I’m getting around 700FPS.

Andy: I was running with sim_vehicle, does this not work?
A: Oh, that might not be working correctly, it’s adviseable to copy the built binary and invoke it with Mission Planner.

  • In essence you only need to open the socket to the SITL 5760, to get it running. MAVProxy, telnet, netcat or even a browser would do.

Andy: It’s sim_vehicle that causes the slowness. Weird…
A: Weird indeed.

1 Like

Can I help? I want to do real tests posing attention only of the flare

You’re welcome to test the code in the Pull Request, of course!

However that means you’ll be flying on our master branch, meaning non-officially released code.
Is that OK with you?

Yes, I saw your solution on github and hypothetically, even if I don’t understand the code, your simulator seems to be fine. Unfortunately, I’m not able, after some try, at using the software in the loop and I can’t wait to try the new solution, since I’ve been performing landings with poorly designed flares for three years, and while waiting for the official firmware, I’ve realized that not many provide real-world experiences, and it’s still a bit sketchy. Unfortunately, I’m not good at IT. I can use Mission Planner, update, install previous or custom FW, but I have no idea how to compile code, etc. IT has always been a stumbling block for me. If the FW is already compiled for the original mRobotics 3DR Pixracer PRO, I can install it. If only the TECS library changes, there shouldn’t be any other problems. In any case, I’ve done a lot of testing and can save the plane by hand. In any case is a simple frame for testings, there’s no problem. If you can help me on how to install it, I’ll proceed as soon as possible. Excuse me for bad English, I use translators and after I check the meaning to make me understandt as possible. Thank you very much.

You can find a compiled version of the Pull Request here.
You can flash it with Mission Planner → Setup → Install Firmware → Load Custom Firmware.

If you install it successfully, at the time of the boot, you should get a message saying that the firmware hash is 12c7c8e2dfe0.

Keep in mind: This is not a version where the flare change is placed on top of the 4.6 release. It;s a version where the flare change is placed on top of the current “dev” version, also know as “master”. So there will be more changes, fixes and new features, apart from the flare fix.
I’m mentioning in case this is important to you.

Thank you for offering to test, in any case!

So: It started raining and I was able to do a few tests.
Don’t pay attention to the precise touchdown, as I need to change the parameters a bit based on the different behavior. If it stops raining, I’ll fix it a bit better. I didn’t have time to take a video.
It seems perfect to me, the behavior is very different, it’s very fluid with LiDAR acquisition and in every approach phase. I can’t believe it, after more than three years of trying to set the parameters in vain. I haven’t changed any of the parameters, just two questions:

1 - in the image, while the file “arduplane_pr_tecs_flare_sink_init_12c7c8e2dfe0” mentions the number you mentioned, it doesn’t appear anywhere; this different number appears 115025f0. So, is this the hash I should have tried?

2 - Then with this firmware, it seems to me that the EK3 OPTION parameter, which if I’m not mistaken was set to 1 by default, “fuse all velocities,” has now reverted to 0. What’s the best way to set it? It’s very important to me because in 2021 or 2022, I don’t remember, I blocked the pitot in flight due to rain and the flight control decided to dive as a safety measure, and at full throttle (a similar problem still exists in FBWB if the aircraft banks above 45°, but it’s clearly intentional). So with the new flight control units from the following years, from EKF2 to EKF3, a lane switch occurs and often the aircraft only has a lower estimated airspeed accuracy but doesn’t dive. It’s not necessary to save it, I usually switch to FBWA.

I haven’t looked at the log. If it stops raining, I’ll adjust the flares properly, but I think it’s going to rain in the next few days. The only problem with rain is pitot failure quite sure because different times I had this, and my fear is the lane switch that I don’t know, also if sometimes I had lane switch bacause of pitot closed due to rain or GNSS jamming. Anyway I noted the well behaviour of also the old EKF2 since about in the 2020 I hadn’t the pitot and after firts experiences I loved to use the TECS_SYNAIRSPEED

I only managed to do three other landings; I forgot, I saw the launch direction for autolandings, but I haven’t had a chance to try it since we have a strip with often crosswinds, and autolandings aren’t ideal here, probably better the classic waypoints, I don’t know when I’ll have a chance to try it. I’ve adjusted the parameters a bit better, but there’s still room for improvement, and I only managed to take the video of the second landing, as I first had to try with the radio in hand. Then, seeing that it worked, I put the radio down and the camera in hand and I done video, and then it started raining again. If I may, look at initial video pitch abrupt correction, when after the flare seems perfect in terms of logic. I don’t understand anything about the data you’re able to analyze, but it seems like a very gentle flare and I can improve with parameters, but the correction initially in video of the approach is not so gentle. Correspond to this in the log:

I’ll resume work on other aircraft later, but on the second approach, where the difference between the baro altitude in that launch and probably the GNSS or LiDAR altitude is greatest, the steps are a bit terrifying in reality. For now, as mom teaches, thank you very much and let’s be satisfied. Congratulations, I really do! It takes me almost two hours to get to the camp and I risked to do noting today because of the rain, and is raining also next days, and I’ve been trying to do flare for years in vain…

https://www.dropbox.com/scl/fi/d55ohvsryq8ae5dblla40/IMG_1330.MOV?rlkey=0bbfo89drc6dsbpf2dysheqf5&st=g80dfkzm&dl=0

EDIT: the flare problem is not very very solved, in one of the six flares, I open the log and, also if during a moment, there is a pitch down command like in 4.6.3, see

Unfortunately I gave you the wrong build, it was meant for another feature. I apologize.

This should be the correct link.

Again, please check the correct hash number before you take off. It should be 12c7c8e2 if I did things correctly.

Very good, don’t worry. Initially, I had the impression that everything was working perfectly, then I noticed the pitch down again. It was nice to try this one, though, even though I don’t know if it’s a master branch or something else. I don’t really understand much about it, and it’s nice to hope that with the new solutions, it can improve further. Thank you so much for your reply, because to be honest, I was quite heartbroken after the last landings with the same problem and problems in approach. In this case, however, it was an opportunity to see some changes. Thanks.

EDIT: is raining and night now, as soon as I can try with curiosity and a little trepidation, in the meantime I installed and compared the said number

excuse me, EK3_SRC_OPTIONS six landings with zero, then I put 1 “fuseallvellocities”, update with12c7c8e2 and remained 1, I don’t know why from 4.6.3 passed from 1 to 0; witch is better now for the tests, and why if you can explain me? thank

1 Like

I’d say keep whatever value you had in your 4.6 flights.

dear George, last firmware you suggest to me, four flare in any condition perfect, no more pitch down

flare solved

P.S. usefull fllght count in 4.7, not noted in 4.6

1 Like

Excellent! Thank you very much for testing!