Reporting from the cabin 2

 

The meeting was an opportunity to put some plans and dates in place, so we know what dates we need to get things working by, ready for testing, and of course ready for videoing.

1. Finish research and agree approach by end of January

2. Complete robot component design by end of February

3. Complete robot construction by end of May

4. Complete testing and ready for video for end of June.

Seems plenty of time but then we all have other projects we're working on.

Having made some sheep, we played around with how we could gather them in and move them about, mainly with a few bits of wood and patting the cardboard about, and found we could get quite a lot done that way. Scaling this up to a practical robot attachment we got an idea we could make and test.

This is very much in keeping with what we can make so prototypes will be constructed to try out for next time.

In keeping with the Shepherds Pi challenge, we've also acquired a whistle and microphone for issuing commands to 'rover', so it's likely a fair bit of annoyance will be caused with loud whistles for testing.

And just to keep the theme going, a shepherds crook which might form part of a gate opener and sheep prodder when we have a better idea of what is needed there.

In a previous blog, we had pictures of the cattle feeding hoppers in design and now they have become reality, though still in need of a connecting bracket to the mounting plate. 

We still need to make a funnel to direct the feed sideways to the trough, but this part is well underway for having it's first solution. A second solution is not out of the question if it's better. Quite obviously we need a cable management solution to!

That's it for now,  a break until the new year though I'm sure we'll all have designed or made something in between, and videos of mass hopper emptying as well sheep herders to look forward to. We'll stop using the pretty yellow and green plastic as well, looks too good for prototypes so back to more boring colours, we'll bring them out again for final construction.

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.

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

Always something new

 While we're all busy with different things, somehow we get new ideas for PiWars challenges. So we have a new Hungry Cattle hopper design, this time both a measure, and also a funnel to direct the feed to the trough.

This design is to have a single hopper dispensing a measured amount of feed only into the trough. The main hopper is 122 x 100 x 104mm and the cylinder, which can rotate through 360 degrees, is 62 x 100mm long.  

In addition to considering a new hopper, there's also the idea of a side funnel to direct the feed independent of the hopper position. 

With this addition, the current chassis can drive up alongside the trough, dispense the feed, and then drive on saving time. Using the central front hopper only, the chassis has to drive up to the trough, dispense the feed, and then manoeuvre away from the trough, all of which is extra navigation.

Thinking of a decoration for the arena, instead of just plain cardboard, or MDF, a colour scheme. 

This looks a bit more field like, as well as having the useful 250mm grid lines for laying out the challenges. Not sure about having muddy pools yet!

When it comes to thinking about a challenge, we can be very analytical, so here are a few diagrams ahead of our full apple picker design.

This is a chassis and attachment volume model showing the extents that a any given design can occupy.

Applying this to the apple tree, we can view the approach distances and develop a strategy.

From this we can then design the apple picker to fit the strategy, QED :) 

We did lots of clever software work as well, write up on that next time.