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!
When I was building P21 I promised myself that I would not build another circuit on stripboard. As a result, I started designing PJD’s control board in KiCAD. But then I realised that large amounts of the circuit were untested, and I wondered if I might design a lovely shinny new PCB that wouldn’t work because the circuit design was wrong before I started.
So, once again I have built a robot control circuit on stripboard:
It’s not my tidiest work, but it is the most densely populated piece of stripboard circuitry I have ever built.
The board has the following features:
A Teensy 4 as its core controller.
A connection to the Raspberry Pi. This has a full-duplex serial link, two GPIO connections (for shutting the RPi down, more on this later), and the power supply to the Pi.
Two 10A H-bridges for the drive motors. I had to use different MOSFETs since the ones I usually use were on back order until April! There are two motor connectors too.
An I2C interface for the front time-of-flight sensor.
A “game implement” connector. This is the same design as the one in P21, so hopefully any of the old implements will at least be electrically compatible with PJD.
An interface for Robotis Dynamixel AX12-A servos. These are old (from a robot I bought in 2006 I think), but they are high torque and I have always liked that they can be connected together via a serial bus. I like to re-use old parts wherever possible. On PJD a pair are used to lift the front loader.
An SBUS connection so that a radio control receiver can be plugged into the board. This is really useful for testing the mechanical aspects of the build.
A BNO055 inertial measurement unit (IMU). This is largely used to calibrate turns on our robots, but it’s also fun that the robot can detect its pitch and roll angles too.
A LiPo protection circuit. In the event that the supply voltage dips below 3.2v per cell (i.e. 9.6v), the circuit is able to switch off power to the whole robot, after closing down the Raspberry Pi. The Pi interface has a serial link for sending and receiving control messages, but it also has two GPIO line connections. One line is asserted by the RPi when it boots so that this circuit knows it is connected. The second connection can be used by the robot controller to indicate that the supply is critically low, this causes the Pi to shut down in an orderly fashion. As it closes, the first GPIO connection goes low indicating that the Pi has closed. At this time the controller board is safe to chop the supply from the battery. This is an important circuit; overly discharged LiPos are a fire hazard!
A DC-DC converter module. This converts the battery voltage to 5v for the Raspberry Pi and some other components.
A servo connection. Our Doofus has a servo to turn his head.
A supply for the exhaust shaker. This is on a PWM output so that the speed can be varied.
Finally, a connection for the robot’s tail lights. Again, a PWM output is used so that various flashing sequences and brightnesses can be achieved.
That’s a fair amount on one board, and thankfully it all works. It turns out I could have gone straight to a PCB after all!
I always felt that the mecanum wheels we use on P21 were too large; they’re about 100mm diameter. I think they are not really suited to delicate autonomous manoeuvres.
Over Christmas I decided to gamble on buying a set of these from Pimoroni…
These wheels are cheaper than ones I’ve seen before (£24 for a set), and are about 36mm diameter.
I say gamble because the website doesn’t specify the size of the hexagonal hole on the back of the wheels. I hoped the hole would be the right size for the hubs we use on our robots…
Unfortunately the holes on the wheels were too small, so the hub didn’t fit.
I thought about 3D printing a new hub to connect the motor shaft to the wheel but didn’t think I could make it strong nor accurately enough.
I decided to enlarge the hole in the wheels. I preferred this method as this keeps these wheels compatible with the hubs we use on all our robots. Well, assuming I could make it work of course; this is what you might call a high risk / high reward approach.
I 3D printed a jig to hold a single wheel, with M4 bolts to clamp the wheel in place. The jig can be screwed down to the spoil board on the CNC router at Exeter FabLab.
Next, I created a tool path in Fusion 360 to machine 0.7mm from each face of the hexagonal hole…
Amazingly, this all worked. I was able to machine off 0.7mm from each face of the hexagonal hole on Exeter FabLab’s Denford router. The cut is just right, the hubs are a nice snug fit in the wheels.
Hopefully, I can get some time to test these new wheels in the near future.