So this week on the Discord a lively conversation bounced around the subject of the weight of the Cattle Food that we need to transport for the Hungry Cattle challenge.
The Barn Rats team previously demonstrated a pretty successful dispenser that was able to fill a food trough to the required volume. But we had not really given any consideration or thought to the issue of what would happen if we had 3 of those dispensers hanging off the front of our robot.
Uh. That might have been a mistake…
Turns out that the short answer to the question is … we’re going to need to substantially rethink our design.
The dispenser works pretty well, as long as the robot is not trying to go anywhere. Driving it around however is a bit of a problem… Its way too front-heavy for our test chassis.
The chassis is about 180 mm square, with the dispensers sticking out about 100mm to the front of it. The robot body itself weighs 1300g. The front-mounted dispenser weighs in at about 400g empty, and 1000g when filled with 600g of dry rice, which is the amount it would take to fill 3 food troughs to 50%.
The robot has no trouble moving the mass around, even though this test chassis just uses tiny TT motors. Unfortunately backing up, or stopping from forward motion causes the whole thing to tip over…
On the flip side (poor pun intended), it DOES do a pretty good job of dispensing the rice. Most of the rice actually makes it into the food trough. The central bin with the front-dropping trapdoor does a better job than the side bins which have side-facing trapdoors. But as you can see in the photo we do manage to get the bin up to just over half full (the black stripe starts at the 50% point (thanks for the idea @keegan).
So it looks like some redesign is in order. Thinking about moving the bins “back” so their mass is mostly between the robot wheels, then having a slide to aim the rice down towards the trough. Mom always used to say that “there are no fails in life, just opportunities to learn”…
The big lesson here is “pay attention to the mass of that rice”. It is probably not insignificant compared to the mass of your robot.
Before we build our real robot we need to prototype (try out) some of the ideas for parts and strategies we will use in the real bot. Fortunately we have an existing robot that has a chassis pretty much perfect for trying out ideas.
The test robot has a 3d-printed chassis with grid holes on its front and lid that make it easy to attach test parts for various projects. It has 4 brushed motors driving Mecanum (omnidirectional) wheels, and is controlled from a ps4 controller (using Approximate Engineering’s software drivers on a Raspberry Pi Zero). Though not relevant to this particular test, it has a TFT display and a NeoPixel ring on its back end that provide a lot of operational information on commands and battery / system status.
Because we want to eventually try to make this work autonomously, we also included mounts for some sensors we want to try out. They’re shown in the video, but we left them out of the OpenSCAD design code we show below, because they are really fodder (pun intended…) for another story. And because we haven’t actually done anything with them yet.
So, on to the good news. It works. Mostly. A little bit. Sort of… The prototype did its job and pointed out the flaws in our concept. As a proof-of-concept, it was a success. We’ll fix the oops-es and carry on with this as the strategy.
For sure the driver (oops, me…) had some issues with accuracy and driving skills. The major design flaws became much more obvious in the physical reality than they were in the imagination. You probably noticed that we put a camera on the front of the mounting bracket, in anticipation of later using that to help find and accurately position the robot in front of a trough. You probably also noticed that the trap door totally blinds it when it opens. Oops ! Might need to rethink that… You’ll also notice that the hopper needs to be mounted a little higher so its opened door wouldn’t bump into the food trough on the next approach. But, fundamentally, it does drop food.
On the “plus side”, the unanticipated interference between the camera and the trapdoor made the trapdoor turn into a pretty nice ramp that helps to spread out the feed. Even though we plan to relocate the camera (and probably replace it with a Pi Zero with a tiny spycam on OpenCV), we’ll probably put in a “stop” to duplicate that ramp effect.
Our plan is to ultimately have 3 of these hoppers arranged horizontally on the mounting bracket, one for each food trough. And each hopper will be tall enough to hold enough food to fill a single hopper to the required half-way point. The one shown here is “shorter” to reduce printing time since its only a prototype.
What it looks like / How it works
This is how the hopper door operates; the door itself is on a pivot at the back. Normally a small “catch” holds it closed. The catch is mounted on an SG-90 micro servo which can be activated to release the door
The photos below show details of the catch mechanism. Note that the catch is printed with a small pocket into which a standard servo horn is bolted with M2 bolts (its too hard to print the tiny teeth that actually mount to the servo itself).
The trapdoor has a lip to make a clean seal for the “feed”. It rotates on pivots that are actually M3 bolts screwed into a tubular sleeve on the back edge of the trapdoor. Note that the centerline of the pivot should be inline (vertically) with the joint line between the hopper and the trapdoor to avoid binding or interference crashes.
The bottom of the bin has holes for M3 screws that act as pivots; these holes are 4mm dia so that the screws turn freely in them (and the screws are not “fully tightened” when installed). As noted above, these pivot holes are vertically inline with the joint line. Also note that the “back” of the bin has a vertical clearance gap to allow room for the axle sleeve.
The “front” of the bin has mounting holes that the servo mount box bolts into, the back of the box has mounting holes that are used to attach the bin to the mounting bracket. Note that in the pictures below, the bin is shown “upside down” because it is oriented in the way that prints best (with no supports).
The CAD Design
The OpenSCAD code that generates the hopper parts is as shown below.
Note that the code is heavily parameterized. The most likely parameters that would be changed to support a new robot are bin_l, bin_w, and oversize_multiplier. These control the length (front-to-back) and width (side-to-side) of the bin.
The height of the bin is calculated in the code to hold a sufficient volume of “food” to fill the 100 x 100 x 50mm bin half-way. Note that the oversize-multiplier parameter allows you to allow room for a bit extra to allow for spillage. In this example the parameter is set to 1.25 which gives 25% extra.
The “standard part dimensions” screw diameter parameters and the door_clearance_gap parameter can be used to tune your design to match the actual extrusion profiles of your 3d printer.
To run this code, simply paste it into the OpenSCAD editor. You can change the parameter in line 2 to select which part will be generated when you render the design. There are 4 possibilities: “bin”, “door”, “catch”, and “servo” (which generates the clamp that mounts the SG90 servo).
The Python Code
The servo is driven by a PWM signal generated on the Raspberry Pi Zero controller. This code uses the pigpio library to generate PWM signals that are jitter-free.
The setup for the library and hardware is as follows:
import RPi.GPIO as GPIO
# note it is important to "sudo pigpiod" at bootup to allow this to work...
# verified that it works with all 3 servos, even though documentation
# seems to suggest that there is only one PWM generator in pi.
# probably only needs one generator to work even with multiple pins
# the pin numbering is per gpio numbers.
# tested with GPIO.24, GPIO.25, and GPIO.9 simultaneously
servo = 24
pwm = pigpio.pi()
pwm.set_PWM_frequency( servo, 50 )
The code used to open and close the trapdoor latch is as follows (if you build one, the actual constants (600 and 1500), which represent the pulse width, will probably be different, based on your angular placement of the arm on the servo motor shaft):
print("pressed L1 servo 600 LATCH TRAPDOOR")
pwm.set_servo_pulsewidth ( servo, 600 )
print("pressed L2 servo 1500 OPEN TRAPDOOR")
pwm.set_servo_pulsewidth ( servo, 1500 )
So we are encouraged to know that our initial prototype shows that the idea will work. We will need to make some hardware tweaks to fix the OOPS-es, and we’ll need to try it out with a full-height bin just to make sure there’s no surprises there, but we feel like this is indeed the approach we will use for this challenge.