Robot Project: Treat dispenser installed on robot

Huge progress on the robot and treat dispenser! They are connected and working together! Thanks to a very helpful suggestion from my wife I was able to implement a simple fix for the clogging problem. I cut some thin flexible plastic from the top of a takeout sushi container and cut one end into fingers. I attached it so that it reaches about one “treat height” above the belt. The fingers brush back extra treats that would get carried forward as a stack due to their stickiness but they don’t allow them to get jammed by the fingers because they are so weak and flexible. You can just see the fingers in this picture:

Detail of anti-clogging solution…

The fingers also make the kicker servo and armature more effective. I added a zip tie around the kicker servo to make it more stable and to transfer more of the energy to the treats. This works good and having run multiple full hopper tests I can confirm that it successfully clears all the treats without jamming.

The next thing I needed to do was to mount the dispenser on the robot and as part of that mount the servo controller and the servo batteries somewhere. I got some nice 1.5cm x 4mm standoffs and drilled and countersunk some holes in the treat dispenser base plate and mounted the controller behind the left side servo. I was able to cut a couple of slots and mount the battery pack using a velcro strap next to the controller.

Controller board mounted using standoffs and the battery pack for the servos mounted using velcro strap.

Two new tools made a huge difference in this process, I got a set of small metric wrenches and a set of coarse and fine files. The wrenches allow the tightening of these tiny fasteners so much better and more easily and the files allowed me to drill out the slots and then remove the rest of the material by filing to create nice clean slots without cracking/burning/destroying the acrylic.

File set, not an expensive one but it works great, the small files on the right are perfect for making slots or fitted holes in acrylic. Just use the brush regularly to clear the file when working with plastic. Also, go slow to not melt the plastic with friction.

Tiny wrenches apparently usually used for working on carburetors. The metric ones are wonderful for tightening the tiny nuts on the robot without mangling them.

I was able to use some of the existing holes in the upper deck of the GoPiGo robot to finally mount the treat dispenser on top of it just behind the camera. Handily it also centers most of the weight of the treat dispenser over the drive axles and it doesn’t seem to make the robot more prone to tipping. I was worried because this particular robot only has a single roller caster in the back.

Using the existing holes in the upper deck of the GoPiGo robot to mount the treat dispenser.

I ran a test with everything integrated this morning and the robot was able to move, turn, use it’s sensors and dispense treats with no problems. Here is the video of the run:

I’m really happy with the progress so far, the next step is to make the software part of this project more usable. After messing around with trying to make the robot autonomous I have decided that it just isn’t up to it in terms of sensors, steering and maneuverability. So, I’m going to implement a dashboard and keyboard controls so I can directly control the robot and treat dispenser remotely via an ssh tunnel.

Robot Project: Treat dispenser acrylic version powered test

I got the servos installed after some back and forth. During powered testing to find the right position for the servos I managed to have the servo lever arm push on one of the axles. This popped the entire feeder body off of the base breaking the CA glue free. I had suspected that it would have a hard time holding on that long narrow seam on the bottom with torque and a big lever arm. So you’ll see later that I fabricated a couple of aluminum mounting brackets and screwed the dispenser to the base. This is much stronger and I realized it may be useful to disassemble this to clean it at some point.

I figured out the range for each of the servos to power it’s part of the driving sequence. I wrote a little python program to just run through four cycles. I tested it with real treats. For the most part it works fine and the ramp inside performs as expected, it can clear all the treats now. However, the narrowed area where the ramp is causes the treats to bind up there. They are a little moist and stick together enough to get suspended in that gap. I’m going to have to put another small servo with a kicker somewhere in that area to twitch the food to keep it moving. But, overall it has been very sucessful.

Here is the video of the test run:

Next up is solving the clogging problem then mounting it on the robot somehow.

Robot Project: Acrylic treat dispenser

Over the holidays, after evaluating alternatives for cutting the acrylic and aluminum, I got a bench top band saw.

It has allowed me to make all the parts for the feeder quickly and reasonably straight. I even figured out how to make the treat ramp inside to keep them from getting stuck. I used CA glue to bond everything. That was a little learning curve. My new clamping surface plus some masking tape to avoid gluing the parts to the bench worked great. So, here is the assembled unit:

I'm very happy with how it came out. Next is installing the servos and getting it running under power. The placement is going to be tricky.

Robot Project: Treat dispenser cardboard mockup

I’ve been working on a mock up of the servo driven treat dispenser for my robot. I wanted to build a mock up to look for any design problems before I commit to cutting aluminum and acrylic sheet. Here is a quick design walk-around video:

I also did a test with real treats that went well, here are the videos of that:

So far, so good, I’m a little worried about the size and weight of the treat dispenser but I think my next step is to try to get to a powered test of the mechanism.

Robot Project: Audio In/Out, Cat Treat Feeder, Refining the Patrol code

Whenever we’re away for a long time we worry about our cats. There are people who come in to feed them, play with them, and change the cat box, but still we worry. Over the years I’ve developed more and more technological solutions to allow us to check in on them remotely. Now, before we go I set up multiple wifi cameras around the house, each of which is in a likely cat activity space. I can reposition the cameras remotely and they capture based on motion and save up a nice movie of all the activity broken down by hour. They have infrared cameras and so we get twenty four hour coverage. This works pretty well and reduce worry a lot.

There was only one gap in this system, sometimes the cats decide to be completely outside of the view of all of the cameras for many hours. Being an engineer I felt compelled to try and build a solution to fill this gap. I decided that I would build a robot rover that could do the following:

1. Autonomously roam one or more rooms of the house

2. Take pictures during it’s patrol and upload them

3. Record sounds

4. Play our voices calling for the cats and offering treats

5. Dispense treats

6. Allow me to take over and control it’s functions manually over the internet

The theory would be that while a robot would likely make the cats wary, something that sounded like us and dispensed tasty treats would make them get over that and come close to be seen on camera somewhat on demand.

Now that I have the robot assembled and I’ve figured out how to program it, I’ve been working on the patrol code. It is still a work in progress but I’ve managed to get ten probes into a room and not get stuck, I have some ideas on how to get to the next level. Along the way I’ve discovered some interesting edge conditions in the python api code, for example in some locations where they convert from degrees to a number of intervals from the wheel sensor they use integer math. Not in general a problem except when the division comes back as zero in which case the onboard controller takes that as meaning “turn on the motors until you’re told to stop” instead of “stop after some number of wheel sensor signals" So, every so often everything would be going well and then the robot would need to turn a small amount and it would just start spinning in place until it hit the code to go forward which at that point was in a random direction. There was a similar issue with the code to go forward a certain number of centimeters resulting in running right into whatever wall was in front of it.

I’ve got all of the safeguards in my code now to prevent those conditions now, and it has been interesting debugging both in the code and physical world. One of the mechanical things that I ended up having to fix was that I had originally mounted the servo on the front and the ultrasound sensor on the lower deck of the robot ( they didn’t say you shouldn’t and it was out of the way of the camera .) Turns out, that you don’t get full range of motion of the sensor on the servo because the circuit board hits the upper deck. More importantly for something that rolls around the floor it was easy for the low mounted sensor to miss things that would interfere with the top half of the robot. So, I moved it up to the upper deck. I just pivot it out of the frame when I use the camera.

I also learned that you shouldn’t operate the motors and take a picture at the same time, the ribbon cable ( not shielded ) for the camera runs right past the power circuit for the motors. There is a lot of RFI when they’re running and so you get some pretty funky images as a result.

Robot showing amplified speaker, microphone, and new placement of the ultrasonic sensor

I got a very cheap USB microphone dongle to use for audio input… bad idea… the gain on the device was terrible, it worked but the audio was barely audible over the noise. The noise was because all of it’s circuits were yes, you guessed it, right near the motor controller board. I ended up using a nice USB microphone via a USB cable clipped to the side of the robot, that worked like a champ and had enough gain to pick up a cat vocalizing.

I also got a tiny rechargeable amplified speaker to plug into the Raspberry Pi’s headphone jack and that worked fine. I got a 90 degree adapter to keep the wire away from the wheels and mounted it to the back with some double stick tape. Using the pygame module it is easy to play any audio file so we should be able to record ourselves calling to the cats and use that.

Design for cat treat feeder…

The final item is the treat dispenser, this is an entire project in itself. I have a design that I’m working on and I’ve created a prototype of the dispenser mechanism. I have been using components from the Lego Technic collection of parts. The great thing is that they have all kinds of shafts, bearings, gears, wheels, beams, etc… that are all compatible with each other. I’m not qualified to machine anything or even do a competent job designing something to be machined. So, these are a godsend and have allowed me to build the core mechanism of the treat dispenser and get it working. The power for the treat dispenser will come from two additional servos one on each side which will push a peg on a drive wheel, they are set 180 degrees apart. (see video for demonstration in the prototype) Fortunately the folks who make the robot provide a kit with an add on servo controller board that can control multiple servos and it comes with a couple of big servos that should work. It also has it’s own batteries and so it won’t be dependent on the robot’s power.

You can see the up and down action of the servo being translated to rotation to drive the belt.

I’m going to make the case for the treat dispenser out of 1/8” acrylic sheet and I’m going to have to cut these parts a lot more cleanly that the last one because I intend to glue them together. My Dremel has a straight cutting bit and a guide collar and I think that would work with the panel clamped firmly to a sacrificial piece of wood and pressing the Dremel against a guide fence. I’m going to be experimenting soon.

That’s where I’m at for the moment.

Robot Project: Adding pi camera and making a mounting bracket

I’ve started hacking away on a prototype program to have the robot drive around the room and investigate the objects it finds with the ultrasound sensor. Part of that was to take a picture, so I needed to get a camera. Raspberry Pi makes a nice add on camera which just comes with a ribbon cable and the camera card. You can just let the ribbon cable anchor the camera to the upper deck of the GoPiGo robot, but it seemed to be too low so that you’d always take pictures of the ultrasound sensor and also not well anchored so when the robot drove around it would flop back and forth. So I needed to fabricate a bracket.

I decided to make it in two parts, a lower right angle made out of .032” aluminum and an upper mounting plate made of the same 1/8” acrylic sheet that the rest of the body parts are made of. I made the cuts in both the acrylic and the aluminum using my Dremel tool and a cutting disk. It worked pretty well just needing to take my time and not heat the acrylic up too much. The only downside is that there isn’t a way to use a guide ( or shall I say I haven’t figured that out yet ) so the cut edges are a bit erratic. The resulting bracket is charmingly imperfect, but completely functional. I secured it to the upper deck with 8x3mm screws, nuts and a compression washer, the mounting plate is attached to the aluminum angle in a similar manner. I almost had an issue because unlike everything else on the GoPiGo the camera board has 2mm holes. Fortunately I had a couple of 8x2mm screws and nuts and I was able to use them to attach the board to the mounting plate. Because of the inaccuracies of my fabrication I had resigned myself to crooked pictures, but due to a happy accident, my inaccuracies canceled out and the camera ends up quite level.

Now back to debugging my patrol code and adding in the image captures.

Robot Project: Assembly and programming

Back in July of 2016 I guess I thought I’d have some time on my hands to play around with robots… that didn’t happen… but I did buy a GoPiGo kit from Dexter Industries along with some accessories. It has been in my office drawer for four years until this week when I got it out and put it together. It is a nice kit and targets kids 10 years and older and is really quick and easy to assemble. I would say that the youtube videos are the documents of record on how to assemble and get started with the GoPiGo. The robot is a simple rover powered by a Raspberry Pi and a Debian Linux distribution called Raspbian for Robots. It also has servos, cameras, and ultrasonic sensors that you can add on. There is a simple python api for programming the robot and interacting with the servos and sensors.

The version that I have is the GoPiGo 2 and the current one is GoPiGo 3, they have an archive of all of the software and documentation for old versions and the YouTube videos for the old ones are also still there. I got it assembled with only one mishap where I cracked a small Plexiglas part by over-tightening a fastener, I was able to mend it and continue. The software setup was equally easy, just plugged in an Ethernet cable, pointed a browser at it and they have a vnc based desktop where you can configure WiFi. Once it is on the wifi network you unplug the cable and you can just log on to the robot where ever it is via WiFi.

I created a github project for my programs and using git I can just pull them onto the robot. That way I can code on my desktop and just move things over via git. You can power the robot for programming purposes using a USB power adapter so that you don’t deplete the batteries while you’re debugging. I’ve successfully shipped over a couple of test programs and tested moving the robot and also manipulating the servo and reading the ultrasonic sensor. Now I’ve just got to think about what my first substantial robot project is going to be.