This article is the fourth in the multi-part series “Building the KR01 Robot” ( 1 | 2 | 3 | 4 ). Further articles can be found tagged “KR01“.
Sometimes when you’re experimenting you fail. Sometimes over and over. I had two failures this week, one that had a solution and one that didn’t seem to. But as the I Ching says: perseverance furthers1.
After some deliberation I’d decided to base my robot on a tank. I’d considered the benefits of a “dual-differential drive configuration, balanced by a non-driven tail wheel caster” on David Anderson’s SR04 robot and thought the OSEPP Tank Kit might be able to provide a suitable drive platform for my robot. One of the requirements of being able to determine the location of your robot is to accurately know how far its left and its right drive motors have traveled. This is necessary in order to perform odometry.
The SR04 has a left drive wheel and a right drive wheel and can rotate in place if the wheels turn in opposite directions (David’s robot impressively can spin in place on a table without changing position). A tank is able to do the same but requires a lot of tread slippage, and this “odometry error” would need to be accounted for somehow, perhaps using another type of locational awareness.
I hadn’t thought of the other problem, and there was a bit of delay in even finding out that there was another problem (one of those “unknown unknowns”). During the assembly of the robot I’d taken the silicon tank treads off a few times, and one morning one of the tread pieces had torn, and it’d been my last spare. I’d contacted OSEPP and they’d been very nice in sending out some replacements. Being this is New Zealand shipping things here from North America took awhile.
By the time the replacement treads arrived I’d gotten the robot to the point where it could perform its first test drive, so I put on the tank treads, wrote a quick Python program to move forward, turn around (do a 360 degree turn) and come back.
I put it down on the carpet and executed the program. The robot moved forward just fine (baby steps!), but as soon as it began to turn around, to my horror the treads slipped and twisted up, partly came off and then caught under the robot. I hit the kill switch (actually, Control-C from the ssh session), put the treads back on and tried it again. Same result. It was better on a wooden floor, but if the rotation was too fast it still sometimes did the same thing.
Now, I can’t blame the OSEPP people for this. I measured my robot and without a battery it weighs 1.7kg. With the smaller 12 volt Makita power tool battery it’s up to 1.92kg, and with the Makita 18v 3Ah battery2 it tops the scale at 2.35kg (5.2 lbs). If one watches the OSEPP Tank promo video on YouTube their little tank zips around with just an Arduino and a six AA cell battery pack, so it’s carrying nowhere near as much hardware. I’d be comparing a kererū with a tomtit. Unfair. I think a robot with a weight similar to the original kit would be fine.
My big fat kererū just couldn’t use the tank treads. I’d considered the tread slippage problem (but not the treads-falling-off-disaster) and ordered four of the OSEPP silicon wheels, and after some floor and carpet testing found that they would work. There’s enough slippage on wood floor or carpet that the four wheels do a reasonably good in-place rotation.
Thank goodness. I didn’t want to have to go back to the drawing board.
The Other, Seemingly Intractable Problem
The other problem was with the motor encoders. These are tiny Hall Effect sensors mounted to the motor shaft (before the gearbox) and are meant to provide a pair of waveforms (labeled A and B) that permit a determination of engine direction, speed and the number of times the shaft has rotated.
I’d spent days debugging this. I have this cool old Iwatsu SS-5710 oscilloscope I bought at a local pawn shop. It’s everything you want in an oscilloscope and more: complicated, mysterious, lots of knobs, bright image, nice lines, good coloring, even engages in scintillating dinner conversation. Okay, maybe not that last one.
I’d tried everything to get a usable waveform off of the sensors. Tantalisingly, I was able to get some tiny waveforms, similar to those NASA receives from Mariner 9 at the edge of the universe. But not enough to peg a Raspberry Pi GPIO pin. I’d disassembled the robot, adjusted the encoders, tried adding a 74HC14 Schmidt trigger circuit (forgetting that the encoders already do this), nothing worked. Ugh.
This morning I was reconnecting the 6 pin IDC cable I’m using between the chassis and the platform holding the Raspberry Pi, and I remembered that there were six pins. Six pins. The left and right motors each had an A and a B (i.e., A1, B1, A2, B2). What had I used the other two pins for?
Oh yeah… power.
I hadn’t provided power to the motor encoders. As soon as I connected ground and 5 volts to the encoders and fired up the robot while connected to the Iwatsu, lo and behold: I had some square waves. Success! If it’d been later in the day I would have cracked open a beer.
I then rummaged through all manner of half-completed Python scripts to find one that with some slight modification was able to count up and count down as the motor drove forward and back. So… the robot now functional motor encoders.
Next: to begin figuring out how to write a PID Controller.