Finally bought some parts

On Feb 7, 2016 I actually spent some money on this project. I decided I have to prototype the air valves and muscles to see how they will work before I can make more progress on the overall design. So I have ordered a bunch of stuff to support that prototyping. The main items are a bench top power supply (two variable supplies and one fixed 5 volt supply) an air pump, 2000 feet of magnet wire and miscellaneous additional bits of wire and tubing.

This will let me build the solenoid portion of a valve and see if I get the expected pull from the core when it is activated. I also will have all the electronics to control the solenoid from the ARM cpu, so I can make sure that works.

With the air pump I can build a muscle prototype and verify its function.

I still don’t know if I want to order the 3D printer now. If I do then I can use it for these initial prototype parts, but it increases the learning curve before I get something that I can play with.

The next steps

The next steps:  build and evaluate/redesign the following components:

  • an air valve (I will want the 3D printer for this)
  • muscle fabric
  • a complete simple muscle
  • a latched joint
  • control of an air valve and joint latch from the ARM cpu

At the end of this phase I should know if the basic design I’m envisioning will actually work.  If not, it’s either time to redesign and try again or go off to some place with little umbrellas in the drinks and re-evaluate.

Development hardware I need to get in order to create and evaluate the prototypes:

  • dual voltage lab power supply;
  • digital multi-meter;
  • decent soldering iron (which I now have thanks to John Cole);
  • breadboard-ing parts (jumpers, resistors, capacitors, etc.);
  • magnet wire;
  • coil winding rig (might be very simple, like a variable speed electric drill);
  • air pump;
  • pressure gauge (ideally computer read-able);
  • air tubing and couplings (need to pick a diameter);
  • fabric for muscle bodies;
  • latex caulk to air-proof the fabric;
  • 3D printer;
  • 3D printer ABS filament;
  • 1/4 (maybe 3/8?) inch machine bolts for magnet cores;
  • o-rings for air valve seals;
  • lubricant for air valves;

I have been looking for all the above items over the last few months and sending myself email when ever I find a good supplier.

Why I’m getting my own 3d printer

I had originally planned to make use of  Case Western Reserve University Thinkbox  to do the 3D printing for this project. It seemed ideal, with lots of equipment available at no charge to encourage local entrepreneurs. But they do (and should) charge for consumables, and for 3D printers that’s about $23 a cubic inch of plastic. I’m guessing I’ll need about 5 cubic inched per leg, plus another 5 for misc. core parts, so I’m up to 35 cubic inches, excluding 3D CAD mistakes and part re-designs.  I can buy a low end, but entirely adequate, 3D printer for about $700, and then the plastic is about $20 for a 600g spool, which must be several cubic inches. If the plastic is about as dense as butter, a spool should be about 20 cubic inches.  I  should hit the break even point on cost after about one full set of parts. Plus, then I can print my own sonic screw driver.

Unresolved low level issues:

  • I think the geometry of a normal walking gate will result in some un-planned joint flexing. I need to either build in some flexibility or allow for the extra motion some other way. I’m a little concerned that the body core will bounce up and down during walking on perfectly level ground. These questions can be answered by doing a more detailed analysis of the dynamics of walking, looking at the 3d geometry.
  • Can I get enough mechanical force from the solenoids (~1500 turns of  #28 wire with 500 milliamps, I think) with the 1/4 inch bolt heads being pulled in, to quickly shift the air valves? If I have four (or maybe more) o-rings in the valve body I don’t now how much drag that will introduce. I have to build this, measure the drag and then see if I can adjust the valve geometry to minimize friction while still providing an adequate air seal.
  • Can the springs in the air valves reliably return them to the neutral position when power is removed from the solenoids or do I  need a more positive force-to-neutral mechanism? (Latest re-design of valves seems to avoid this problem)
  • How quickly/slowly can I move a leg? If I can get 2 atmospheres of pressure in the muscles, and I have between 1 and 4 square inches of face on the muscle pressure plates I think I’ll have enough torque, but I don’t know how quickly the valves will respond or how quickly a leg will move.
  • How many stop points do I need in the joint gears to get the level of control I want for walking (or for picking “things” up later on)? It doesn’t need to be linear. I could have lots of teeth on areas of the joint that do fine motion and just a few in areas that I want to move through quickly. The trade off is that if I have more stop points (teeth) on the joint gear it will take longer to do large movements.

When the prototype pieces described above have been built and tested I should have answers to most of the above questions.

Muscles, joints and air valves

Evolution of the muscle design

Muscles started out looking like an old time bellows (see diagram…oops, no diagrams yet) with a pivot point at the bottom and a lever at the top that would move back or forth depending on which of the two air bags was inflated. The muscles hung below the arm with the moving level coming up through a slot in the center. As I better defined what I wanted to move with these muscles they got more and more mechanically  complicated. Their advantage was that I could use a fairly large pressure plate to get the force I thought I would need at the joints. Finally I decide to guess at the air pressure that  would be available ( around 30 psi) and work out how large a pressure plate I really needed.  This lead me to the design I have today, but still mounted below the arm and moving vertically, to keep the used horizontal space on the body hub to a minimum.  The most recent change was to abandon the idea of a multi-stage muscle (not really needed, I hope) and move the muscles so they were horizontal and  clustered around the arm. This has been mechanically much more straight forward, but I have lost a lot of flexibility if the muscles are not powerful enough or don’t have enough travel to fully exercise their joint’s full range.

I have two important criteria for the muscles: force and travel.  I think I’ll need three to four inches of travel to get the desired joint movement. This will in turn depend on the radius of the joint gear and the amount of angular motion needed at each joint. Each leg joint may have different travel needs. The force needed to move the joint will depend on a variety of things such as: how much weight (extra leg parts) are below this joint; are we lifting the body core with this movement; are we pushing on something; etc.

I switch between metric and English measurement units randomly.  I try to stay metric but sometimes I just think about certain parts in inches. I blame Obama for this.

Evolution of the air valve design

The air valve was originally just a slab of soft rubber inside a high pressure area, positioned over a hole that led to a lower pressure area. A pieced of metal was glued to the rubber (on the low pressure side). A solenoid coil was located over the metal, but outside of the high pressure area being controlled. The solenoid could magnetically pull the flap off the opening to release pressure. This was very simple and I think it would have worked fine, but I needed four solenoids for each complete muscle and the geometry of the parts required to get the flaps in the correct place was not very pretty. The current design uses nested sliding cylinders to control both muscle halves with a total of two solenoids. Its really a much nicer design, but since it doesn’t use the pressure in the controlled area to seat the moving element I am  a little concerned that it wont seal as well or return to the neutral position reliably.  I need to build one and find out.

I expect the sound produced by the air valves when the robot is walking around to be amazing.

Evolution of the joint design

The joint started out as just a disk at the end of a shaft. The disk is used to get the right mechanical advantage for the tendon that goes over that joint and attaches to the next arm segment. I recall being quit pleased with myself when I realized that I could easily adjust the mechanical advantage if needed by just changing the radius of the disk. It could even be a cam shape to provide different torque at different positions. Of course that changes the travel I need from the associated muscle, but  I think I know how to get more muscle travel if needed. At some point I realized that this wouldn’t work at all because the joints were entirely at the mercy of the muscle pressure, which was not well controlled at all. I needed to change the disk into a gear with something to lock onto the gear teeth after motion had occurred.  Since the tendon had to go down the center of the disk I ended up with a gear with a groove down its center to accept the tendon. Then I needed a way to mount the latching mechanism that  would engage the gear  without interfering with the tendon attachment. Lastly I needed to have a way to route all the tendons and control wires for the down-stream joints through the preceding joints. These secondary tendons have to pass as close as possible though the rotation axis of the joint so the don’t change in length and alter their down stream joint as this joint flexes.

What a world, what a world! Time to cue the monkey army. Maybe one of them can make a simpler joint.

Evolution of the design before 2016 and other background

As of Feb 1, 2016 I have not committed any money to this project other than getting a Beagle Bone Black ARM cpu board from a co-worker. He had no use for it and I thought I might make it into the on-board low level motion control processor (and I wanted to play with a Linux ARM based system).

The Beagle Bone Black has quite a nice I/O mix: beaglebone-black-overview

I am a long time Linux user, staring with kernel 0.98, which I brought home from work on dozens of  5.25 inch floppy disks.  All the machines in our house use Linux, including  Mary’s desktop where she does all of her writing. We run a mixture of Mint-MATE based machines (switched from Ubuntu when they abandon the “good” user interface) and many versions of Puppy Linux.  I like both of these distributions a lot.  Each has different strengths that make one or the the other of them more suitable for a particular hardware platform.

We have several old netbooks that are still completely usable running Puppy, but which don’t have the CPU power, ram size or disk speed to  host a full blown standard Linux system. Puppy is perfect for these machines. I always use the Puppy frugal install, which means that to install a new version I just copy three files to the boot directory, update the grub menu and reboot.

I can’t say that I miss the old Linux days, when getting the display configured was an art form, and getting sound to work was a struggle, and getting Ethernet to work was a struggle. Hunting for patches and unreleased drivers. Rebuilding the kernel  over and over again. Now you just download the bootable system image to a thumb drive, reboot, select install and answer a few questions. In 15 minutes you have a brand new system running. And it all works. And it plays nicely with Windows and UEFI. Actually, I don’t know why anyone uses Windows any more unless they must run 3ed party programs that require it.

But I digress.

The first thing I did after deciding to go ahead with this project was to make a list of  requirements, which included not only performance but also cost, technology issues,  servicing (cleanliness) etc. I have that list somewhere and I should find it and plug it in here.

As will be obvious in the notes below I have now deferred thinking about most of the high level issues (the software design),  and I am concentrating on the basic platform mechanics.

Basic platform hardware overview

  • 6 legs, 3 joints on each leg (1 horizontal, two vertical)
  • All muscles on the body hub with string tendons to the joints
  • Muscles provide pressure but do not lock in position
  • Joints use a clock escapement-like mechanism to latch positions
  • Body hub has: air pump, air reservoir, batteries, low level cpu board and interface to all the motion  control actuators, the cell phone,  the mirrors/fiber optic lines to get both the hardware status and the view of the surroundings to the cell phone cameras.
  • Each leg segment will have two digital control bits for muscle control (flex in, flex-out, neutral) and one bit for latch control (allow motion, lock). For status, I’ll need something to report actual joint position and probably some sort of stress or deflection indicators.
  • The foot should have a contact indicator, and maybe an analog force indicator.

The above items need some diagrams to make things more clear, and to help me spot at least some of the obvious errors in mechanical design.

The whole area of feedback from the motion commands needs more thought. If something gets in the way of a leg, or there is uneven terrain, how do I detect it and what do I then do about it.

Skills I will need to develop (because…retired):

  • 3d cad design for 3d printed parts (FreeCAD for design, xxx for part verification)
  • Simple circuit design for leg actuator control from the ARM processor. Since each leg will have at  least 9 digital-out bits for muscle and latch control and there will other digital I/O needs, I’ll need a multiplexor of some sort to get the 54 bits of digital output from the smaller number of  pins available on the Beagle Bone ARM board.

I have a EE degree, but I have been strictly software for my entire working career,  so designing and building even a simple digital circuit will be quit exciting. Getting back to my roots.

  • Python seems to be the popular language for robotics these days, and I’d like to get proficient with it. I now do almost everything in bash, which I am not proud of, but it works.
  • I’ll need to develop an Android app that lets me connect a phone to the ARM on-board CPU via Bluetooth.  So I guess I’ll get to know the Android SDK and Java better than I do now. That app will have to control the cameras, do the image processing to determine the state of the vehicle, keep track of where we are and where we want to go, etc.  I expect that all the higher level software smarts will run in the phone and the base platform will just deal with walking, including adapting to uneven terrain. The high level command to the base platform would be something like “rotate 120 degrees and move 4 meters” or something like that.  The details of which leg does what and which joint does what, and dealing with low level recoverable failures should all stay in the low level platform. This represents a lot of serious work, but it is independent of the details of the platform.











The backstory

Having been the owner of several medium to large dogs, I always carry plastic bags in my pockets, just in case. As with children, the digestive activity of the dogs was always of interest, and sometime of concern. You don’t want to needlessly alienate an entire neighbourhood by not cleaning up as you pass through, so to speak.

So, the problem of dog hygiene is in the back of my mind while I’ll looking at an add for a Roomba on Woot. “If only it would work for dogs” I say to myself. And the next thought is, “Well, why not?”

There are several initial requirements that come to mind:

  • It would have to have legs, not wheels, to move around in a yard, even a fairly smooth yard. The architecture I envision initially is like the little spider robots in the Dr Who episode in New New York with the cat nurses. Or the similar spider bots in Minority Report.
  • It  would need to be enough aware of its surrounding to recognize yard boundaries and make non-overlapping sweeps of the area when activated.
  • Identifying the target items would be a challenge.
  • It would have to keep itself clean to avoid being totally disgusting.
  • It  would have to be very inexpensive to build, because I regard frugality as one of the highest virtues.

After a little more idle musing some additional thoughts occur:

  • For processing power, navigation sensors, cameras and communications, a cell phone has all the electronics I would want in a small robot, and phones can be had for a few hundred dollars. Or, for the truly frugal (me), you could have a cradle for the phone on the top of the robot and just plug in a non-dedicated phone when you wanted to make a sweep of the yard. Use Bluetooth to link the phone to the based unit electronics. Some software would be required, but I should know how to do that. Android SDK downloaded.
  • I’d like to use the phone cameras for as much of the robot input status as possible. So, for example,  instead of sensors on each joint of each leg to report actual position, some sort of video feed could be provided with image analysis used to get joint position. The frugal aspects of this are just washing over me like a warm bath.
  • Camera input for location in the yard also seems like a desirable thing. Mark the yard boundaries with small sticks that have some sort of distinctive colour banding at the top. To get distance information I might need to split the images to provide some sort of binocular vision. Lots of TBD here.
  • To make the project more interesting ( it’s supposed to be fun for me, not just something to get done) I don’t want to use motors. I want to make all the motion pneumaticly driven. This also has a frugal component, since I think I can build pneumatic actuators, but I’m not going to be winding motor armatures.

This could be fun.  A six legged robot doesn’t have any speed related balance issues and could march around in the yard examining suspicious lumps very slowly, if needed. While it is doing the dirty work in the yard I can sit on the porch and have a relaxing drink.

Google searches begin. (How did we ever live without Google search?)




Start of blog

I had intended to start this at least a year ago, but there you go.

I’m a recently retired (or mostly retired) software engineer, who has worked with computers since 1968. Since my departure from the 5 day work week, people keep asking me how I will spend my time. Well, in truth I’m not having any trouble filling the days with happy interactions with my lovely wife, multiple news papers, late breakfasts, playing with the dog and just idling away the time, but in order to provide a more honourable response to the “how will you spend your life” questions, I started talking about a project that I would pursue as a technical gentleman with spare time on his hands.

The project, in short, was a robot that  would clean up after the dogs in the back yard. A poop-bot. Not very glamorous, but useful and with lots of interesting technical problems to solve to make it work.

This blog is an attempt to chronicle my progress on this project, though I will include other material as I feel like it. I had originally hoped to capture the initial design decisions, false starts and  blind alleys that I explored as this activity progressed, but since I have delayed so long in starting the blog I have already missed a bunch of  (to me) significant events.

So the next entry in this will start a summary of where I am now with this and what happens next.