CI Review
Release Update
Issues & Pull requests
Attendee count (max): 20
UTC1101 - https://github.com/ArduPilot/ardupilot/actions/workflows/ci.yml
-
DeadReckoning is dying again
- We looked at it a bit on the call
-
Thomas has looked at the colcon stuff and thinks heās got 90% of the stuff
-
For whatever reason weāre in another ādisruptedā period
UTC1114 - release
-
4.6.3 is going fine
- Including Plane patch
-
Internal error flow of control in althold mode
- Land detector
-
āVery very very bad pitch in autolandings in autolandings in Planeā
-
Slightly less bad than 4.6.2?!
-
Tim has said something similar?
-
There were some pitch fixes surrounding rangefinders in 4.6.3
-
-
Discourse update has caused older browsers to stop working?!
- Old MacOSX browsers
-
S.Bus corruption?
- More likely just going to bind-time values
-
People are asking about 4.7 beta
- Holding off for another few weeks so Leonard and a few others can get some things in
UTC1130 - Add support for MAV_CMD_DO_SET_ROI_WPNEXT_OFFSET
-
Need to get the mavlink upstream
-
General agreement that this can go in
-
Need all of the backends to support the new enumeration entry value
-
We should split our internal enum from the mavlink one
UTC1137 - https://github.com/ArduPilot/ardupilot/pull/31377
-
Remove a prearm check for origin
-
Sensors only or complete solution are both options from AHRS
-
We can arm Copter in stabilize without an origin
-
So maybe we remove the check?
-
Really want to avoid having the null origin!
-
-
Tridge has left some testing instructions
UTC1144 - https://github.com/ArduPilot/ardupilot/pull/25814
-
Enhanced attitude control via scripting
-
Leonard queries changing function namesā¦
- Can be done in a variety of waysā¦.
-
Randy really doesnāt like the wrapper function for set_target_velocity_NED
-
Randy wants to test
-
Conflicts need to be resolved
-
[10:58 AM]Peter Barker: ā¦ I think weāre supposed to be using AP_ExternalControl for this stuff
UTC1157 - https://github.com/ArduPilot/ardupilot/pull/28874
-
Clean up and remove unused features
-
Merged!
UTC1159 - AP_Compass: throw away all samples which arenāt acceptable in thinning
-
Looking good, maybe a better comment
-
A little more staring and can then be merged
UTC0012 - https://github.com/ArduPilot/ardupilot/pull/30157/files
-
Allows skid-steer rovers to turn on spot
-
Condition commands were supposed stop other things until you reached a goal
-
Randy will look at this later
UTC0014 - https://github.com/ArduPilot/ardupilot/pull/31441
-
Support RC_FS_TIMEOUT on all vehicles
-
Randy wants to test
UTC0019 - https://github.com/ArduPilot/ardupilot/pull/31452/files
-
Fixes for test_build_options
-
Merged!
UTC0027 - github.com/ArduPilot/ardupilot/pull/31461
-
Fpv-lock for CaddX
-
Lock gimbal to body frame
-
Canāt land a plane if you canāt judge the pitch!
-
Need to move stuff into the mount target object
-
Some discussion on siyi and fpv mode
-
We could potentially fake FPV mode by using rate modes for the gimbals
-
Three regimes
-
Donāt lock anything
-
Pitch-lock only (earth-frame)
-
Pitch-and-roll lock (earth frame)
-
-
Do we want something which just says, ājust do FPV modeā
-
Doesnāt make sense to have complete independence of ārpyā
-
Go back to an rpy thing
UTC0047 - off the floor
-
Conference videos are going up!
-
Next conference will be in Ottowa!
-
If you want rights to do social media stuff for AP then ping tridge
UTC0049 - close
Regarding the āpitch in autolandingsā on 4.6.3, my issue is with QuadPlane not regular plane landings and RTL in particular. @robertlong13 has a PR that seems to help.
Sorry, Iām the autolanding guy;
please understand that:
1 - for me is difficult to write and understand in English, so I donāt know if itās understood what I write
2 - Iām not very good to summarize
3 - I have no programming experience
Iāve been doing thousands of autolandings for several years, the problems are:
1 - Pitch shouldnāt be directly controlled by the hight. When the hight changes due to GPS recalculations or other factors, I donāt know because I donāt know the altitude controller block diagram or loop controll, the pitch undergoes sudden changes.
2 - Similar to 1, during the flare, the pitch follows a command probably directly from the hight control. Therefore, at the moment of flare, the aircraft undergoes an attitude imbalance that is difficult for the vertical speed controller, to recover from. At the moment of flare an idea could be that the pitch must remain in the last command, then the vertical speed control intervenes. Since these are very very low-inertia aircraft, the flare must be a not very long time fase like real general aviation planes, because you have no energy margin.
All this is not caused directly by the rangefinder, praise also to whoever wrote the rangefinder library, which is exceptional at interpreting and using it even when the terrain below is complex or rough, but by the height and pitch control algorithm. For example there is another strange things in hight controller that I never reported, when I incline more that about 45 degree the roll in CRUISE mode, the hight controller commands a descend and full throttle probably for safety reasons, but in fact the plane is very energetic healty because has speed and low angle of attack, but letās postpone this to the future. Please, do not abandon the altitude control code, because this firmware, in its entirety, has achieved exceptionality, for example whoever works on EKF3 is genius, as a proof of this, with older releases I sperimented the airspeed sensor failure with a dive, a similar incident was occurred with new Boeing series with sensors failure, instead my new failures, including GPS jamming, lead to a quiet EKF lane switch that can maintain the plane in flight and subsequent recovery, another example the NAVL1 controller was written by a true genius, etc. everything is incredible, but someone needs to get their hands on the altitude controller otherwise itās a real shame like to have a Ferrari with a flat tire; I have some aircraft are in pause because attempting autolandings with them is harmful. In the past, Iāve burned out ā¬120 ESCs, and when the firmware was between the version from years ago and before 4.6.3, pitch could arrive to reach the -20 degree flare caused the nose or landing gear to be destroyed, if equipped, this was corrected from 4.6.2 to 4.6.3
The people I was referring to who could help would be:
jschall seems to be very expert in planes hight controll algorithm, then rubenp02 AP_TECS: Fix flare height demand when using a rangefinder by rubenp02 Ā· Pull Request #29230 Ā· ArduPilot/ardupilot Ā· GitHub
jknight100 ArduPlane Flare Height Cmd During AutoLand Ā· Issue #26932 Ā· ArduPilot/ardupilot Ā· GitHub
But Iām not sure, as, as I said, unfortunately I canāt interpret their code proposals
Letās comment on the logs:
1
1 - rangefinder intervenes perfectly, the pitch suddenly is commanded by almost the max, is not smooth to see in reality, I apologize but for now I have no video
2
2 - excuse me, now after posted, I see that the image has a white border down, due to bad for me paste in paint that I deemed to avoid correcting; switching in auto mode the hight controller commands rightly a change in altitude, but the pitch drops abruptly commanding about -6 degrees, not very delicate if it there were passengers, apart from that, this involves a fair loss of altitude much greater than what a gentle profile would require, in fact it is seen afterwards that it has to recover upwards this too sudden correction
3
3 - excuse image sovrapposizition, as I tell Iām not the best in screenshot and links; after some waypoints, the well scripted algorithm of landing, calculate the slope and he rightly realizes that the altitude is excessive and immediately orders a pitch down of about -15 degrees, and probably because of the previous overshoot request, the well working rangefinder asks for a pitch of 12 degrees; if the pitch requests had been a little gentler the result would have been less variable. Then the flare commands down resulting a brutal strike to terrain
4
4 - excuse image sovrapposition; at the same mode, the TECS.hdem has a request in a waypoint, could be reasonable for various reasons that I am unaware of, and the pitch commands an excursion between approximately -3 and 10 degrees, not causing any significant variation in the altitude profile, but an imbalance in the attitude
5
5 - in flare probably the plane arrived with an offset, also with probably not bad tuned constants that I tested with probably hundreds of flights, of altitude of about 30/40cm, because if I donāt remember wrong there was a quite turbulence, the TECS.hdem request a variation of pitch from an attitude of about 6/7Ā°, to about 2/3Ā°, but after a very short time, probably only the altitude variation controller is in action, which I didnāt trace to avoid confusion, it commands the maximum pitch; depending on the case this flare causes a difficult to set clean recall also changing parameters with many tests; At the moment of flare, the aircraft undergoes an attitude imbalance that is difficult for the vertical speed controller, to recover from. At the moment of flare an idea could be that the pitch must remain in the last command, then the vertical speed control intervenes. Since these are very very low-inertia aircraft, the flare must be a not very long time fase like real general aviation planes, because you have no energy margin. So when the motor shut off, the plane hand no energy to recover suddenly attitude, also if the speed scaler was very very very well scripted and runs very well commanding very well calculated excursions to the plane at very low speeds
p.s. It took me about half a day to write and try to translate this post well
the LOG: log about TECS.hdem HELP ME poor RC flight enthusiast
2 Likes