Poshold with optical flow works weird

I’m using firmware ver-1.5.5 (LPE) with my pixhawk and try using optical flow
and I have same issue with


and a little difference is I sometimes can get in to poshold mode but my copter flies crazy and crash down
and one more question what is MPC_ALT_MODE?
what is the difference between ‘terrain following’ and ‘altitude following’ ??

Can you post a log? It’s hard to help otherwise.

Re MPC_ALT_MODE: “altitude following” means the vehicle will perform altitude hold (position control in the z axis) with respect to the estimated altitude, which is based on baro and/or GPS. in “terrain following” the vehicle will control its altitude such that the height above ground (based on range measurements) remains constant (unless you change the altitude setpoint of course).
If you are flying over completely flat ground, there is essentially no difference. If you are flying e.g. up a hill, “terrain following” will result in the vehicle climbing in order to keep its height above ground, altitude following" will result in the vehicle getting closer and closer to the ground.

thank you for the reply and here are two logs
http://logs.uaventure.com/view/ZfYtmfYoFKbZaAZgreYU8J this is one tested outdoors and thrust ctrl had some problem, if I change in to alt_hold, copter just rises and if I get in to pos_hold than it seems to be rejected and even not rejected for few seconds, performance was not that reliable

http://logs.uaventure.com/view/U4o9Ddq46KhzikVLMmk8n5 this is one tested indoors and alt_hold was fine(no rising) but after switching to pos_hold my copter flew crazy and crashed…:cry:

One problem that I see is that your range sensor is very noisy. Most of the time it is not actually fused into the HAGL estimate, which is fatal for flow.

You should see in the message logs if/when lidar and flow measurements begin/stop to be fused with messages like “[lpe] lidar init: mean X cm stddev Y cm”.
You can find the message log in the root directory of the SD card, the names are the timestamps of the boot-time.

You are using the sonar on the PX4FLOW board, correct? Do you have another range sensor (lidar lit/TeraRanger) at hand to try?

2016_11_16_10_26_43: [lpe] Sonar detected with ID 0
2016_11_16_10_26_43: [lpe] land init
2016_11_16_10_26_43: [lpe] baro init -131 m std 28 cm
2016_11_16_10_26_44: [lpe] z resume
2016_11_16_10_26_44: [lpe] tz resume
2016_11_16_10_26_59: ARMED by RC
2016_11_16_10_26_59: [blackbox] /fs/microsd/log/2016-11-16
2016_11_16_10_26_59: [blackbox] recording: 10_26_59.px4log
2016_11_16_10_27_05: [lpe] sonar timeout
2016_11_16_10_27_06: DISARMED by RC
2016_11_16_10_27_07: [blackbox] stopped (333 drops)
2016_11_16_10_27_09: [lpe] sonar init std > min
2016_11_16_10_27_13: [lpe] flow init: quality 254 std 0
2016_11_16_10_27_13: [lpe] xy resume
2016_11_16_10_27_16: [lpe] flow timeout
2016_11_16_10_27_20: [lpe] sonar timeout
2016_11_16_10_27_24: [lpe] xy timeout
2016_11_16_10_28_20: PREFLIGHT FAIL: GPS RECEIVER MISSING
2016_11_16_10_28_20: MANUAL CONTROL LOST (at t=102134ms)
2016_11_16_10_28_20: MANUAL CONTROL REGAINED after 2075ms
2016_11_16_10_28_33: ARMED by RC
2016_11_16_10_28_33: [blackbox] /fs/microsd/log/2016-11-16
2016_11_16_10_28_33: [blackbox] recording: 10_28_33.px4log
2016_11_16_10_28_35: Takeoff detected
2016_11_16_10_28_39: [lpe] sonar init std > min
2016_11_16_10_28_40: [lpe] flow init: quality 250 std 10
2016_11_16_10_28_40: [lpe] xy resume
2016_11_16_10_28_41: [lpe] sonar init std > min
2016_11_16_10_28_42: no gps
2016_11_16_10_28_42: failsafe mode on
2016_11_16_10_28_42: LOW BATTERY, RETURN TO LAND ADVISED
2016_11_16_10_28_43: [lpe] sonar init std > min
2016_11_16_10_28_44: [lpe] sonar init std > min
2016_11_16_10_28_46: [lpe] sonar init std > min
2016_11_16_10_28_48: CRITICAL BATTERY, LANDING ADVISED!
2016_11_16_10_28_48: [lpe] sonar init std > min
2016_11_16_10_28_50: [lpe] sonar init std > min
2016_11_16_10_28_52: [lpe] sonar init std > min
2016_11_16_10_28_53: [lpe] sonar init std > min
2016_11_16_10_28_54: [lpe] sonar init std > min
2016_11_16_10_28_55: failsafe mode off
2016_11_16_10_28_58: [lpe] flow timeout
2016_11_16_10_28_58: [lpe] sonar init std > min
2016_11_16_10_29_05: DISARMED by RC
2016_11_16_10_29_05: [lpe] xy timeout
2016_11_16_10_29_05: [lpe] sonar timeout
2016_11_16_10_29_05: [lpe] land fault, beta 19.71
2016_11_16_10_29_06: [blackbox] stopped (0 drops)
2016_11_16_10_29_07: Landing detected

2016_11_16_10_26_43: [lpe] Sonar detected with ID 0
2016_11_16_10_26_43: [lpe] land init
2016_11_16_10_26_43: [lpe] baro init -131 m std 28 cm
2016_11_16_10_26_44: [lpe] z resume
2016_11_16_10_26_44: [lpe] tz resume
2016_11_16_10_26_59: ARMED by RC
2016_11_16_10_26_59: [blackbox] /fs/microsd/log/2016-11-16
2016_11_16_10_26_59: [blackbox] recording: 10_26_59.px4log
2016_11_16_10_27_05: [lpe] sonar timeout
2016_11_16_10_27_06: DISARMED by RC
2016_11_16_10_27_07: [blackbox] stopped (333 drops)
2016_11_16_10_27_09: [lpe] sonar init std > min
2016_11_16_10_27_13: [lpe] flow init: quality 254 std 0
2016_11_16_10_27_13: [lpe] xy resume
2016_11_16_10_27_16: [lpe] flow timeout
2016_11_16_10_27_20: [lpe] sonar timeout
2016_11_16_10_27_24: [lpe] xy timeout
2016_11_16_10_28_20: PREFLIGHT FAIL: GPS RECEIVER MISSING
2016_11_16_10_28_20: MANUAL CONTROL LOST (at t=102134ms)
2016_11_16_10_28_20: MANUAL CONTROL REGAINED after 2075ms
2016_11_16_10_28_33: ARMED by RC
2016_11_16_10_28_33: [blackbox] /fs/microsd/log/2016-11-16
2016_11_16_10_28_33: [blackbox] recording: 10_28_33.px4log
2016_11_16_10_28_35: Takeoff detected
2016_11_16_10_28_39: [lpe] sonar init std > min
2016_11_16_10_28_40: [lpe] flow init: quality 250 std 10
2016_11_16_10_28_40: [lpe] xy resume
2016_11_16_10_28_41: [lpe] sonar init std > min
2016_11_16_10_28_42: no gps
2016_11_16_10_28_42: failsafe mode on
2016_11_16_10_28_42: LOW BATTERY, RETURN TO LAND ADVISED
2016_11_16_10_28_43: [lpe] sonar init std > min
2016_11_16_10_28_44: [lpe] sonar init std > min
2016_11_16_10_28_46: [lpe] sonar init std > min
2016_11_16_10_28_48: CRITICAL BATTERY, LANDING ADVISED!
2016_11_16_10_28_48: [lpe] sonar init std > min
2016_11_16_10_28_50: [lpe] sonar init std > min
2016_11_16_10_28_52: [lpe] sonar init std > min
2016_11_16_10_28_53: [lpe] sonar init std > min
2016_11_16_10_28_54: [lpe] sonar init std > min
2016_11_16_10_28_55: failsafe mode off
2016_11_16_10_28_58: [lpe] flow timeout
2016_11_16_10_28_58: [lpe] sonar init std > min
2016_11_16_10_29_05: DISARMED by RC
2016_11_16_10_29_05: [lpe] xy timeout
2016_11_16_10_29_05: [lpe] sonar timeout
2016_11_16_10_29_05: [lpe] land fault, beta 19.71
2016_11_16_10_29_06: [blackbox] stopped (0 drops)
2016_11_16_10_29_07: Landing detected

yes I’m using my sonar on px4flow
these are the log msgs and I ordered lidar today

2016_11_16_10_28_39: [lpe] sonar init std > min
2016_11_16_10_28_40: [lpe] flow init: quality 250 std 10
2016_11_16_10_29_05: [lpe] xy timeout

can you explain what this log means? and does ‘timeout’ means it just doesn’t work?

You can see that the height above ground estimate is re-initialized several times due to poor/invalid range measurements.

“sonar timeout” is printed here and depends on the _time_last_sonar timestamp which only gets updated if the range measurement is valid:

“flow timeout” can happen for a variety of reasons, including bad height above ground estimate.

Since you do not have a GPS connected you have no position estimation anymore once flow times out, causing the “xy timeout”, and the quad goes into failsafe mode.

You could try flying over other surfaces that might be more reflective to sonar, but ultimately you’ll be better off with a light based TOF range sensor.

I got lidar and I did
https://pixhawk.org/peripherals/rangefinder?s[]=lidar
these installations but I couldn’t get my lidar work
I coudn’t get lpe lidar init message and my pixhawk still uses sonar for distance sensing

I gave power from RCIN pwm port
I did check 5v comming out from aux6
I uncommented //if (_lidarInitialized && (_lidarFault < fault_lvl_disable)) { return; }
this line from lpe sensor sonar code

by the way how do I make direct link from github code like you did??

Is the lidar working in general? I.e. do you see range measurements with only the lidar attached, flow module detached?
Do you have a lidar v3? I start mine (on a PixFalcon) with ll40ls -X start (note the -X for expansion I2C bus option).

You may have a conflict when you have two range sensor devices attached, which will both publish on the same topic. The driver that is started first will be the one that LPE ends up using.

You should be able to fix that by ensuring that the lidar driver is started first, e.g. by inserting the start command in rcS, somwhere above this line:

Re github link: Simply click on the line number you want to reference, this will add the line number to the URL. Paste it into discuss with a blank line above and below, discuss will then expand it.

thank you so much for the reply

I think my lidar does not work in general I can’t see distance value through QGC analyze when I detach px4flow
what could be gone wrong?
yes I’m using v3 though PWM aux pin

and this is the line I uncommented to override sonar, is this not enough? or is this the line should be commented?

I have no experience with the lidar on PWM aux pin, so I can’t offer any advice.

I don’t think you need to uncomment that line. It appears to be a relic. Neither _lidarInitialized nor _lidarFault appear anywhere else in the code. LPE does not actually differentiate between different range measurement sources, it just uses whatever is on the distance_sensor topic, which is then fused in sonar.cpp.

ok I will try other way thank you Nicolas !:grinning: