Hi,
I noticed in mission planner under optional hardware there is an optical flow section.
Can ardurover support the pxflow sensor?
I did see this on the ardurover wiki.
http://ardupilot.org/rover/docs/common-optical-flow-sensors-landingpage.html
has this changed?
Esa,
Rover doesnāt currently support the optical flow sensor. It certainly could though, itās just a matter of adding a few includes into Rover.
Most rovers are too low to be able to use an optical flow sensor well I thinkā¦ but we have a change coming that will allow using an upward facing optical flow sensor (or actually it can face in any direction).
All add it to the to-do list. https://github.com/ArduPilot/ardupilot/issues/7420
Is there any more about actual support for PX4Flow in ArduRover? The documentation implies that itās there already, but it would obviously need a parameter to specify fixed distance or sensor for distance.
David,
Flow isnāt supported in Rover but wheel encoders are. Any reason youāre keen on the optical flow? Because the rover is so close to the ground, I donāt think itās going to work all that wellā¦ but Iām slightly new to the Rover area so happy to be corrected.
Any chance you could point out the documentation that implies flow works on Rover? Iād like to correct that implication on the wiki if possible.
I must have misread http://ardupilot.org/rover/docs/common-optical-flow-sensors-landingpage.html not seeing the part I didnāt want to see (that Rover is not among the supported platforms). No correction needed. I realize there is a lot of overlap in platform documentation. I also saw https://github.com/ArduPilot/ardupilot/issues/7420 and that encouraged me in this direction.
I was looking for location capability with finer resolution than GPS and not relying on wheel turns. Computer mice are pretty close to the surface and they seem to track nicely, so itās not obvious to me why a rover couldnāt have a flow device mounted close to the ground. Iāve seen at least one video of a rover using optical flow. They had a light shining on the ground to overcome ambient lighting variations.
David,
Ok good stuff. Well, if a developer steps forward Iām very happy to guide them through adding support for optical flow to Rover. Itās not particularly hard but my plate is quite full.
Hi, I have time and interest to go through this process. I think it should work for low speeds with the stock lens; e.g. with 16mm focal length lens mounted at 25cm from the ground, you can measure a maximum speed of 0.6 m/s. With a 4mm lens you can go up to 2.4m/s at the same height. With the Traxxas xmaxx RC car, 25cm seems about right.
Do you have any suggestions for where I should start?
Optical flow would be useful for rovers that operate off road in an environment where wheel slippage is significant. Encoders are nice, but if youāre on wet grass they might not accurately reflect vehicle translation.
This is a feature I would use if it were ever implemented. Like @juancamilog said below, I wouldnāt mind attempting to help if I can. If itās already implemented in copter the hard work is done I would imagine.
In terms of implementing optical flow in Rover, the best way to do it is to search for āoptflowā and see whatās done for Copter. We donāt actually need everything that copter does though. The important things that need to be added are:
I will try and take a look at it this weekend, thanks for the guidance Randy!
I started some work over here: https://github.com/juancamilog/ardupilot/commit/8a388b6ca732618232c8f1934993b594cc908e04
This compiles but Iām not sure it is working. On mission Planner, I see these messages:
EKF2 IMU1 is using optical flow
EKF2 IMU0 is using optical flow
EKF2 IMU1 tilt alignment complete
EKF2 IMU0 tilt alignment complete
PX4v2 004F002B 30345107 36353832
PX4: 8ca93fbd NuttX: 1472b16c
ArduRover V3.5.0-dev (8a388b6c)
EKF2 IMU1 initial yaw alignment complete
EKF2 IMU0 initial yaw alignment complete
GPS 1: detected as u-blox at 115200 baud
RCInput: decoding PX4IO_PPM
Ready to drive
Using QGround control, I can see that the sensor is measuring something
I also noticed that I only get optical flow messages if the vehicle is disarmed.
ā Juan Camilo
That looks good reallyā¦ it not reporting while armed must be something elseā¦ maybe the telemetry link is being flooded by some other messages? I donāt know why that would happen thoughā¦ If the Optical flow data is being written to the logs then the sensor is working.
The messages that the IMU is using the optical flow is also a very good sign.
I created an AP_RangeFinder_Fake backend which always reports the ground clearance as the distance measurement. Set it up using the RNGFND_TYPE, RNGFND_GNDCLEAR and RNGFND_ORIENT parameters. now weāre getting optical flow messages when the vehicle is armed! This is a temporary solution until I get a range sensor.
@juancamilog You are quick sir! You beat me too it, but I think you are doing a much better job than I could have.
Is the plan to have a parameter set equal to the ground clearance? Or do you envision using a PX4Flow with a rangefinder of some sort? Or both? Does a rangefinder provide a measurable increase in accuracy? (Edit: I am making the assumption the lens is pointing downward)
Iām getting ready to purchase a sensor to eventually help test the code but I want to make sure I get the right one.
Thank you for your work!
Juan,
Nicely done! You knowā¦ itās not a terrible long term solution eitherā¦ Iād have to check with some others including Tridge and Francisco to get their opinion ā¦
It should work both with a real range finder or the fake one. I was thinking of using the VL53L0X https://www.adafruit.com/product/3317, but here in Montreal the earliest I can get one is after Tuesday. Since I was a bit impatient, I thought the fake rangefinder would allow for quick testing, as a temporary solution. It might work well if your rover is deployed on a flat surface; e.g. indoors. If you want your vehicle to go off-road then it might be a better idea to use a real range finder.
Iāve updated the repo (https://github.com/ArduPilot/ardupilot/pull/9334/commits/e67f610b787fff68d7b9b0f46be5a8703a5004bc), so you should be able to test it. To use the fake range finder, youāll need to set RNGFND_TYPE to 21 (The new fake rangefinder type), RNGFND_ORIENT to 25 (Down) and RNGFND_GNDCLEAR to the approximate distance of the flow sensor to the ground when mounted on the rover.
Cheers!
Come to QuĆ©bec city, Iāve got a handfull 
I tend to agree with @rmackay9 , there is no real need to implement the rangefinder on a 2D platform , so I would call it a āāfixed rangeāā instead of āāfake rangefinderāā and have merged in master
Thanks for the suggestion! I 've refactored AP_RangeFinder_Fake as AP_FixedRange. Havenāt had time to test this more on the actual robot, still needs calibration.
It looks like weāll need to hardcode calibration parameters and build the px4flow sensor firmware to make sure the parameters are persistent: https://github.com/NVIDIA-Jetson/redtail/wiki/3DR-Iris-Setup#px4flow
Iāll let you know how the experiments go.
ā Juan
Would it be a good idea to try and merge changes from the PX4/Flow repo into the one used for ardupilot (https://github.com/priseborough/px4flow/tree/klt_flow)? There have been a bunch of updates on the main repo, and Iām particularly interested on this one: https://github.com/PX4/Flow/pull/86
Juan,
Perhapsā¦ I actually think that the px4flow sensorās days are numbered so iām not personally keen on putting the effort into bringing the firmware up-to-date. There are much more flexible, cheaper or more flexible options out there like:
