Showing posts with label OpenCV. Show all posts
Showing posts with label OpenCV. Show all posts

Friday, December 17, 2021

Reporting from the cabin 1

We had another show and tell update meeting to report progress and lots came out of this, so much so that we have two blog posts to report it all, otherwise it gets very long and boring! 

First off is the new vision system. We had originally been working with a borrowed StereoPi system but our chassis master wanted better performance and started work with OpenCV on the new Raspbery Pi Zero 2, the technical details recounted in our last blog post. Here are a couple of pictures of the new camera solution.



Two Pi Zero 2's with two cameras, they've been setup at 65mm separation to facilitate usage with VR if we want to go down that route at sometime. Next up is time synchronisation and distance measurement based on the stereo image.

On a more prosaic subject, we looked at some more cardboard models of trees and sheep.


It makes for a very useful exercise to actually build the challenge props and look at them instead of theorising online, and so we had some cardboard sheep made up which we pushed around, knocked over picked up etc to see how they could be moved around. Similarly, we looked at the 'wolf' pieces and what they would be like to operate around, how easy to move or pick up.

This led to the decision to use balsawood to construct accurate 'sheep' to which we will add separate decoration in the future.


It is a simple thing but just getting it right will make the challenge easier to design for and prototype.

The 'apples' on the tree had already been designed, they're polystyrene balls, but a bit of thought for attachment (and detachment) was needed. We're attaching via magnets, which while apparently straightforward threw up a set of issues. First off, they have to be strong enough to hold the apple easily, this also helps with setup between runs so that attaching apples is easy.


Secondly, they have to be detachable, obvious but the more attachable it is, the less detachable it becomes!!! Silly observation perhaps, but there is definitely a balance to be found, we did find with some quite small magnets that the cardboard tree was easily pulled over, and when the apple came free, sprung back dislodging other apples. A cardboard tree isn't necessarily the best subject so a thin MDF one will be made for the next tests.

The attachment fitting for the chassis had been decided upon at the last meeting, and a trial plate made to test it. Unfortunately, the measurements for this were off and a second had to be made.


The main chassis fixings are on a 80mm grid for M4 bolts, with the outside dimensions 100mm. Onto this are moulded four lugs to fit the attachment securely, together with four raised supports for a PCB (dimensioned for a .254mm pcb matrix board) to be fitted.


This is the mounting fitted to the chassis. Not the most exciting item but essential.

That's enough for this entry, see the second blog entry for what else we got up to.





Wednesday, December 15, 2021

An OpenCV story

 Our chassis builder was determined to get OpenCV working on the latest Raspberry Pi platform for our entry, but it wasn't as straight forward as a quick download...................

Installing OpenCV on Raspberry Pi Zero 2 W

A tale with a moral

I have been interested in using OpenCV for years, but the driving force of need was never strong enough to overcome the obstacles. For example, my bomb disposal robot needed to detect the bomb. I scoured the Internet for instruction on installing OpenCV, but in the time it took to try and fail a few times I was able to implement Canny edge detection myself, and it worked fine for that purpose.

Then came Pi Wars 2022. Suddenly the goalposts had moved. Whereas the bomb disposal robot, which moved slowly in any case, was happy with two detections a second, I reckoned that our Pi Wars 2022 robot would need at least twenty, and preferably forty. So, back to the Internet.

If you type “install opencv on raspberry pi” into Google, you get 839,000 results, and I'm here to tell you that the most common single category is someone who has read how to do it and is passing it on without actually trying it themselves. Why do they do it? It just makes more crud to wade through. The next category is people who have tried it and got it to work on a very specific configuration, but don't explain fully what that configuration was, so you can't tell if it's applicable. One common thread is that a full install from scratch can take days and is fraught with peril. I asked on Discord for a prepared disk image without success. In total, over time, looking for shortcuts, I probably spent several days not installing OpenCV

Eventually I gave up on shortcuts, bit the bullet, and found a recipe for doing it the hard way. https://pimylifeup.com/raspberry-pi-opencv/ It was marked “beginner” which turned out to be a bit optimistic, but basically it worked!

A few prerequisites may be missing, so I added the following:

sudo apt-get install libatlas-base-dev

sudo apt-get install libjasper-dev

sudo apt-get install libqtgui4

sudo apt-get install libqt4-test

sudo apt-get install libgtk2.0-dev

sudo apt-get install pkg-config

sudo apt install libopenblas-base

sudo apt install libopenblas-dev

sudo apt install liblapacke-dev

If they are already there, running the install will do no harm.

Anyway: I now have OpenCV working on a variety of Pis in the sense that all the facilities in there that I think I need are present. I have made the disk images available on Google Drive if anyone wants to save effort, but I would encourage people to do it themselves.

Moral: sometimes the hard way is the best way.

Colin Walls
05/Dec/2021

 

P.S. The Pi Camera

Anyone used to SLRs will find the Pi camera hard to understand, particularly as it is on the end of a long chain of hardware and software, all trying to be helpful, but obscuring what is really happening, so …

There is no diaphragm, so you can't adjust the F stop. 'ISO' affects analogue gain and has no effect on raw sensor sensitivity. The focus is factory set (supposedly to 2m - infinity) and glued into place. There is no shutter, so light is hitting the sensor at all times. The sequence of zeroing, waiting, and reading pixel rows is roughly equivalent to a rolling shutter though, and the waiting period is roughly equivalent to shutter speed.

It is a video camera, there are no stills in the conventional sense. When you 'capture' an image what is really happening is that you get given the last video frame that the camera happened to produce. This means that you can't synchronise two cameras by 'capturing' an image at the same instant. This is why frame rate is crucial, because (assuming a 30fps rate, for example) any frame could be up to 1/30 second old when you get it, and the two cameras could be up to 1/30 second different in time of capture.

One thing common to nearly all digital cameras is that each pixel captures only one colour, so the true resolution is ¼ what you think it is, as other values are interpolated. This means that the ¼ 'maximum resolution' resolution has the special quality of matching the natural binning of the Bayer quartets in the sensor and involves a lot less processing. For the Pi camera V1 this 'sweet spot' is 1296 x 972. For the V2 it is 1640 x 1232

If you want to know more, read

https://picamera.readthedocs.io/en/release-1.13/fov.html