[Dprglist] Optical flow sensors - down the rabbit hole

Karim Virani pondersome64 at gmail.com
Wed Jul 1 18:35:52 PDT 2020

Hey Murray,

I kinda went down the rabbit hole with the optical tracking sensor you
shared in RBNO last night. It looked really promising and might still be -
I'm not sure.

So you've been experimenting with the Pimoroni optical flow sensor for

which in turn is based on the PMW3901 PixArt sensor:

Issues with this sensor are partly related to its intended usage - this is
optimized for drones and their typically greater distance from the ground.
Also this usage is not really odometry. It's more optimized for detecting
velocity rather than distance . Technically those should be convertible -
but that's in a perfect world independent of the kinds of error that might

You mentioned the possibility of switching the sensor a similar one from
the same manufacturer, the PAA5100JE-Q:

This one looks optimized for indoor floor driving robots like vacuum bots.
It's tuned to the kinds of surfaces we (DPRG) often see. Note that it has
some sister products that might work better on highly glossy floors (like
in the Perot), but they are a different form factor and have a
larger minimum distance.

You noted that this sensor might be an easy drop in replacement for the
existing Pimoroni carrier board and so asked Pimoroni to look into that. I
did a +1 vote on that and if anyone else is interested, add your vote here:

Not wanting to wait on a decision from Pimoroni, I looked for a carrier
board that could accommodate the LGA package and found this one:

But then I took a closer look at the datasheet for the PAA5:

and I noticed it needed a ground plane in the middle which that breakout
doesn't have. It also requires a minimal amount of external components to
work according to the reference schematic and that also is a reason the
Pimaroni option looks good if they choose to support it.

However it might not be a perfect fit for my team. At 45 inches per second
maximum tracking speed, it would handle most of the club's robots and most
FTC robots. But it wouldn't cover the speediest of FTC robots. Patrick's
team would likely be pushing that speed limit. And FRC robots would
definitely be too fast.

Deepening the rabbit hole, I found another sensor by PixArt -
the PMT9101DM-T2QU which is more closely related to optical mouse history
and I've actually used a variant of this one.

This part solves one of my concerns - it has a much greater detection
speed.  This is a motion tracker that's been optimized for industrial
applications like tracking paper passing through high speed copiers. So it
can handle much greater velocities and accelerations.

And then I found a paper on using that sensor to detect/control smart
hydraulic cylinders which did some performance analysis:

And this brings up some other related concerns. The PAA5 specs have this

Repeated Accuracy Error at Nominal Height: 3% to 10% (3% on carpet & 6% on
laminated wood)

Now what does that mean? It's really hard to say, but my initial reaction
is not great. That seems like a lot more error than we get with
free-wheeling odometry.

PixArt uses that Repeated Accuracy Error for most of their related
products, although they aren't necessarily specified in the same way. For
example the high speed PMT9101DM-T2QU claims:
Repeated Accuracy Error at Nominal Height ±0.25mm over 25mm
Which is 1%, so better. The improvement might be related to the much more
constrained range to surface detected. But 1% is still problematic.

Going back to the hydraulic motion paper linked above, it studies this
sensor specifically. I can also recommend that paper because it has a
pretty good general treatment of optical flow and optical mouse sensors.

It turns out that according to this paper, there is a problem with
measurement drift in these sensors. And it seems to be susceptible to
changes in direction. The paper goes on to explore a correction algorithm
that achieves good results, but that is dependent on placing a correction
marker in the surface being tracked and that can't be done when we are
tracking motion across an arbitrary and unknown surface.

One other concern for my team is that our hardware doesn't have SPI, so
we'd probably need to incorporate an I2C to SPI bridge.

I'm still interested to test these out. But I now have limited expectations
about the buildup of error in absolute distances travelled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20200701/77dad032/attachment.html>

More information about the DPRGlist mailing list