Inav: SURFACE mode doesn't work

Created on 1 Jun 2019  路  52Comments  路  Source: iNavFlight/inav

Current Behavior


Quadcopter doesn't hold fixed altitude above the surface in SURFACE mode. Log is attached. Please help.
LOG00067.TXT

Steps to Reproduce


1.Arm and take off
2.Enable SURFACE mode

Expected behavior


Copter is expected to hold altitude above the ground when SURFACE mode is being enabled.

Suggested solution(s)


Maybe it is disabled for my target..

Additional context



Dump



  • FC Board name and vendor: INAV/MATEKF722 2.2.0 May 26 2019 / 19:50:46 (a713b63e4)
  • INAV version string: GCC-7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Inactive

Most helpful comment

Any news?

All 52 comments

Surface more is a modifier for altitude hold mode. It has to be enabled together with ALTHOLD or at earlier time.

I've tried this way as well. See my first comment.
Still not working

Or do you mean that firstly I should enable SURFACE and only after this ALTHOLD?

SURFACE should be enabled before or at the same moment as ALTHOLD. In your log your copter is not in surface mode, but in regular altitude hold.

SURFACE is not a mode. It changes the behavior of ALTHOLD

Best - take off in ALTHOLD + SURFACE mode

Will try and reply in 1 hour. BTW, why max sonar range is only 60 cm?

Crappy sonar hardware. INAV's limits for rangefinder/surface tracking
max_surface_altitude (2m default) - max rangefinder reading INAV will accept as a valid.
nav_max_terrain_follow_alt (1m default) - max altitude INAV will allow in terrain following mode.

Hm.. I'm using us100 + arduino. May there be limits in sketch?

On a 3-5" quad US-100 gives 60-80cm range unless you use a very good soft-mounting (soft rubber) to isolate US100 from vibrations.

I was testing range without arming. It just displays -1 write after exceeding 60 cm. That's why I think it is limited somewhere in code.
Can surface mode be always enabled? Or it can brake some other behavior like RTH or POSHOLD or GSC or any other?

That could be limited in Arduino sketch. INAV doesn't have this 60cm limit.
SURFACE mode shouldn't interfere with RTH, but it will affect POSHOLD and GSC

Here is the sketch I use.

For POSHOLD and GSC it (SURFACE) should be enabled simultaneously as well?

@digitalentity It is definitely limited in the sketch. Playing with these vars PULSE_TO_CM 500, MAX_RANGE 500. Have no idea what is what, behavior is strange, but still)))

https://github.com/iNavFlight/inav-rangefinder/issues/6#issuecomment-498005047

@digitalentity Which behavior should I expect in POSHOLD and GSC modes (with SURFACE modifier)?
P.S. Sorry for so many questions. This feature is poor documented yet.

Summarizing discussions from chat, I think the dependence on ALTHOLD is a major usability trap that could be resolved by quietly making SURFACE enable the altitude-hold code.

ie pseudocode
is_altitude_hold_enabled = isBoxMode(SURFACE) || isBoxMode(ALTHOLD)

It is not clear to me what the benefit of keeping SURFACE as a modifier dependent on ALTHOLD, especially if you can't toggle it in flight.

I agree that this is not very obvious way to switch SURFACE.
BTW here is an update
https://github.com/iNavFlight/inav-rangefinder/issues/6#issuecomment-498414007

I kind off have the same problem, sensor is a TFMini, however I see no effect of switching on surface mode even together with AltHold. Inav is version 2.2.
Please advice.
LOG00109.zip

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help.
This issue / pull request will be closed if no further activity occurs within two weeks.

Any news?

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help.
This issue / pull request will be closed if no further activity occurs within two weeks.

Automatically closing as inactive.

I鈥榤 testing the feature SURFACE as well. But the behavior differs. I had activated SURFACE together with POSHOLD. Seems to work as expected. But sometimes I鈥榙 like to activate POSHOLD without SURFACE. How to parameterize that in INAV configurator?

Is anyone going to look into this issue?

@georgekucher: Do you use this feature (SURFACE)? I鈥榤 using the Matek sensor, see https://www.rcgroups.com/forums/showthread.php?3572803-Matek-Lidar-and-INAV. It works more or less. But I do not know how to activate SURFACE in combination with ALTHOLD or POSHOLD.

Yes I have the same sensor.

SURFACE should be enabled before or at the same moment as ALTHOLD. In your log your copter is not in surface mode, but in regular altitude hold.

I'm enabling it (SURFACE) before enabling ALT/POS HOLD and it works.

Enabling SURFACE+ALT/POS HOLD simultaneously didn't work for me.
So that it requires more TX switchers to be used for this manipulations((

In my case, it's exactly the opposite.

This setup works:
SURFACE_ _POSHOLD
"Works" means: In case of activating POSHOLD&SURFACE, the copter sinks and keeps hovering at the level of approx. 100cm.

This setup doesn't works:
SURFACE_separately
"Doesn't work" means: My copter will sink slowly to the ground without hovering. When the copter reaches the ground, he rises slowly. This will repeat: sink - rise - sink - rise - ...

Hmm.. Maybe devs changed something.
I have following config
image

I assume it will take a while for me to understand what you are doing. How many positions has the switch which is linked to channel 6? It seams that you control nearly everything with this switch. Right?

I've mixed 2 3-pos. So 9 positions.
Yes I control all flight modes with this channel

It was my understanding that SURFACE mode has to be enabled before (or perhaps simultaneously with) ALTHOLD for the surface following mode to activate. SURFACE has no function when activated separately-- it's purely a modifier for ALTHOLD.
See my comment far above about the usability problem this causes because it is difficult to understand.

It was my understanding that SURFACE mode has to be enabled before (or perhaps simultaneously with) ALTHOLD for the surface following mode to activate. SURFACE has no function when activated separately-- it's purely a modifier for ALTHOLD.
See my comment far above about the usability problem this causes because it is difficult to understand.

Yes, I totally agree with you. Further more, the same should be done for POSHOLD+SURFACE

Wait... does this work? You can get into surface following mode while in POSHOLD mode without ALTHOLD on?

That's my aim. But it does not work. POSHOLD and ALTHOLD works, but without the lidar surface feature. And I thought I can activate the lidar surface feature separately.

I assume that I have to try mixing channels to achieve that. I up to now I haven't used the channel mix feature.

Wait... does this work? You can get into surface following mode while in POSHOLD mode without ALTHOLD on?

Yes

Actually I can get into POSHOLD while it SURFACE

Try it this way. Using two three-pos switches,
Switch 1:
Pos A) SURFACE+ALTHOLD
Pos B) Nothing
Pos C) ALTHOLD

Switch 2:
Nav modes, however you like.

Try it this way. Using two three-pos switches,
Switch 1:
Pos A) SURFACE+ALTHOLD
Pos B) Nothing
Pos C) ALTHOLD

This is my config now

I have the budget FS-i6. With the 10 channel update and some modified switches.
FSi6

I try to use the channel mix feature to solve the task.

I have the same. Only with 16 channels and a bit different switches upgrade

Great! May you be so kind and tell me how to parameterize the mix? I鈥榙 like to use two of my 3 position switches to do what you did. Setup has to be performed in the radio. Right?

I'm a bit confused why this overly complicated setup is necessary. For example, if you drop the need to fly in althold modes without poshold active (when nav_user_control_mode is set to ATTI, which is the default, you get angle-mode control while in POSHOLD anyway), you could do this:

Switch 1: Position hold modes
Position A) POSHOLD+ALTHOLD
Position B) Nothing
Position C) POSHOLD+ALTHOLD+SURFACE

Switch 2: Autonomous navigation modes
Position A) NAV WP
Position B) Nothing
Position C) NAV RTH

I don't have the ability to test this right now, but as far as I can tell, NAV WP and NAV RTH override ALTHOLD anyway to follow their programmed waypoints or return-to-home behavior.

I'm a bit confused why this overly complicated setup is necessary. For example, if you drop the need to fly in althold modes without poshold active (when nav_user_control_mode is set to ATTI, which is the default, you get angle-mode control while in POSHOLD anyway), you could do this:

Switch 1: Position hold modes
Position A) POSHOLD+ALTHOLD
Position B) Nothing
Position C) POSHOLD+ALTHOLD+SURFACE

Switch 2: Autonomous navigation modes
Position A) NAV WP
Position B) Nothing
Position C) NAV RTH

I don't have the ability to test this right now, but as far as I can tell, NAV WP and NAV RTH override ALTHOLD anyway to follow their programmed waypoints or return-to-home behavior.

The thing is that I don't want to drop flying in ALTHOLD. This is why I mixed switches into 9pos

Great! May you be so kind and tell me how to parameterize the mix? I鈥榙 like to use two of my 3 position switches to do what you did. Setup has to be performed in the radio. Right?

Yes. In radio. You should go to TX setup and assign 2 switches to a channel. In my case this is Channel6=SWB+SWC. The firmware of the TX should have this options.
15867365087955720683098540644474
15867366160887384136377956437246

15867367285992634586973325852505

Have you ever seen this strange behavior with SURFACE & POSHOLD and full throttle?
https://youtu.be/0SNdMbonubk

Hm..
No never.

I'm despairing. Have you performed the "Optic Flow Calibration"? I did that several times on different surface (inside, outside, lawn, wood, ...). The result (value of "Scale") is always different. But the calibration seems to have impact on the result of the debug signals. Especially on Debug 1. Currently, it looks like that:
Debug

Should be ok, but the Sonar sensor signal looks not that good:
Sonar

Have you performed the "Optic Flow Calibration"?

No I didn't.

Should be ok, but the Sonar sensor signal looks not that good:

My performs very likely.

This has now veered far off topic, but IR rangefinders can have difficulty in full sunlight.

Also ensure this condition is met from the Matek datasheet:

Make sure Optical Flow lens to ground >2cm for opflow initialization while FC starting up.

Thanks anyway...

Was this page helpful?
0 / 5 - 0 ratings