Switching to AutoHold results in abrupt and continous climb after flashing latest dev build

The following snapshot corresponds to stable Altmode switch in OctaQuad-X configuration with older build V4.5.7. Here CTUN’s alt and CTUN’s Balt are in line and CTUN’s DAlt switches to flying altitude the moment AltHold is enabled

I recently took latest master (v4.7.0) changes and with that custom build AltMode is having issues.

There are three barometers. One external and 2 internal (Cube Orange). Barometer’s Alt is reporting within acceptable range

Whereas CTUN BAlt is 6 order of mangitude higher and when FlightMode is switched from Stablize to AltHold. DAlt is lineary increasing may to catch with with CTUN’s BAlt. What could be the issue. Also with this build have enabled TF02 RangeFinder and RPLidar A2M12 and hence Parameters changes related to enable and read relevant values have been changed. Can this Cause CTUN BAlt’s reading to be so high.

Even with unplugged range-finder and lidar CTUN’s BAlt is in the range of 10^6.

https://drive.google.com/file/d/1JN6zPUhqSaP3nNLSaVoJ0Xixqjlk7llw/view?usp=sharing Log file attached

You are using unstable development firmware somewhat blindly. Revert back to 4.6.2 stable and report back if problems persist.

I do not think it is a good idea to disable the Arming Checks at this stage and during operation.

1629 0001-01-01 00:00:52.580 MSG 52580310 ArduCopter V4.7.0-dev (36b5b0be)
1630 0001-01-01 00:00:52.580 MSG 52580319 ChibiOS c6d0293e
1632 0001-01-01 00:00:52.580 MSG 52580366 CubeOrangePlus 00290044 31335104 34343730
1633 0001-01-01 00:00:52.580 MSG 52580377 Param space used 1455/5376
1634 0001-01-01 00:00:52.580 MSG 52580385 RC Protocol CRSF
1635 0001-01-01 00:00:52.580 MSG 52580397 RCOut PWM
1636 0001-01-01 00:00:52.580 MSG 52580403 New mission
1638 0001-01-01 00:00:52.582 MSG 52582385 New rally
1639 0001-01-01 00:00:52.582 MSG 52582391 New fence
1640 0001-01-01 00:00:52.582 MSG 52582402 Frame OCTAQUAD/X
1642 0001-01-01 00:00:52.582 MSG 52582417 GPS 1 specified as DroneCAN1-125
21737 0001-01-01 00:01:24.249 MSG 84249699 Warning Arming Checks Disabled
50939 0001-01-01 00:02:10.417 MSG 130417241 EKF3 IMU1 MAG0 in-flight yaw alignment complete
51000 0001-01-01 00:02:10.519 MSG 130519755 EKF3 IMU2 MAG0 in-flight yaw alignment complete
51065 0001-01-01 00:02:10.614 MSG 130614732 EKF3 IMU0 MAG0 in-flight yaw alignment complete

Have you done a ESC calibration?
Have you done an RC calibration?
Do you know what ESC type you are using for your 9" Octocopter?
Have you done a Motor test?
What is the drone takeoff weight?

MOT_PWM_TYPE,0
MOT_SPIN_MAX,0.95
MOT_SPIN_MIN,0.15

The main reason i took is to have RPLIDAR A2M12 support which was added a few weeks back. will try to reproduce the issue in stable build

In Stable build 4.6.2 built locally. CTUN’s DAlt still raises when AltHold is enabled but CTUN’s BAlt now tracks that of Baro’s Alt. What could be the issue in configuration. Please note, have added TF02 RF with this setup.

Logs are at https://drive.google.com/file/d/1ufCmF1dJ3xxbHOZjmUG89KilI3WBeGeP/view?usp=sharing

Yes they were done before migrating to new build from my previous 4.5.7. Do I need to re-calibrate alfter flashing a firmware

Please note in build 4.5.7 Copter was flying stable in AltMode, PosHold


Even the newly added RangeFinder’s Distance to ground tracks well with that of Baro’s and THO is around 45% to 50%. So AltHold should work as it was working in my previous build.

What do I need to tune further?

1 Like

What do you mean? You compile the source code?
You are using Cube Orange Plus, right?

Probably the vertical acceleration gains have not been set. That causes this kind of behavior.

The documentation clearly explains that you need to do that directly after the first flight, and that only after doing it can you safely use AltHold and loiter flight modes.

Please do not use the outdated poshold flight mode.

2 Likes

I think it is easy to revert back to 4.5.7 and get a flight log, without another hardware change, then move to 4.6.2 or 4.7.0-dev and get another flight log. I think the developer team will be interested in understanding further.

Any reason why you choose to do a custom build for your Cube Orange Plus instead of just use the pre-build version?

@Jai.GAY the custom build was to enable the A2M12 lidar, right?

Oh I see, so RPLidar A2M12 is potentially the culprit that screw up the height holding?

I do not think that. I think the culprit is what i described four posts above.

Thank you

Got the culprit. By comparing changed-parameters(which is suspect is because of flashing) after flashing dev or 4.6.2 build that MOT_THST_HOVER was reset to default value (0.2). After reverting back to the value which was around 0.45 from the backedup parameter file(before flashing). Post that AltHold is working and is becoming more stable with flights as MOT_HOVER_LEARN is enabled. Now with multiple flights in AltHold mode it is learned to 0.55 as around 190g + 90g of extra sensors RPLidar AP2M12 and Benewake Rangefinder TF02 have been added.

So my next question what parameters would be reset to default values when a binary is flahsed or updated?

No. It is not because of your recent changes to support the sensor. Thanks for your commit the Proximity sensor works.

What is your procedure when you are doing the upgrade and downgrade? Which tool is used? Do you have a video?

Mission Planner 1.3.83 build is used. Just flash the locally built .apj image whether it is upgrade or downgrade through “Install Firmware” → “Load Custom Firmware” option.

Downgrading requires that you restore the parameters from a backup that you made when using the old version before upgrading.

Upgrade does not require that manual backup, nor restore.

Have you downgraded correctly?

I am afraid to say no. Was not aware downgrade needs backed-up params to be re-installed though it now makes sense for me to do so.