I’m thinking of trying the latest beta to see if the optical flow benefits are helpful to me.
I have a HereFlow and a Lightware LW20 (down facing) on my copter.
While the LW20 lidar has done a good job for terrain following, I’ve never noticed much (if any) benefit in position holding from my HereFlow.
I’ve done the wiki’s HereFlow calibration process - and when I have flights with enough roll data, I consider the Optical flow settings suggested in the Auto Analysis report.
In a recent test in tight quarters in my yard, it’s sometimes hard to believe that positioning precision is aided by optical flow.
In order to test the benefits of the optical flow benefits in the beta, I need some guidance in understanding the data to measure present optical flow performance - to make a comparison with the beta version.
I noticed the comment about an improvement in the beta regarding switching between GPS and Flow. I don’t know how to see if or when this switch occurs from the logs. Can someone tell me how?
Below is the Flow Quality graph from a recent test flight.
EKF bug fix to altitude used for optical flow (e.g. rangefinder altitude)
Lua script to automatically switch between GPS and optical flow (see here)
It sounds like you want to fuse both GPS and optical flow at the same time which is very do-able but I’d like to see the log file to ensure that the EK3_SRC2_VELXY has been set to 5 (Optical flow) because if this hasn’t been done then optical flow won’t be being used at all.
After this I think it would be good to verify that the vehicle flies well using only optical flow and ideally set it up so that you can manually switch between using GPS and optical flow using an auxiliary switch as I did in this video.
Once we’re sure that the optical flow position hold is working well I might ask you to send me another log (maybe with “replay” enabled) so we can evaluate how much of a difference using the optical flow is making as compared with just relying on the GPS. This would allow you to see for yourself the GPS vs optical flow position hold performance.
TBH, I’m also not sure how much of a difference it makes to fuse both GPS and optical flow at the same time. Certainly Paul Riseborough has done tests in the past and says it improves position hold but I have never verified this myself.
That’s what the lua script should do although it doesn’t directly check for GPS glitching it does have other thresholds that it tries to use to determine whether the GPS or optical flow should be used.
There is no mention of EK3_SRC2_VELXY on that page - so indeed, that parameter is set to “0” on my copter. Maybe optical flow has never been active on my copter.
I don’t recall seeing the link at the bottom to the page for calibration - if it was there at the time, my bad for missing it. I did the manual calibration where you roll the copter while holding it about 3 feet in the air. (a pain in the ass)
It appears I had a mis-understanding - I had understood that when I installed the HereFlow, ArduCopter would automatically add the optical flow input into determining it’s position.
My goal was to achieve greater lateral loiter stability. I wasn’t concerned about greater location precision - such as RTK - only that the copter stayed stationary - particularly at low altitude.
Using an AUX switch to change from GPS to Optical Flow positioning is OK for testing, but with a limited number of AUX switches, it’s not practical for operational use.
You mention Paul Riseborough’s tests with fusing GPS and optical flow. Is that an option available to us “regular” users? If so - that’s that option I’d like to use.
Ideally, if the copter were to be used in a location with poor GPS reception or HDOP, prioritizing optical flow would be convenient. But as we operators are pilots, not just button pushers - I can accept the responsibility of changing a parameter or two when the circumstances require switching to optical flow and discontinuing GPS for positioning. (like flying indoors - or really bad HDOP)
Let me work though the optical flow calibration wiki and get back to you with my results. If there are any tests or procedures you’d like me to conduct for your benefit, I’ll do my best to help out.
OK, I’ll improve the optical flow wiki setup pages to make it more clear that the calibration and setup is required and re-organise this setup page so that the “Regular Flight” section is at the top… maybe we will split the page in two.
The px4flow KLT firmware doesn’t correctly report the quality I’m afraid. I have only ever used the pre-built firmware so I would stick with that instead of trying to build the firmware yourself. I don’t think there’s much motivation in the core dev team to test or improve the px4flow sensor’s firmware… in fact within the AP team I think only Paul Riseborough ever looked at it. Personally I use the hereflow which is much smaller and works at least as well (perhaps slightly better) but there are other options too and they almost all use the pixart flow sensor.
This is exactly how it should work!!! Is it how it is implemented now?
Basicly flow should help gps to make it more precise and in case gps disappears flow takes control in all those modes where a gps is needed.
@rmackay9 is it how it works now? or there is need for the lua script to run? In case the lua script is needed i don’t see the necessity for it. As far as i am concerned flow should always be there to help and take over in case of necessity. Obviously a parameter could be set to use only gps, only flow or both as i described. I took a look at the wiki and is very confusing, basicly thats the reason i took off all flow from my copters at the moment.
Maybe on the wiki there should be a setup that 99% of people would be interested in:
Flow helps gps and in case gps fails or gets obstructed, flow flies your copter…
Yes, it is easy to setup GPS+optical flow to be used at the same time. A couple of posts up in this thread I put the parameter changes that are required for this but most of them are the defaults. The only parameter that you need to set if coming from a default setup is:
Set EK3_SRC2_VELXY = 5 (optical flow)
If you’re using both GPS + optical flow at the same time then there’s no need for a lua script… but the user needs to be careful because this doesn’t mean the vehicle can seamlessly move between GPS and Non-GPS environments using this configuration. The reason is that especially as the vehicle transitions to the Non-GPS environment the GPS quality will become very bad and it will send bad velocities into the EKF.
… so for outdoor use where you’re just looking to reduce horizontal movement close to the ground, adding an optical flow may help. For GPS<->Non-GPS transitions the lua script should be used to switch between GPS and optical flow.
I totally agree that we need to make this clearer on the wiki.
I have to say though that I also wonder if GPS+optical flow is actually better than just GPS. In my testing I don’t really notice a difference but my testing was not very rigorous.
Ok i understand now the part where flow helps gps. About lua script does it switch authomatically from gps to flow when gps is not usable and before it starts sending bad data?
Yes, that’s what the lua script tries to do. The user sets up some limits in the SCR_USERx parameters that specify a GPS speed accuracy threshold, a rangerfinder altitude threshold, an optical flow quality threshold and an optical innovation threshold.
If the the altitude is below the rangefinder threshold, quality is above the quality threshold and optical flow innovation is below the innovation threshold (lower is better) then it will tend to use the optical flow. If the GPS accuracy is below the GPS speed accuracy threshold (again lower is better) then it will tend to use the GPS.
I say, "tends to … " because it votes every 0.1 seconds in one direction or the other and it won’t switch until the cumulative votes have hit 10 in one direction or the other.
Sorry for jumping into this thread…Having followed your excellent optical flow wiki & videos I successfully added optical flow capability to one of my copter without any problems - it all worked perfectly straight away with impressive results!
I do have one question…currently when using optical flow (configured in another lane) in loiter mode the AP triggers an ‘on the spot’ emergency landing when exceeding the maximum altimeter range.
Is it possible for the AP to automatically switch to using the barometer for altitude estimation to avoid the immediate ‘on the spot’ emergency landing? I understand the altitude holding would be less accurate but I would really like to avoid the ‘on the spot emergency’ landing.
Perhaps, if not already possible, this may be worth adding as an option to the behaviour?
always use both GPS and optical flow. This can be done by leaving the EK3_SRC1_ parameters at their defaults (POSXY = 3/GPS, VELXY = 3/GPS, etc) and then setting EK3_SRC2_VELXY to 5 (optical flow) and EK3_SRC_OPTIONS = 1 (Fuse all velocities)
use the ahrs-source-gps-optflow.lua to switch between GPS and optical flow above a certain range finder altitude (like 15m). I wrote this script a while ago now and it hasn’t been used by many people yet. I think it will work but I should fixup the parameter names at least now that Lua scripting supports custom param names.
Many thanks for the info Randy - much appreciated!
I will use a slightly modified version of the LUA script option - that should work. I would like to have a solution for GPS denied environments as well as a solution where the optical flow assists GPS.
I remembered this morning that we’d spoken about the fact that the dataflash log “Auto Analysis” in Mission Planner has a report on Optical Flow.
I did this report for some of my most recent missions and compared the results. I have no idea what these results are telling me.
I’d done the manual calibration process - where you hold the copter at about eye level and tilt it back and forth. I haven’t tried any of the new calibration procedures yet.
I’m wondering if a good calibration is actually achievable.
I don’t think that the Auto Analysis is able to come up with good optical flow scaling values from a normal flight log. If it could then that the “Set” columns would be telling you what the two scalar values should be set to. The “1STD” columns are providing the “1st standard deviation” which is essentially a measurement of how good these scalars are (lower STD is better).
One more reason we need to update the auto analysis scripts…
I think you’ll get decent results from the inflight calibration.
I’m wondering how to tell if the values determined by the new calibration capability are actually “good” values.
It appears cross checking with Auto Analysis won’t give credible evaluation.
And if Auto Analysis were correct, I don’t think there’d be a need for doing the calibration routine.
For ease of use, I’d vote for putting all the programming effort into the Auto Analysis.
Auto analysis does require a flight with enough movement to do its determination - it reports no results when flights are inadequate. The new calibration routine doesn’t have this problem - it simply reports progress towards completion.
I think there’s room in the world for both - but their core logic should be the same so they both report the same results, And the priority should be placed on Auto Analysis.
