I’ve only now paid attention to the ESP32 support, is there any tutorial on how to build the FC with it?
TERRAIN FOLLOWING ISSUE IN RTL/GUIDED MODES
Hi @tridge ,
I think this issue has been going on since previous versions.
It turns out that terrain following works in CRUISE/FBWB/LOITER/AUTO modes but fails (as if it didn’t exist) in RTL/GUIDED modes.
I did a lot of tests in SITL with the same result; trying to find an explanation I tried changing the primary altitude sensor in EKF3 (BARO/GPS), disabling the range finder, using 90/30m resolution altimetry, changing (increasing) TERRAIN_LOOKAHD values. Always with the same negative result.
I have noticed that the total failure is when using RALLY POINTS to indicate where to DO_LAND_START from. In this case, at the moment of activating the RTL, a descent path is started to meet the height of the RALLY POINT when arriving to its meeting point. But despite the obstacles present, it never modifies its vertical speed, so it ends up colliding with the obstacles.
If the RTL does not use RALLY POINTS it first makes a sharp descent to meet ALT_HOLD_RTL (this is measured above the terrain). In this aspect it can be said that WITHOUT RALLY POINTS it works. What also happens is that it gives the impression of not taking into account TERRAIN_LOOKAHD (in my case 3000) and can lose 300m of altitude when before that 3000m it will have to recover (as I said before it seems to respond to the immediate and does not anticipate).
I’d need a log. I’ve just tested in GUIDED an RTL modes with TERRAIN_FOLLOW=1 and it is working correctly.
Do you have TERRAIN_FOLLOW set to 1? That is needed in GUIDED and RTL modes.
Cheers, Tridge
I have now reproduced this once in SITL with 4.4.1. A second attempt to reproduce did not see the bug. So it appears to be an intermittent failure with using terrain following with rally points.
Many thanks for reporting this issue! I will try to get it fixed for 4.4.2.
I am tracking the issue here:
ESP32 support is quite experimental. I suggest you join the esp32 group on the ArduPilot discord server to discuss with the developers
Start RTL about 12.8km from the rally point, with an altitude of 600m relative to the take-off point. The rally point has an altitude of 60m relative to the take-off point.
At about 6.5km from the RTL point there is a crest of about 480m (approx.) relative to the take-off point. Despite having TERRAIN_LOOKAHD=3000 the aircraft reaches a height of 390m relative to the take-off point. It ends up impacting against the hillside.
I will have repeated this simulation if not hundreds of times, then dozens of times with the same result (despite making a few parameter changes).
As you can see the TECS.dh is absolutely stable until the impact occurs.
ok, thank for your replay.
@Lano thanks! I’ve made an automatic test to reproduce the issue and a fix here:
I will likely get this fix into 4.2.2 stable
Thank you to the entire development team for your dedication and for responding so promptly to our feedback.
I’ve just released plane 4.4.2-beta1. This includes some important fixes in several areas.
- BETAFPV-F405 support
- MambaF405v2 battery and serial setup corrected
- mRo Control Zero OEM H7 bdshot support
- SpeedyBee-F405-Wing gets VTX power control
- SpeedyBee-F405-Mini support
- T-Motor H743 Mini support
- EKF3 supports baroless boards
- INA battery monitor supports config of shunt resistor used (see BATTx_SHUNT)
- BMI088 IMU error value handling fixed to avoid occasional negative spike
- Dev environment CI autotest stability improvements
- OSD correct DisplayPort BF MSP symbols
- OSD option to correct direction arrows for BF font set
- Sensor status reporting to GCS fixed for baroless boards
- added opendroneid option to auto-store IDs in persistent flash
- fixed TECS bug that could cause inability to climb or descend
- fixed race condition when starting TECS controlled mode
- fixed RTL with rally point and terrain follow
- protect against invalid data in SBUS for first 4 channels
- added build type to VER message
- allow moving baseline rover at 3Hz
- use RC deadzones in stick mixing
Testers welcome!
2 Likes
4.4.2beta1 on Matek F405wing(AWS28: FBWA, AUTO) and Matek H743 Wlite (Manta: QHOVER, FBWA, CRUISE) flown without problems.
Rolf
1 Like
Flown without problems today and inverted home arrow issue for DJI Goggles2 users is history now (translate arrows). Thank you!!!
3 Likes
Good news! 
Does the “translate arrows” of OSD_OPTIONS work in the old versions?
The inverted home arrow issue
I’ve just released plane 4.4.2 stable. There are no changes from 4.4.2-beta1.
The changes from 4.4.1 are:
- BETAFPV-F405 support
- MambaF405v2 battery and serial setup corrected
- mRo Control Zero OEM H7 bdshot support
- SpeedyBee-F405-Wing gets VTX power control
- SpeedyBee-F405-Mini support
- T-Motor H743 Mini support
- EKF3 supports baroless boards
- INA battery monitor supports config of shunt resistor used (see BATTx_SHUNT)
- BMI088 IMU error value handling fixed to avoid occasional negative spike
- Dev environment CI autotest stability improvements
- OSD correct DisplayPort BF MSP symbols
- OSD option to correct direction arrows for BF font set
- Sensor status reporting to GCS fixed for baroless boards
- added opendroneid option to auto-store IDs in persistent flash
- fixed TECS bug that could cause inability to climb or descend
- fixed race condition when starting TECS controlled mode
- fixed RTL with rally point and terrain follow
- protect against invalid data in SBUS for first 4 channels
- added build type to VER message
- allow moving baseline rover at 3Hz
- use RC deadzones in stick mixing
Happy flying!
3 Likes
Can’t play MissionPlanner SITL with Xplane 11.
When I connect MissionPlanner with Xplane 11, the Xplane’s Joystic data can’t be transfered to MissionPlanner because the check mark of the “8 Joystic Aileron/elevator/rudder” in the “Network via UDP” column of the “Data Output” page disappers and it can’t be set again.
Could you teach me how I can resolve this problem?
the current display in MP is always display 0.6A when connect to battery even increasing throttle to let the motor spin fast. i have check the parameters below several times 
Enable Battery monitor.
BATT_MONITOR =4
Then reboot.
BATT_VOLT_MULT 11.05
do anyone have this issue,i not sure if this is the new firmware issue.
the firmware is 4.4.1 stable,
does firmware 4.4.2 stable change anyting of this above?
mini+talon+vtol.param (22.0 KB)
I’ve just released plane 4.4.3-beta1. This is a minor update with a few important fixes.
Changes from 4.4.2:
- fixed setup of ICM45486 IMU on CubeOrangePlus-BG edition
- disable AFSR on IxM42xxx IMUs to prevent gyro bias for “stuck” gyros
- fixed AK09916 compass being non-responsive
- implement GPS_DRV_OPTION for using ellipsoid height in more GPS drivers
- fixed SIYI AP_Mount parsing bug
- configuration fixes for BETAFTP-F405 boards
- fixed origin versus home relative bug in quadplane landing and guided takeoff
- correct mavlink response for no airspeed sensor on preflight calibration
- protect against notch filtering with uninitialised RPM source in ESC telemetry
- allow lua scripts to populate full ESC telemetry data
- added YJUAV_A6SE_H743 support
Please test!
1 Like
Hello. I encountered a fatal problem where my plane crashed due to downtime during flight. At first, it flew very well, but when I was about to land, I suddenly lost control and fell to the ground. I am using the main controller STM32H750VBT6, firmware version Plane-4.4.0, and IMU ICM42688P+ICM20608G. Could you please help me analyze the logs?
STM32H750VBT6.param (21.1 KB)
where are the logs? I only see a parameter file in your message