Guided mode with optical flow oscillating in altitude

Hi all,

I previously posted about some problems with optical flow in loiter mode here, and was able to get them resolved thanks to the community. Thank you everyone!

For reference, we’re using the 3DR Solo which has a pixhawk 2 onboard, and we’re using ArduCopter 3.4 on board. We’ve attached and calibrated the PX4Flow and the LIDER Lite rangefinder and confirmed that they are reading values and oriented properly.

Now that we’ve verified loiter works without GPS, we are trying to move into guided mode without GPS. Currently, something seems to be wrong with the altitude. We set up our guided mode script and are actually able to takeoff to about 3 meters if we tell it to takeoff to 13 meters(similar to this issue?). Additionally, as we send various set_position_target_local_ned messages, the solo seems to navigate to the x,y position while the z position oscillates up and down. The z position seems to hop back and forth between 0.5m and 5m (sorry I don’t have logs on me but will link when I get a chance).

The issue that we are running into is that it seems that the EK2 altitude reading is just completely wrong and/or not adopting the altitude from our rangefinder. We have verified that our rangefinder is outputting correct readings through mission planner and mavproxy. When typing the command alt in mavproxy, we get a value of zero even when the rangefinder is outputting the correct value. Looking at other readings such as AHRS3 (status AHRS3) prints out a value that is also wrong–it was a few meters too high. We also saw that status did not show messages shown in SITL such as the solo’s local estimate of position.

For more information, we do see the quadcopter holds its altitude correctly after holding down the FLY button on the solo controller which seems to execute this command. So to be clear, altitude seems to be working in loiter/althold but not in guided mode (which i think includes takeoff via mavproxy).

We have gone through the forums and guides to do this and have configured our parameters like so:

EK2_ALT_SOURCE = 1
EK2_ALT_NOISE = 10
AHRS_EKF_TYPE = 2

Edit: Here is our full parameters list: link
Here is an example output of status during a flight: link

We are wondering if anyone has experienced this problem and has any insight on what we could do to override the EK2 altitude reading with the altitude from the rangefinder.

Thanks for reading,

Sam

1 Like

Definitely a dataflash log would be best. The EKF, as far as I know, doesn’t integrate range finder altitudes into it’s altitude estimate - it makes sense that it doesn’t use it because we can’t assume that the terrain under the vehicle is flat.

Thanks for the response. That makes sense – since rangefinder isn’t used for the altitude estimate, does this mean that the barometer integrations are messed up? Looking at the dataflash logs, AHR2 and BARO seem to match up. However it still seems that in GUIDED mode the merged altitude becomes very unreliable

Here is the dataflash log of a flight in stabilize: https://slack-files.com/T0Q7NPY05-F1SCBT03A-f5fcbc4ef3

Update:

We were able to get the internal (EKF) altitude updating properly by loading the latest version of ardupilot for Solo. It is based off the barometer/accelerator/etc, but now the laser rangefinder doesn’t seem to be working.

The rangefinder isn’t reading anything – we have gone through the guides to set it up and have confirmed that our parameters are correct. The only thing that changed was pushing the ardupilot for Solo onto the board instead of ardupilot master, which leads us to believe that the current ardupilot for Solo is missing something to integrate the laser rangefinder readings. However, using master we are getting other issues with incorrect altitudes.

We will continue to debug, test and update.

It links to a tlog. I haven’t downloaded, but are you sure it is a dataflash log?

That is really old. Even 3DR has more recent versions than that. But it will be harder to help if you are using a custom version.

Anyway, a couple of errors regarding altitude were found and are now fixed in master. I’m not saying that this is what was affecting you but if you to give it a try… As always: use master at your own risk.

Hi sudotong

I am trying guided mode with optical flow only, too. I can take copter off in loiter mode (use RC) and it did well. But nothing happens when I give it set_position_target_local_ned (velocity is set) command just like you. Motors is armed but throttle seems remain in minimal so the copter did not take off. I had used set_position_target_local_ned in guided mode with GPS and it did well. Could you mind please give me some hint to check? I would be very grateful. Thank you very much

I have same issue did you solve it?

I’m facing the same issue.
My hardware: Pixhawk + Pix4Flow + Lidar light.
I tried AC 3.4.6 and AC3.5_RC3. Both work perfect withot GPS indoors but only with remote control and if I arm the copter in LOITER mode. Arming it in any other mode doesn’t activate the LOITER (errors in log). But the plan is to use dronekit and to issue commands by companion computer, so GUIDED mode is a must. But the copter doesn’t takeoff in GUIDED mode with Optical Flow (without GPS) and range finder set as altitude source. It arms successfuly and maintains minimum rpm instead of climbing on the preset altitude (1-2m). The altitude readings are perfect. If I put the takeoff height more than 10m than the rpm is much higher but I’m afraid to put props as the ceiling is only 3m. May be I’ll try tommorow outdoors…

Check the thread The copter does not takeoff in Guided mode and EKF_GPS_TYPE = 3 (optical flow)
Here is a working solution for working with quad indoors in GUIDED mode. But auto-takeoff still is not implemented