I can have a look at the log, also ping @Georacer as he has worked through a number of these issues
pinged georacer at the same time, as you told me last months; Iām surprised how well is the firmware and the solutions are incredibile as well as is probably difficult to write a code for the final approach; since some months in Italy passenger planes uses gps, baro and radar altimeter approach where there is no ILS, so the method should be secure; since many years Iāhave done thousands of autolandings, setted up parameters for a perfect approach and flare, but the hight controller shouldnāt tell the pitch such spikes expecially in the flare, because a negative pitch command, which, before the 4.6.3, reached -20 degrees, or the minumim pitch, that I set -3 degrees, among the other versions with similar bug, or in tue moment of rangefinder at 10m, anyway spikes are deprecable because the rc planes have small mass and the flare must cannot dure too much time to restabilize the asset after deprecable spikes in pitch commands; thank you excuse but in informatics and english I was ever badā¦ thank for help
Hello @Matteo_Tarsi !
Iāve taken a look at your log and I canāt spot any severe pitch demand spikes.
Could you help us by taking a screenshot of the pitch demand plot where you think the spikes happened? Is this perhaps the wrong log?
You can see that the pitch is subject to blue altitude control, with positive and negative peaks that make no sense in aviation.
In the last image, the flare is harmful because it knocks the nose down from a positive, stable attitude, and Iāve previously burned out a ā¬120 ESC that reached 80 amps when it hit the ground after pitching during the flare; isnāt it possible to create better code? There was a person on GitHub who claimed for years that he had better code for the flare and approach, but unfortunately, I donāt know how to code and Iām also a bit clumsy with links.
Hello,
Only the 1st picture you posted came through. The rest are broken links unfortunately.
Based on this one, I have isolated your 5th landing attempt, I believe this is the one in your 1st picture:
I think what happens is that once your rangefinder comes into range (11m), then the landing slope gets recalculated and the vehicle realizes itās ~1m lower than it thinks (red line).
Thus, it decides it needs to pull up and re-capture the glide slope correctly.
Iād say this is an intentional process. The fact that this results in an overly aggressive maneuver for your airframe is a different matter.
You could tune TECS to not produce such abrupt altitude changes. I donāt see any other meaningful intervention.
1 Like
George, the links are not broken, you can click and open images; anyway I posted better discussion below; George please note that TECS loop is working very very well, the hight error in landing is centimeters! But the pitch sometimes is commanded directly from the HDEM variations, is independent from the TECS parameters, it is seen from the extremely ripid slope of the pitch requests when the pitch command is given by HDEM variations and not by an offset correctable with the very very well made and functional and tunable TECS parameters. The result is abrupt pitch instability during changes of phase like waypoints, glide slope, rangefinder engaging and flare.
The problem is flare, and some people like me reported the problem that is present since more than 2 years, with a period in wich, among firmware, there was a pitch down after flare of 20 degree, I wrote here the story approssimative: 4.7 Tecs still demands negative altitudes on autoland with rangefinder Ā· Issue #31011 Ā· ArduPilot/ardupilot Ā· GitHub
and I commented log of other people here: AP_TECS: Fix flare height demand when using a rangefinder by rubenp02 Ā· Pull Request #29230 Ā· ArduPilot/ardupilot Ā· GitHub
Now with 4.6.3 the problem is less but there is a pitch command during flare with no sense, which is upwards if the rangefinder during acquisition has corrected downwards, and we have a deleterious pitch down if the rangefinder during acquisition, much more frequently since the static pressure of the barometer drops during translated flight, and therefore the real altitude is always lower than the estimated one, the rangefinder correct to hight, assuming that the landing has a space before the runway at approximately the same altitude, which leads at the very least to hitting the ground, even if from an altitude close to the ground. The flare in real plane and RC plane have to be a gentle pitch up not down, see my post. We have broken dozens of models, noses, undercarriage, in flare the nose point down, i reported in developer discussion, excuse me if inappropriate;
please help me because I have many hours of plane, RC and real, and copter RC experience, but no programming experience;
in my opinion with some experience of rc and real, the logic of controller may be different but I suppose that it is a large work, the problem is not only when rangefinder acquire, an immediate correction is also acceptable, but the flare in wich the pitch in that moment must not have a wall in demand! There also is another different problem in the logig of safety in FBWB and CRUISE MODES, in wich modes is active the TECS, if you incline more than about 45 degree the plane point down also if has speed and low angle of attack, but that is another bug to discuss in future, is not in this last log, and the controller of pitch by height is more urgent;
for simplify the project of autolanding of the code, I suggest initially a simple correction, to maintain the pitch in the moment of flare, after that can intervent the derivative H controller like now, so the flare can be controlled and smooth; than in future can be done a better work in sudden pitch changes, but for now the flare is a priority in my opinion, because it leads to breakages of nose cones, esc etc. as during the flare the nose is commanded downwards
Below, I copied the discussion that I written in other place, of the last log, than I stop all my planes.
Sorry, Iām new to this forum. The files were initially too large to support direct uplinks. I was used to Italian forums where have very little memory usage, so I added links, but I had trouble sharing them. So I wrote everything correctly. It took me three days to translate and verify that itās understandable from Italian to English. You can take a look here again:
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
1 Like
Hello,
I see you have noticed Rubenās PR which is now merged in master. Have you tried flying with master (4.7) yet? Does it seem to help with your pitch down issues during flare?
P.S. Itās very understandable to not be fluent in English. But also please understand that when you write a post that takes 15mins to read, then youāre not doing yourself or us a favour. Itās very hard to read and we get tired! If we need that much more information we can always ask. Less is more!
I thought Iād do you a favor; no I wonāt try 4.7
1 Like