Servers by jDrones

Pxflow - ardurover support


(David Coleman) #5

I must have misread 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 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.

(rmackay9) #6


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.

(Juan Camilo Gamboa Higuera) #7

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?

(Drew Sandlin) #8

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.

(rmackay9) #9

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

(Drew Sandlin) #10

I will try and take a look at it this weekend, thanks for the guidance Randy!

(Juan Camilo Gamboa Higuera) #11

I started some work over here:

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

(rmackay9) #12

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.

(Juan Camilo Gamboa Higuera) #13

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.

(Drew Sandlin) #14

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

(rmackay9) #15


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 …

(Juan Camilo Gamboa Higuera) #16

It should work both with a real range finder or the fake one. I was thinking of using the VL53L0X, 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 (, 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.


(ppoirier) #17

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

(Juan Camilo Gamboa Higuera) #18

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:

I’ll let you know how the experiments go.

– Juan

(Juan Camilo Gamboa Higuera) #19

Would it be a good idea to try and merge changes from the PX4/Flow repo into the one used for ardupilot ( There have been a bunch of updates on the main repo, and I’m particularly interested on this one:

(rmackay9) #20


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:

(Saijin_Naib) #21

Are these “plug & play” with ArudCopter? I really like the PMW3901 from Tindie, and am interested in possibly fitting it to my Solo.

(ppoirier) #22

If weight is an issue, that could be an alternative, but the PX4Flow is a much better option than pwm3901 for a 3D vehicle. The integration with the EKF is excellent and quite optimal, the integrated IMU and the possibility to use different type of lens offers a lot of flexibility

(rmackay9) #23


As far as I know nobody has integrated the pmw3901 with ardupilot except on the skyrocket vehicles which are all manufactured in a factory. It should work but I can’t make any promises.

@ppoirier, I’m not sure it matters which sensor is used actually. I don’t think the PX4Flow sensor makes use of the integrated IMU does it? I suspect you know better though…

(Saijin_Naib) #24

Thanks for the info, guys.

I may try just to see if it helps at all at lower altitudes.