Pi wars week 2: encoders and magnetometers
8th Oct 2018
It’s been a productive week for the Tauradigm team, we’ve tested a prototype projectile launcher, researched sensors for odometry, mapped out the system architecture, evaluated a magnetometer board and order some of the key components.
Projectile Launcher
First the projectile launcher. Since the concept design (posted last week) is quite similar to Hitchin’s old skittles ball flinger, I thought it was worthwhile to just use that for a test, to check it was feasible to use with the soft juggling balls. I 3d printed a holder to mount the flywheels closer together, so they’d grip the balls:


modified ball flinger and juggling ball. notice the scuff marks on the ball from the tyres
The result is just about ok. It could do with the balls having a bit more energy, so they fly rather than bounce towards the targets. I’m not sure if its because the flywheel tyres are soft, as well as the balls, so they’e not getting much grip, or because the flywheels are too far apart, or because there’s not enough energy stored in the flywheels.
Still, a promising result and worth further development, since the balls knocked over the books and there’s no way the elastic bands from last year would have managed that.
Odometry sensors
Odometry is the fancy word for sensors that tell you how far you’ve traveled. The classic example is wheel (or shaft) encoders where markers on the wheels or motors are counted, to allow the travel distance to be estimated (its an estimate as the wheels may slip). There are now also optical flow based sensors, where a series of images are taken, key reference points identified in each frame, and the travel distance worked out from there. This can eliminate the wheel slip error, but introduces other potential errors such as when when the camera to ground distance varies, the perceived speed changes.
As mentioned previously, we ideally want an encoder that doesn’t interfere with our magentometer (no long range magnetic fields), is fast (better than 100Hz), precise (better than 1mm resolution when used on a 50mm wheel, so more than 100counts per rev) and isn’t sensitive to dirt, contamination and sunlight.
Shaft encoders are split into a few variants:
- optical transmissive (slotted light gates, with the beam broken by a slotted wheel)
- The slotted wheels can have very fine spokes, so potentially hundreds of counts per rev.
- No magnets, very fast (khz), precise, but may need covers to protect them from sunlight and dirt.
- There are some very cheap ones on ebay at the moment: https://www.ebay.co.uk/itm/Photoelectric-Speed-Sensor-Encoder-Coded-Disc-code-wheel-for-Freescale-car/253111107514 that look promising, so we’re getting a pair for testing. the sensor is a little large and may make our wheels stick out a little too far, but there’s no actual datasheet available, so we’ll have to see when they turn up.
- optical reflective (either a slotted wheel that selectively reflects the signal, or a disk with coloured stripes that selectively reflect)
- these tend to be fewerless counts per rev (up to 30) but are otherwise similar to the above optical encoders
- the ‘miniQ’ encoder is fairly cheap: https://www.robotshop.com/uk/miniq-robot-chassis-encoder.html and appears to be much like the discontinued Pololu wheel coder: https://www.pololu.com/product/1217 that only had 48 counts per wheel rev.
- the motor mount version looks more promising (~£9, https://shop.pimoroni.com/products/optical-encoder-pair-kit-for-micro-metal-gearmotors-3-3v) as that’s 20 counts per motor rev x 20:1 gear ratio = 400 counts per wheel rev, but would require new motors purchasing with rear shafts (£5 for some approximately equivalent motors, from Pimoroni: https://shop.pimoroni.com/products/micro-metal-gearmotor-extended-back-shaft?variant=32587847050)
- multipole magnetic, single count per pole
- all magnetic sensors might interfere with the magnetometer. those with weaker and shorter pole length magnets may be better, but they will also be more sensitive to alignment. the magnetic sensors should be most tolerant of dirt and sunlight.
- we could potentially mount these 20 counts per rev encoders https://www.robotshop.com/uk/magnetic-encoder-pair-kit-20d-mm-metalgearmotors-20-cpr-27-18v.html to our output shafts, but that wouldn’t give enough resolution. higher pole count magnets may be available, but they would be very sensitive to alignment since the poles would be less than a millimeter apart, and they seem to be expensive (>£30 each).
- multipole magnetic with multiple counts per pole (uses some sort of interpolation)
- cheap, fast, very precise (microns!) and could be used with the above magnets, or with a multipole ring magnet: https://www.mouser.co.uk/ProductDetail/ams/AS5311-ATST-500?qs=sGAEpiMZZMuI1aKsGLfKZGW%252bAokkxunj7LqBSs9mzow%3d
- the chips seem to be rare but evaluation boards are available.
- analogue magnetic (absolute)
- cheap, fast, precise, but need to be on axis (so on the outside of the wheel, and therefore sensitive to knocks): https://uk.farnell.com/broadcom-limited/aeat-6600-t16/encoder-magnetic-ic-16-bit-program/dp/2213639?MER=bn_level5_4NP_LastViewed_1.
- no breakout boards are available, so they also need us to make a pcb with surface mount soldering.
Optical flow
optical flow solutions fit into two categories: general purpose cameras with specialist software analysis, and dedicated hardware based solutions, often based on optical mice. The mouse chips tend to be cheaper and faster.
- openmv https://openmv.io/
- ~£50, 40fps
- closest focus distance not known, but Rob already has one so we’re going to do some tests
- pi camera + opencv
- from our previous experience with openc cv, we’re fairly sure this will work but will be at a low fps (<30) and will tie up the pi
- px4flow https://www.ebay.co.uk/itm/PX4FLOW-V1-3-1-Optical-Flow-Sensor-Smart-Camera-for-PX4-PIX-Flight-Control/131990574867?
- ~£40 ~ 250fps,
- minimum focus 0.4m may be able to replace the lens.
- pmw3901 https://www.tindie.com/products/onehorse/pmw3901-optical-flow-sensor/
- ~£30, 100hz
- minimum focus distance 80mm, no lens
- adns3080 https://www.ebay.co.uk/itm/Optical-Flow-Sensor-APM2-5-improve-position-hold-accuracy-Multicopter-ADNS-3080/192060338574?
- £7, 1500 – 6400 fps!
- minimum focus unknown but lens can be changed. cheap enough to try. The chip is also available without a replaceable lens, but the focus distance is then only a few millimeters and so too close to the ground to be practical for us.
so lots of options available, none ideal. We’re going to start with the cheapest and see what we learn.
System Architecture
For most challenges, we’re aiming to use map based navigation, and rely on ‘external’ sensors as little as possible (after the issues with light interference last year). To do this we’re planning to have a microcontroller very rapidly reading simple sensors like the IMU (including the magnetometer) and encoders to keeps track of where it thinks it has traveled and adjust the motors accordingly, aiming for a given waypoint, whilst keeping the pi up to date with what its doing and where it thinks it is.
The Pi will keep track of the location on a representative map, use key features to update the perceived location on the map and give the microcontroller new waypoints to head for. Localisation (figuring out where we are on the map) and route planning will be separate modules. See this page: https://atsushisakai.github.io/PythonRobotics/ for a collection of algorithms written in python that achieve this, along with animations representing each one’s approach. Our Pi will use ToF sensors and image processing to detect obstacles and use them as inputs for correcting the perceived location.
Magnetometer Evaluation
Since we already had a gy-271 magnetometer (HCM5883L breakout board), we thought it was worth doing a few tests to see if the magnetic field of the motors would interfere with the results.






The HCM5883L is a 3axis magnetometer, so doesn’t know its orientation to gravity or its turn rate like an accelerometer or gyroscope does, but by measuring the local magnetic field the results can be used to calculate the current orientation.
We first did a bench top test with a single motor and the board. we found that at about 150mm distance, the motors could cause a +/-2degree heading error. At 100mm it was +/-20degrees and at 50mm it caused more than 45degrees error. A few people on twitter suggested using materials with a high magnetic permeability as shielding for the motors. We managed to borrow some flexible magnetic keeper material (like Giron?), so we tried that:


Interestingly, in most orientations this gave no improvement, and in some orientations it was worse than no shielding. We think the material may have been concentrating the motors magnetic field into a better magnetic shape or directing more towards the magnetometer, or maybe the earths field was also affected by the material. We couldn’t entirely engulf the motor as we need the power wires to exit one end and the gearbox output shaft to exit the other. If anyone can suggest a more suitable material or arrangement, please let us know in the comments. Good magnetic shielding materials seem to be very specialist and expensive, and will likely add more weight than a plastic sensor tower, so for now we’re going with that.


Here you can see we’ve mounted a wooden stick to the front of our Tiny test chassis. Since the explorer phat doesn’t have pass through headers, we initially used a PiFace solderless expansion shim to breakout the GPIO pins, but we found some of the pins weren’t getting a connection, so had to revert to using jumpers to wire everything up (explorer phat floating in the air on wires, instead of sitting on the pi). After a bit of calibration, we got the Tiny to drive towards North fairly successfully:
From this test, its clear we need other sensors to help us figure out how far off course each little deviation takes us, so we don’t just turn back to the correct heading (parallel to the original path but offset), but we can turn back onto the desired path. We also need to find a better calibration routine, the few libraries we found still left some errors, North was ok but South was closer to South by South East. Here’s an example of one of the early calibration test results:


This is after some scaling and conversion, so the units are a little meaningless, but it shows the magnetic field strength in X and Y as the sensor was rotated. Since the earth’s field is constant, this should result in all the points being an equal distance from the origin, clearly this is offset to the right and downwards. The scaling looks ok as both axis vary by the same amount. After we changed the offsets we got much better results.
Parts are arriving
We’ve started ordering the parts we’re confident we will need, like a Pi, Pi camera and motor controllers:


So lots of progress. Hopefully next week we’ll evaluate a few more sensors and develop the Tiny test bed further.
Comments are closed.