Pxflow - ardurover support


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.

has this changed?


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

1 Like

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.


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.

1 Like


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?

1 Like

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:

  1. call to optflow.init()
  2. call to optflow.update()
  3. send optical flow data to the GCS (so the user can see it’s working)
  4. dataflash logging of the optical data so that we can do calibration of the sensor (see Log.cpp)
  5. call to ahrs.set_optflow() so that the ahrs/ekf will use the optical flow sensor

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

The quality is constant at 255. For flow_x I get nan, and for flow_y I get 0. So I’m not sure this is working.

I also noticed that I only get optical flow messages if the vehicle is disarmed.

– Juan Camilo

1 Like

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.

1 Like

@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!


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.


Come to Québec city, I’ve got a handfull :wink:
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

1 Like

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


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:

1 Like