The copter does not takeoff in Guided mode and EKF_GPS_TYPE = 3 (optical flow)

I’m using Pixhawk with companion computer for indoors “missions”. I’m familiar with controlling the arducopter with GPS using companion computer with Dronekit and it works good. But now I need a flying platform for GPS denied conditions. I have successfully installed the Pix4Flow sensor with Lidar Light in PWM mode. And everything works quite good when arming the drone in Loiter mode using RC. So the Loiter mode uses the rangefinder and optical flow sensor for position hold. I’m also capable to send commands to my Pixhawk controller while it is in Loiter using channel override. But it seems to me a little bit ugly solution.
I’ve got a very basic script that puts the drone to guided mode, arms it and forces it to take off for the altitude say 5m, then it wains for a while and lands. With EKF_GPS_TYPE = 0 (using GPS) and EKF_ALT_SOURCE = 0 (using baro) it works excellent. But when I switch to optical flow EKF_GPS_TYPE = 3 and EKF_ALT_SOURCE = 1 then the copter just arms and then raises a little bit rpm. But it does not takeoff. The same issue is with AC 3.5-RC4.
What can be done in order to be able to takeoff the drone indoors and send velocity commands in guided mode?

Hi Constantine,

Can you share a log of when it doesn’t work? Not required, but if you can do it with LOG_DISARMED set to 1, it might have more interesting information.

2017-04-21 21-58-37.bin (1.3 MB)
Hi Francisco,

Here is a log with LOG_DISARMED set to 1. This log shows one more issue I saw earlier only once - after the takeoff command (dronekit simple takeoff) the two motors gradually increase their rpm.

Hello Constantine,
You have to use a very recent version of ardupilot (i.e. master from within the past few days)
Enable optical flow and make sure it can be flown in Loiter mode
You need to set: AHRS_EKF_TYPE = 3, EK2_ENABLE = 0, EK3_ENABLE=1 , GPS_TYPE = 0
Within Mission Planner select ‘Set home here’ then the vehicle should appear on the map
Then you can take-off in loiter mode and set guided through Mission Planner (or using commands).
Please note , I cannot take-off guided yet with Optical Flow yet , we are working on it.
Please update with your results :slight_smile:


Thank you for reply. I compiled and uploaded to Pixhawk the latest ArduCopter master V3.6-dev (1a246851). Double-checked the parameters AHRS_EKF_TYPE = 3, EK2_ENABLE = 0, EK3_ENABLE=1 , GPS_TYPE = 0. Pointed a ‘Set home here’ within a MP and took-off in Loiter mode. Still when switching to Guided Mode the log says Err:FLIGHT_MODE-4 and the hud shows: error switching the flight mode. So no success.
Is the AC version I’ve compiled is suitable for purpose?


When you set home, do you see the quad icon appears , and does the image move (leaving a purple trace and showing magnetic heading and altitude) on the screen when you physically move the quad?

1 Like

Thank you for the help
Now it works! The problem was in EK3_ENABLE=1. I didn’t understand if it was because of the MissionPlanner version or I forgot to save the parameter. But after I updated to the latest MP v1.3.46 and noticed the EK3_ENABLE was zero. So I switched it to 1 and now the quad behaves as you describe and I’m able to switch to Guided mode. The MP shows all the quad movements according to the OF sensor. Excellent. Tomorrow I’ll make a flight test and report!
Tanks again!

My today’s flight test of the guided mode with optical flow is mostly successful. I can control the quad with my script!
There is one new question. What should be the EK3_ALT_SOURCE value? By default it is 0. It means that it uses baro not the rangefinder. I’m asking because sometimes I notice a sudden altitude changes especially when I command yaw change while in guided mode.

Are you able to takeoff guided ?
And I agree with you concerning the EK3_ALT_SOURCE it need to work with the RangeFinder.

Looking here:
EK3_ALT_SOURCE: Primary altitude sensor source

Note: This parameter is for advanced users
This parameter controls the primary height sensor used by the EKF. If the selected option cannot be used, it will default to Baro as the primary height source. Setting 0 will use the baro altitude at all times. Setting 1 uses the range finder and is only available in combination with optical flow navigation (EK3_GPS_TYPE = 3). Setting 2 uses GPS. Setting 3 uses the range beacon data. NOTE - the EK3_RNG_USE_HGT parameter can be used to switch to range-finder when close to the ground.

Value Meaning
0 Use Baro
1 Use Range Finder
2 Use GPS
3 Use Range Beacon

So we should be able to use the rangefinder as the altitude sensor using opticalflow – it works in EKF2–, but I seems that its not implemented with EKF3. Note: I asked on developpers for comments.

The thing is that when I set the EK3_ALT_SOURCE=1 and EK3_RNG_USE_HGT=something_else_but_-1 then the ArduCopter will not arm, because of “Prearm Check: Need GPS fix”. Strange, isn’t it? So I left them with default values.
If I try to take off in guided mode (my RC control is turned on for safety, and throttle is in minimum) then the quad starts all the motors for 5 seconds and then disarms. But when I do the same but with the throttle set to middle then the quad seems to try to take off. I did it without props. I’ll do the real take off in guided mode without GPS later and report.

OK we have exactly the same pattern then, so its good to know we are now 2 Beta Tester for this test case. Hopefully it will be easier and faster to pinpoint problems and test solutions.

Btw , my goal is to implement Randy’s Balloon fFinder in Guided mode in GPS denied using Optical flow.
Here is a test with the Red Ball using OpenMV and running Precision Landing Library - in loiter mode.

I saw this awesome project, but I noticed it after I’ve implemented my own red mark hunter :slight_smile:.
It was an interesting trial. And now I’m trying to implement a simple wall following quad (sonar-based)

So, I checked the take-off without GPS and it works!!! I put the 1m altitude to try it, and it was an overshoot up to about 1.5m and then it stayed in the air at the altitude of about 0.5-0.6m. Not bad.
Here is the log.5 1-1-2000 5-46-18 AM.bin (845.4 KB)

Super Really like the Tag Attack !!

What have you changed in the configuration to make the Quad TakeOff Guided since the last post ?

We are working as well on an avoidance library that you could use with the sonar. Acutally I am working with an Arduino based VL53 IR ToF 360 degree distance sensor i called the “POC” look here:

1 Like

Wow, “POC” is great. Thank you for info. Will follow the progress.

Concerning the GUIDED + OF take-off, really, I did nothing. Once I put the props and commanded takeoff, the quad started to make a smooth jumps for 1m altitude. I checked the log, and it said “Err:FLIGHT_MODE-2”. WtF! It’s a shame, but I forgot to “Set Home Here” from MP.
Just in case someone want to check my quad’s settings I’ve attached the *.param file.
AC3.6-dev_of_lidar_nogps_params.param (13.2 KB)

Ok Thanks for reporting, I will make additional tests and finally make a quadcopter ‘‘guided tour’’ of my garage :slight_smile:

Its Fixed =

Thanks to Paul Riseborough, we can now fly OpticalFlow with RangeFinder as the primary altitude sensor :slight_smile:

Hi @dollop , @ppoirier

Did you use MAV_CMD_NAV_TAKEOFF_LOCAL, MAV_CMD_NAV_TAKEOFF to take copter off? Or use SET_POSITION_TARGET_LOCAL_NED to give copter velocity? Thank you very much

Hi @chobitsfan,
To test the takeoff I used the dronekit command vehicle.simple__takeoff(TargetAltitude). Exactly as decsribed here

Great, tanx!

Hi @dollop
Thanks a lot for your reply. I found vehicle.simple__takeoff send MAV_CMD_NAV_TAKEOFF message. Thank you

Hi @dollop

I see in you .param file. you set EK3_GPS_TYPE = 0. But EK3_GPS_TYPE 0 means “GPS 3D Vel and 2D Pos”? I am sorry for my poor English