Problem on Optical flow on APM 3.3rc8 Paul or Randy can you help me to understand the problem please

[Roberto Navoni]

Dear Friend,
in last week we are testing the APM 3.3rc8 on VR Brain 5.2 , we are
checking all nuttx driver and advanced functionality like Optical Flow
loiter and lidar terrain following functionality.
So about the lidar we are very happy ... did a lot of test and all
work fine as you can see in this video:
https://www.youtube.com/watch?v=XXTeOogVd8k&feature=youtu.be

After the test of alt hold we start to evaluate optical flow , follow
the wiki instruction did the first fight well and check the log ...
then activate the optical flow , armed the drone in stabilize ,
because in loiter the pre flight check tell that is not possible
without 3D fix .. then switch in loiter and try to take off. When i'm
taking off i check if the command on roll and pitch work well but it
don't work ... don't move the drone ... only throttle work if i re
switch to stabilize i re take the control on pitch and roll .
What could be the problem ? Are there some guys that sucessfully check
this release of firmware with Optical flow ?
Thanks in advance
Roberto

[Luca Angelo Micheletti]

Hi,
I have to add some other information about these tests that Roberto and I we did. It was impossible to arm: there was always the message preArm: check range finder. I put a look to the source code: it seems impossible that that function can return true. I had to disable this check to continue with the tests.
About the configuration of optical flow.... We follow Arducopter and Pixhawk wiki: we enabled logs and verified all values. We did first fly with EKF_GPS_TYPE = 0... The logs were OK. We changed EKF_GPS_TYPE to 3.... The first problem was the 3DFix of GPS while arming in loiter... We tried to arm in stabilize, switch to loiter and then take off the drone but there was not control on pitch and roll. Probably we have done something wrong! Do you have any idea about this behaviour? Why the preArm check want 3D Fix when I use optical flow.

Thanks a lot for your help

Luca

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luis Vale Gonçalves]

I believe that with Optical Flow Active you have to pick up the vehicle and "point" the sensors to a larger distance. It was like that with only the sonar attached because it was believed that with sonar there was also Optical Flow. It was changed to only do that "range check" only with Sonar + Optical Flow, but I might be wrong.

[Randy Mackay]

 

     Thanks very much for testing the optical flow.  We haven’t had a lot of users of it so it’s not too surprising that there are issues.  Personally I was thinking about giving it a try on the NAVIO+ board because we have a linux driver for it now as well.. but I digress.

 

    Yes, Luis is right.  You just need to pick-up the sensor to a height of between 50cm ~ 200cm if optical flow is enabled.  It’s a slightly controversial check but Paul said that while he was testing with the 3DR Solo people, they had lots of problems and it almost always came down to the lidar being setup incorrectly or not working for some other reason.

 

     Definitely dataflash logs would be good at this point too if you have them.

-Randy

[Roberto Navoni]

Hi Randy ,
we did some test today, Me and Luca check optical flow in different
condition , as suggest by another user we de activate pre flight
check , there are a lot of bug in pre flight check procedure before to
release it for standard user.
So we did some good flight and other with some big iusse. The main
problem that we saw is that the drone if take off and immediatly have
some drift normally don't fly well with optical flow if when take off
all work fine in first loiter normally the rest of flight is good ,
like a parrot :) So i think that before to release this function need
more debug analysis .
We are uploading a new video.
best
Roberto Navoni

2015-08-07 2:56 GMT+02:00 'Randy Mackay' via drones-discuss
<drones-...@googlegroups.com>:

[Randy Mackay]

Videos are great but to really understand what's going on we need dataflash logs. If possible please turn on the Log-while-disarmed logging as well.

-Randy

[Luca Angelo Micheletti]

Hi Randy,

today we did 3 different tests (all with LOG_BITMASK = 131071):
1. The drone moved a lot in this first test: I think it was because there was much grass moved from the propellers (is it possible?). We have a video (https://www.youtube.com/watch?v=uiD2B_fL93s) and a log file (4-OpticalFlow-Test1.BIN).
2: This test was fantastic. We changed the location. You can see the video of first part of the test (https://www.youtube.com/watch?v=HbAxfs5TUC0), the one of the second part of the test (https://www.youtube.com/watch?v=x6HsN9k0bLw) and finally the log file (5-OpticalFlow-Test2.BIN)
3: In the last test, the drone took off, began to drift and fell. You can see the video (https://www.youtube.com/watch?v=-vt3aYyaU0Q) and the log (6-OpticalFlow-Test3.BIN). Is it possible that it happened because we powered on the drone in Stabilize Mode, switched to Loiter Mode and then armed it?

Thanks again for your help. I hope this material can be useful for you!

Best Regards

Luca 

[Luca Angelo Micheletti]

Hi Randy,
we did some other tests yesterday... and we have some other video and logs for you...

https://www.youtube.com/watch?v=_cwSrUaG9BI
https://www.youtube.com/watch?v=LNQyKFpMZ2E
https://www.youtube.com/watch?v=5heqd0wJ_ho

We tried to take off the drone with different heading, from different clean or dirty place... but it seems there isn't any relationship between all these situations. If the drone take off correctly, all the flight continues well. Into our videos and logs you can see the drone taking off from the same place but with different behaviors already from takeoff.

However it seems that the behavior of the Optical Flow is good ... when we have a little more time we would like to test the maximum height that we can achieve with this system

Best Regards

Luca

Il giorno venerdì 7 agosto 2015 14:35:03 UTC+2, Randy Mackay ha scritto:

[Paul Riseborough]

A few pointers:

1) You will need to pick up the vehicle to waist height and place it down again so the system can verify the range finder is working and pass the arm checks

2) You should takeoff in LOITER and quickly climb to a metre for initial assessment

3) You won't get much visible angle change close to the ground because when operating in OF mode, the maximum velocity allowed in loiter is scaled with ground height to avoid the flow sensor saturating

4) The OF solution is vulnerable very close to the ground due to issues with focus so it relies on the Lidar to know when there is enough height to begin using the measurements.

I'll have a look at your data logs

[Roberto Navoni]

Hi Paul,
thanks for your suggestions and feedback
Tomorrow i'll check .... i think that the problem is the take off
because when i take off the drone my impression is that i haven't the
control of pitch and roll untill it arrive at a good altitude ... also
the stick of throttle is not clear how it work because you need to put
it in the center and after that start to climb up when raise the stick
up the middle ... if the take off is not correct .. It have the drift.
Best
Roberto

[Paul Riseborough]

I have just finished looking at the number 4 log and the problem was that between arming and taking off, the takeoff detection test triggered prematurely and enough time had lapsed for the EKF to reject the OF data and time-out. It then fell back to constant position mode so the entire flight was done without using the OF data. t is surprising to me that given the EKF filter status at that point in time that the system was allowed to remain in LOITER mode so we need to investigate why that happened.

• The EKF5.FIX and EKF5.FIY are the optical flow rate innovations and if they are flatlined, then you know that the EKF was not using OF data.
  
• EKF5.meaRng is the range finder input - looks good
  
• EKF4.SS is the bit masked EKF solution status. If bit 7 is true, then the EKF is operating in constant position mode and is not using the OF data. For correct OF operation, bit 3 will be true (relative position mode) and bit 7 will be false.
  

I will have a closer look at the log and work out what went wrong with the takeoff detection check. I suspect that your particular sequence of arming has exposed a bug in the check s there is nothing obvious in your data that looks unusual.

In the meantime if you arm in loiter mode and takeoff immediately, it should work.

-Paul

[Roberto Navoni]

Hi Paul ,
yes i agree with your conclusion. In some take off my process to reach
the middle of throttle was slow .. because i did the takeoff carefully
to understand what happen during the initialization of OF ..
Normally the Ing. point of view is different respect of standard user
... I'm happy to found a bug and help to improve the quality of OF :)
Tomorrow morning try to take off more fast but could be nice to patch
the problem so the OF will be fantastic option for our APM firmware :)
Thank you Paul
bye
Roberto

[Paul Riseborough]

I think I found it. The EKF uses two criteria to detect takeoff, one is range finder increasing above the arming value by 10cm, the other is detection of angular rate. In your case the copter vibrated on its undercarriage when the throttle is raised causing th takeoff detector to false trigger.  I will remove the angular rate test, because with the range finder pre-arm check it is unnecessary as we can trust the range finder to indicate the increase in height.

-Paul

[Roberto Navoni]

Great News,
thanks Paul
When the patch will be available we can test it for you and resend the log.
Best
Roberto

[Philip Rowse]

Thanks Paul, thats cool

Philip Rowse

Lead Systems Engineer 

3D Robotics Australia

+61-(0)4-2732-6366

website | facebook | instagram

[Randy Mackay]

I've added an issue to look into why the EKF failsafe didn't trigger.

          https://github.com/diydrones/ardupilot/issues/2686

-Randy

[Paul Riseborough]

Here it is:

https://github.com/priseborough/ardupilot/commit/600ac931db3228f090d110c1e26e4e2f6f7025ab

[Roberto Navoni]

@Randy @Paul ,
thanks for your support. Tomorrow and in the rest of the week i'll try
to do some test. Randy Paul do you think that is possible use
OF_Loiter instead of Loiter for use drone in loiter ? Because if i do
some test could be more simple to use a different mode instead to
change ekf from 0 to 3 and from 3 to 0 to switch between Gps and OF
... So the mode could be stable mode and it is usable by the standard
user . Could be necessary to switch to land re re take off or is
possible to switch dinamically between two mode ?
best
Roberto Navoni

[Roberto Navoni]

Hi Paul , Randy ,
today i did new test with the patch , but the problem still of
initialization still when you need to much time from arm condition and
arrive ad desidered altitude for activate the initialization of drone
. In this condition could be better force a land ... or manage in
other way this condition ..
Best
Roberto

[Luca Angelo Micheletti]

Hi Randy and Paul,

this is the log of last test and this (https://www.youtube.com/watch?v=oLRbSJzmVw4) is the video. The problem is when you arm the system and you wait a few seconds before take off. If you arm the system and take off immediately all works fine.

We did also a test about the maximum height at which the system can works fine: we reached about 7 meters.

Best Regards

Luca

[Paul Riseborough]

Looking at your logs I don't think you are using the PX4Flow sensor firmware recommended in step 2) in the Wiki: http://copter.ardupilot.com/wiki/common-optional-hardware/common-optical-flow-sensors-landingpage/common-px4flow-overview/

The default firmware does not operate well close to the ground when the lens is out of focus, so you should follow the link here and try with that firmware. i will have a look at your latest log and see if there is anything else that stands out.

[Reinis V.]

I've been experiencing similar problems with optical flow on latest ArduCopter, with the recommended px4flow firmware (KLT).

I've narrowed the problem down to velocity/position estimates going wild (because without fusing in flow data, the estimates are provided by integrated attitude data, so at takeoff, I've seen up to a few m/s velocity estimates).

I've been able to partially work it around by constraining state.velocity, state.vel1, state.vel2 and state.position to 0 until ap.land_complete goes false. 

This has led to reliable takeoffs, with a few caveats:

* If one tries to take off from uneven surface (e.g. ~10 degrees roll/pitch angles), the velocity estimate still gets large enough for flowTestRatio to exceed 1 and start ignoring flow, which leads to vehicle just continuing to fly in the direction of initial attitude.

* Filter really doesn't like the velocity/position being constrained to zero, but having non-zero attitude (bascially, attitude estimate goes nuts).

I'm going to try constraining attitude until optical flow is stable (state.quat.initialise()?) but I'm afraid it will cause the takeoff to happen without stabilization (as the attitude estimate will not be provided).

Paul, Randy- I really feel what I've tried is not the correct solution to this problem, as it could affect the stability of the filter in other cases- is there a better way to fix it?

[Leon]

Hi, @Paul
I tested the optical flow takeoff check with Copter 3.3-rc11 (branch: master). I followed this tutorial: http://copter.ardupilot.com/wiki/common-px4flow-overview/, I changed EKF_GPS_TYPE to 3, there was the message “Pre-arm: need 3D Fix” while arming in Loiter mode.  I checked my flight data flash log and found that the parameters: EKF5.FIX and EKF5.FIY are flatlined. I know that the EKF was not using OF data. But, how do I fix this problem? Maybe I have done something wrong….

Thanks a lot for your help~

-Leon

Paul Riseborough於 2015年8月10日星期一 UTC+8上午5時56分24秒寫道：

[Paul Riseborough]

The EKF won't start using the optical flow measurements until the copter  is armed. While disarmed you can check the OF group flowX,Y and bodyX,Y messages for the flow sensor operation and the EKF5 group meaRng message for correct range finder operation.

Your range finder seems to be dropping out on the ground and jumping to a value of 0.58 metres. The RNGFND_GNDCLEAR parameter should be set to the correct reading for your range finder when the copter is on the ground. That means that if the range finder drops out when on the ground, the EKF knows what the default range should be. otherwise the resulting height inconsistency can prevent it arming.

I haven't flown optical flow with recent software builds, so you might need to disable the GPS arming check to fly in loiter without GPS.

[John Lian]

Hello @Paul,

We purchased the Pulsedlight LIDAR-Lite V2, connected via PWM, to test the optical flow. We are using Copter 3.3 rc11. We can't seem to get any valid data in EKF5.meaRng when we were following the tutorial. 

The flash logs show this:

After looking at the logs, we checked to make sure that the rangefinder is operating properly:

What did we do wrong? How do we get EKF5.meaRng to recognize the data from the rangefinder?

Thanks,

John

[John Lian]

By the way, here's our parameters. 

[John Lian]

Ok @Paul sorry for bothering. It turns out that it was just an APM Planner issue - the EKF5.meaRng readings are good when read in Mission Planner.

From there we tried following the tutorial again. We changed EKF_GPS_TYPE to 3 and now have encountered the same issue as @Leon where we see “Pre-arm: need 3D Fix”.

We are using the LIDAR and our quad is fairly tall so on the ground we see values around 0.13-0.17m (accurate). We set that for RNGFND_GNDCLEAR parameter but it still doesn't work.

We will try flying with GPS arming check disabled soon when we get the time and space. I'll report back then.

[Mad Macks]

@Paul and @John

I share the same problem that John is facing.   I am unable to arm the craft in loiter as I get the same pe arm error, even though I have all checks disabled.    I am able however to arm in stabilize ascend to roughly 6-12 high then at that point i can switch to loiter and the OF and Lidar function perfectly.  Heres a quick video of one of my test. https://youtu.be/oWcUMRT1q2I

[Alejandro Hernández]

Hi everyone,

I'm trying to fly with PX4Flow and LidarLite (both connected by I2C). But I'm finding some troubles. I'm following the instructions of Senzai in this blogpost of DIYdrones[1] (That is some of the most complete diagnostic and set up information that I have seen on the PX4flow). Also I have checked the official documentation[2].

I have uploaded the firmware of the PX4Flow with the available in ardupilot website[3] with QGorundControl (Description : PX4Flow sensor firmware using Lucas-Kanade method for use with ArduPilot).

If we take a look to OF.bodyX and IMU.GryX. We can see that the behaviour of OF.bodyX is strange (It isn't continuous and only appear peaks) ¿Anyone have experimented this kind of behaviour? ¿How I can obtain better measurement from the optical flow?

I have compared my logs with the logs provides by Luca Angelo (these logs is what I expected)

Regards

[1] http://diydrones.com/forum/topics/optical-flow-discussion-thread?id=705844%3ATopic%3A2135599&page=2#comments

[2] http://copter.ardupilot.com/wiki/common-px4flow-overview/

[3] http://ardupilot.com/downloads/?did=118