In early May it became clear that our attachment for Shepherds Pi wouldn’t work because the combined length of the robot and attachment was too much to permit a turn within the delivery pen. So, here is the new version:
As you can see, this version can lift the sheep completely above the body of the robot; thereby not increasing the overall length of the machine. In this configuration the robot is (just) able to turn within the pen.
This version has the added advantages that it can place a sheep over the fence of the pen, and it lifts the sheep out of the view of the camera. However, it can only lift a sheep from the side (version 1 could lift from the side or from end on).
We did some experiments with the new lift, and it works well.
There’s a lot to do to get this game working though:
For now, the video guidance system aligns on the “sky” around the sheep. However, there’s more blue around the head end of the sheep graphic and this pulls the centroid of the colour away from the cuboid centre. Sometimes this causes a rather “lop-sided” lift of a sheep, although the lift still doesn’t usually drop the sheep.
The bigger problem is that the arena is too crowded for our control system. In most games the rather vague nature of our dead reckoning system can be countered by the camera and ToF sensor. But in Shepherds Pi there is need for more manoeuvres between visual guidance opportunities and this usually results in the robot displacing play pieces inadvertently.
We’ve decided to stop further work on this game for the time being. We will prioritise the other games and videos, then use what time we have left to have another go later.
There’s been some progress this week on Nature’s Bounty. The Apple picker has been printed and assembled, and the game play code has been written.
After some (read “a lot of”) adjustments we managed to get a video of the robot picking 24 (of a possible 36) apples within the allowed 5 minutes.
There’s still work to do though:
Sometimes the apple picker knocks some of the apples to the floor, other times an apple remains on the tree. We are going to try further adjustment to the design of the “fork” to make things more reliable.
The number of apples picked isn’t all that clear on the video. I think we will unload the apples into a container so that they can easily be seen and counted by the judges on future videos.
Finally we will create a second set of apples (i.e. glue washers to ping-pong balls). As with Feed the Cattle, the manual preparation of the game is a big proportion of the entire length of the video. You need the mindset of an F1 pit crew for PiWars 2022!
As you know (hopefully), we have made a big effort with the aesthetic aspects of our robot this year. However, we have also tried to make our arena and game pieces look the part too. Here are some details…
There’s a slightly cartoon look to PJD, so we have carried that through into the arena decorations. We downloaded some cartoon tree images then created landscape images for the back two walls of the arena. Exeter FabLab has a large format printer that was able to print the images 300mm high and 1,500mm long.
Simon, who is more artistic than the other members of the team, painted the Nature’s Bounty tree for us:
We decided to make a “net” to make the decorate the sheep cuboids. To achieve this, we created a 3D model of a cartoon sheep in Fusion 360 then took an image from each direction. These were stitched together with some sky and grass and printed. The sheep cuboids are 3D printed in white PLA, then the paper nets were glued on with PVA.
The wolves were just a straight download from the internet. Again, the standee structures were printed in PLA and the image attached with PVA.
Feed the Cattle
Some aged, cartoonish planks were modelled in Fusion 360 then constructed into a face of the correct dimensions for the troughs. The same face was printed in blue PLA for each face of the trough. A red band was printed in PLA for the half-full line, then the whole lot glued together.
Hopefully we’ve made the game pieces look nice, now all we need to do is get the games working properly!
If you follow this blog, then you’ll know that there have been two designs for the Feed the Cattle mechanism; a hopper with doors and one based on an Archimedes’ screw.
Well, now there’s a third (and can I say final?) version, which has been inspired by the work of a couple of other teams from the competition.
Mk3 uses a rotating drum containing three individual hoppers as used by the East Devon PiRates (https://eastdevonpirates.blogspot.com/). The flow of rice is controlled by a sliding mechanism which is how I think M0o+ (https://blog.usedbytes.com/tags/m0o+/) do theirs. My design is a mixture of the two; the hopper rotates so that the bottom of the hopper aligns with a hole leading to the pipes. So, one servo presents a new hopper and in doing so opens the flow of rice.
I decided on a re-design for two reasons:
The Archimedes system was a little slow, taking more than 10 seconds to make a delivery.
Mk3 makes a delivery in around 3 seconds.
But more importantly, I didn’t have confidence in the amount of rice being delivered. It appeared that I would have to time the delivery differently for the three different troughs. I could imagine having to make lots of videos to get nine perfect deliveries in a row. And if I lacked confidence then so might the judges.
With Mk3 it is easy to be sure how much rice has been delivered. So long as all (or at least most) of the rice goes in the trough then the perfect amount has been delivered because each hopper holds the right amount of rice plus 20%.
The design uses two down pipes to direct the flow of rice to the trough. This is so that PJD’s radiator grille mounted camera can still get a clear view of the trough (although the last bit of the drive is blinded by the bottom chutes).
In operation PJD deliberately crashes into the troughs so that two front mounted prongs can align the trough with the robot before the delivery takes place; this means that diagonal approaches to the troughs still work. As delivery takes place the robot turns the hopper back and forth through about 10o to make sure the rice doesn’t stop flowing.
During the design process I wanted to measure the volume of rice held in each hopper. But I couldn’t see how to get Fusion 360 to tell me the volume of a void. Two minutes on the internet provided the answer; create a solid then use the hopper as a cutting tool to shape the new solid to the shape of the void (and hence the rice it could contain). Fusion will then tell you the volume of this new body. I could then extrude the top of the design until the volume was exactly 300,000mm3 (this being 20% more than the volume required to half fill a trough). The picture below shows the shape of the rice held within each of the three hoppers.
This system works well and an initial video is “in the bag”. All we need to do now is make a new video where the human elements of the team don’t dilly-dally quite so much!
The good news is that my test on an Archimedes’ screw-based cattle feed delivery system went well. I’m now printing the remaining parts (a hopper and a chute) to complete the build. (Actually, that would be half a build; I plan to use two of them.)
Furthermore, it seems that it should be possible to deliver a measured quantity of feed based on the motor run time. It may not be as quick as some of the other systems I’ve seen, but I like the idea of an Archimedes’ screw.
Now the not good news…
The bad news is that the Sheep-pen-ator is not fit for purpose. My plan had been to drive into the pen then have the robot make a right-angle turn in order to tuck the sheep into the corners of the pen. However, the picture shows that it will not be possible to make the turn as the robot will still be in the gateway.
It feels late in the competition for such a fundamental problem.
Unfortunately, it doesn’t work. The right-angle drive shown in the highlighted circle (which is made of Lego parts) is used to grip the top of the sheep. However, the shaft that carries the drive from the servo flexes when too much torque is applied. This results in the gears jumping and the mechanism loses synchronisation. The system is unable to apply enough grip to lift the sheep.
I have reworked the design so that the shaft is supported between the servo drive gear and the right-angle drive. While I was at it, I added a mid-support for the shaft that holds the jaws of the grip too.
I designed this hopper for the Hungry Cattle game.
The door hinges are set at the correct pitch to allow synchronisation by a pair of Lego gears. A servo would be mounted at the back to drive the doors. Each hopper is 70mm wide and the plan would be to mount three of them across the robot, with each carrying slightly more than the half a trough of rice required for the game.
However, I’m not pleased with this design. Although I think it could work, the angle of repose (see previous blog post) for rice means that the path from the back of the hopper to the delivery chute at the front of the robot must be at 35o to the horizontal. Furthermore, I would like to put the centre of mass of the rice between the robot’s axles. This all means that the rice ends up needing to be mounted high on the vehicle.
I think the robot will not be stable if there is a lot of mass mounted high on the chassis.
There are various options to mitigate this, such as placing the hoppers partially in front of the front axles or setting the hoppers on an incline. But ultimately a gravity fed system requires the rice to be substantially higher than the edge of the troughs.
So, I wondered about a design which uses motors rather than gravity to deliver the rice.
After quite a few failed attempts, I managed to design an Archimedes screw in Fusion 360:
I am going to try to 3D print this. If that works, I will design the rest of the system.
If I can build it and it works then it will be possible to mount the rice lower on the chassis, between the axles.
I also wonder if it might be possible to use a single mechanism and run the delivery motor for a predefined time to deliver a measured dose.
I want to build a path for the cattle feed for Hungry Cattle. I wanted to know the minimum angle the rice path should have (from horizontal) so that the rice would flow reliably.
I set up the experiment shown above. To start with the inclined plane (which is a 3D printed wolf in PLA) was level. I placed some rice on the end, then raised it until all of the rice slid to the bottom. I measured the amount I raised the plane then calculated the angle with some trig. I repeated the experiment a few times and took the worst case.
I measured 30 degrees from the horizontal. So my design will use 35 degrees.
Wikipedia tells me that this angle is called the angle of repose.
After a great deal of thought, I have finally settled on the approach I’m going to try for Shepherds Pi. The problem for me has been that the layout of the arena favours the ability to approach the sheep sometimes from the side, and sometimes end-on. So I hope I have built a design that can do just that.
The lifter uses one servo to grip the sheep and a second that allows the sheep to be rotated. This is attached to PJD’s front loader mechanism, which I hope will be able to lift the whole lot (sheep included) maybe 20mm off the deck.
The idea is that the grip rotates to suit the orientation of the sheep, then the robot drives to the sheep (guided by camera and front ToF), the grip grabs the sheep, then the front loader lifts the whole lot. The robot can then drive to the pen, possibly rotating the sheep as it goes to help with sheep “packing” in the pen.
Getting the whole mechanism within the 100mm implement limit has been challenging. However, there is a little room left at the front to add some kind of latch hook for opening the pen gate, should there be time at the end.
Getting that video wasn’t all that easy. We ended up writing software to keep Doofus looking at the camera and to raise and lower the front loader through a turn (all based on the heading as reported by the IMU). That bit all worked fine.
To start with, the software also instructed the robot to start a 360o turn when the ToF detected a hand close to the front of the robot. But a request for a 360 just results in an immediate report of turn finished; doh!
So, we did the turn by radio control, but with Doofus and the front loader controlled by the IMU. Anyway, video made = happy days!