1

I'm looking at making a pretty cheap and easy odometer, eventually for an electric car or similar vehicle.

My idea is to implement a big computer mouse, and track the speed with that: a computer mouse takes photos of the surface it is on, and finds the difference between sequential images in both the X and Y directions.

What I am wanting to do is to attach a downwards-facing camera; something like this, to the bottom of the vehicle, and use an Arduino Nano to do the image processing to achieve a result similar to a computer mouse.

I was wondering whether anyone knows of an libraries/documentation on anything similar, or if anyone has any pointers on reasons why this would not work, or ways it would work.

Thanks all.

Improve this question
6
  • Neat idea! One potential problem that occurs to me is the lens getting dirty. You might also need a light for it to work at night.
    – dlu
    Commented Jan 12, 2016 at 4:59
  • Mouse chips are ASICs specifically designed for image processing. Use an encoder instead.
    – Ignacio Vazquez-Abrams
    Commented Jan 12, 2016 at 5:10
  • Like @jogco pointed out, you will have very little computational power. With that camera you will have to use a clock at 24MHz to read the data; this means at least a 100MHz uC. So forget the arduinos... Maybe you will manage to do that with higher power uC (for instance ST nucleo boards), but then you'll have to face another problem: resolution. An electric car moving at 7.2 km/h (human speed) travels 2m in 1s. The frame rate is at most 30fps, which means that the car moves 7cm every frame. This means that the camera should be at least at 10cm from the ground to be able to see some common
    – frarugi87
    Commented Jan 12, 2016 at 10:51
  • points between two frames. Since, however, it'll be very difficult to compare them, I think that at most you should allow for half an image of difference. This means that the camera should be at least at 20-25cm from the ground. And if the car is faster than humans, well, just give up. The easiest solution is to use an encoder on a shaft (for instance on the wheels one). I suggest an optical encoder because they are easier to assemble, but dirt can lower their performances, If dirt can be an issue use a magnetic one (or just magnet + reed relay)
    – frarugi87
    Commented Jan 12, 2016 at 10:53
  • @frarugi87 Thanks for that analysis, it definitely puts it in perspective! I can't rationally explain why, but I am trying to avoid shaft encoding. I am wondering about a small array of photoresistors, and simply multiplex them, so I can have a significantly faster read time, and just look for patterns.
    – Lui
    Commented Jan 12, 2016 at 22:04

1 Answer 1

Reset to default
1

Whooa, wait a minute. This sounds way too complicated, and my guess is that a Nano would be seriously underpowered.

If you really want to do all that work, you probably would need to step up your processing power. I suggest that you do some calculations on that, the number of pixels per second that should be compared.

Also factor in the time it takes to capture the image, the device you suggested is probably not fast enough. My guess is that by the time you can take next picture of the surface, you don't have any part of the image to compare with. According to wikipedia, a modern mouse has a 18 by 18 pixel sensor, and we're not talking a lot of (surface) speed here.

But there's a simpler solution; mount a magnet to one of the wheels (or axle) and a reed switch so that it is actuated as the magnet sweeps by. Then use the Nano (or a Trinket, no need for power here) to count the pulses from the reed switch. Do your math; (circumference of wheel) * (pulses per time unit). Convert to suitable format.

Voila; speed! :-)

This method was used to get accurate speed for deadreckoning, before GPS was really usable on land.. OMG, I'm old.

Possible problems areas - dirt, debouncing the switch, timing of arduino. But these sound simple in comparison.

Improve this answer
3
  • I totally agreed with this until you wrote that "need RTC" sentence.. An RTC? Why? RTCs are good at keeping time when the device is off, not to measure small time gaps (usually they have a 1s granularity). Crystals' precision is really enough for this project. What really lacks is the computational power to analyse the image in few milliseconds
    – frarugi87
    Commented Jan 12, 2016 at 10:43
  • Sure, then we can straighten out that question mark, and move it: !(need RTC). I was just throwing up possible areas to investigate.
    – jogco
    Commented Jan 12, 2016 at 11:07
  • Thanks Jogco, I wasn't totally sure about feasibility. I guess for speed accuracy there is some relationship with the field of view and the speed at which each image is processed. I have been looking for a significantly lower resolution camera, but am unable to find it. I wonder if I would be able to use a small (~10x10?) array of photoresistors and multiplex through them. This would need some form of light source to go with it, too.
    – Lui
    Commented Jan 12, 2016 at 22:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.