to mark a step as We started with a sketch of a wheel that had legs, or short sticks that would push off the ground behind the bottom of the wheel to roll the wheel forward. I was inspired by Object Oriented Design to make this robot, since this way each wheel (and the motion of any robot using these wheels) would be abstracted away from the main task of the robot.
We chose 5 "legs" for the initial wheel, kind of arbitrarily in order to have extra servos left over and better approximate the wheel shape when the legs extended. The first body was 2 discs laser cut out of 1/8" acrylic, with mounting holes for the servos and one central axis. This iteration had its plates ~3 inches apart.
After mounting the motors and legs, the wheel looked like this. The long screw in the middle was insufficient for holding the two plates together in a stable way. It kept coming loose and was very bendy in general. We added a wire connection between the two plates and that helped, but we would fix that in V2. We weren't sure whether to put the legs on the inside of the two plates or on the outside, and just placed it on the inside to centralize the forces rolling the wheel.
I'm using an Arduino Uno to control the servos, powered by a 3.7V Li-Po battery separate from the RC car battery supplying power to the servos themselves. I originally had the Arduino jacked into the car battery, but noticed that when multiple servos were being powered the operating voltage would drop and my Arduino would restart itself. Not good. (Excuse the mess, this wire arrangement is AFTER cleaning them up)
Here's the other side of V1. I'm using a voltage regulator to drop the 7.4V car battery to a stable 6.8V for the servos, and I never had underpowering issues. When manually testing the rollyness, the 5 servos on the black side really unbalanced the whole contraption. Adding the battery helped significantly with balance, and the power cables that had to travel across the gap between the plates helped keep the whole thing together. There was nowhere to mount things in-between the plates because there was just a single screw holding the whole jawn together, and the power wires helped that feature out.
At this point, the robot worked. Kinda.
It still had no sensors, and from its flailing you can tell that it has no clue which motor is down. This makes it hard to toggle which motor to power, so it just does them sequentially. I spent some time making very poor quality limit switches out of a wire and a resistor, but forgot to add a pull-down resistor to ground so there was a lot of noise. Some switches would trigger randomly or get stuck, and the code was still written in such a way that only one motor could be powered at a time.
All in all, rollyboi was a pretty inconsistent and blind robot at this point. It was a little unstable because of the one centerpiece holding it together, and the final robot had a tendency of pushing itself against the ground hard enough to knock itself over. The programming also needed a major rehaul.
Version 2 looked a little different but incorporated a lot of changes. First off, the limit switches from before were switched out for pushbuttons, which are hidden under duct tape pads along the rim. We had to cut a little notch in the original wheels to accommodate them. These reliably reported which side had just touched the ground. We also used clear acrylic this time, to more easily debug wiring issues inside the robot's two plates.
In the middle of the wheel, we also added three connectors which were meant to stabilize the two plates together. This didn't work because the connectors were just a bit too loose to actually do anything. We couldn't recut because of a lack of time and access, so we wrapped them in paper and carefully pushed them into the gaps. When mounting the second plate however, it cracked a little in the middle because of the pressure we put on the plate to securely fasten the connectors together.
This new designed allowed us to mount things on the inside of the robot. It's a little hard to see, but inside the robot's middle bit we taped the breadboard, Arduino, and battery pack to one of the three connectors securing the two plates. Unfortunately, this makes it heavier on one side and harder to begin rolling in certain orientations. Notice also that the wheel's legs are now on the outside of the rollbot. We realized in testing of V1 that the leg would extend suddenly sometimes, tipping the entire bot over. We made the gap between the plates a bit wider and put the legs on the outside, so that no full extension would be able to tip over the entire bot. To prevent this, we also added another set of servos on the other side of the bot, so both sides push off the ground simultaneously.
The last program only allowed activation of one servo at a time, which made it impossible to control both sides of the wheel that needed to be controlled. I added timer control that allowed multiple motors to go at the same time, i.e. allow servo albert to extend while servo eddington was still retracting (the others were bentley, carlton, and debbie. bentley's arm was stripped, which partly inspired us to add motors to the second plate of the robot. Thanks bentley!)
Our previous program activated the motor corresponding to the switch last triggered, and our current program just detects presses more consistently. However, this is not nearly enough for speeding up the rolling of the bot. Given an initial velocity, when each leg is triggered there is no guarantee it will extend in time to hit the ground before the wheel has already rolled on to the next switch. This leads to the flailing that sometimes occurs. We can calculate the velocity of the robot from wheel circumference and the timing of the presses, but the delay time before triggering a servo and "how many servos ahead of the switch" to trigger was something we couldn't figure out in time for the robot. That would be a future feature to work on, since the robot could reach much, much higher speeds with consistent leg triggering.
Due to a combination of wind, a broken chassis, and an unstable rim distance, we didn't get to far in the final course :(. However, we were able to go a decent distance in testing, and entertain some people by trying out a new idea.
Problems with V2:
We settled on the algorithm that just triggered whichever motor was above the switch last pressed since we didn't have time to fine tune it. This limited the speed of the final iteration, but prevented it from kicking itself over. Adding servos to both sides was definitely beneficial, however.
The rim was unstable even with the connectors. Because of our hacky paper fix, the connector distance was inconsistent, and the weight of the bot tended to make one of the plates tilted in relation to the other one. When it fell over in the final run, it was because the robot made itself top-heavy and rolled onto the thinnest section of its rim. We could add period rim arms to stabilize it, but that would require a new way to secure connectors.
In the future, we'd like to implement turning. By making one side's leg extend faster than the other side, the robot jolts in a controlled way and angles itself. However, due to the rolling nature of the robot, it is impossible to give rollyboi v2 the eyes it needs to navigate. The image will always be rolling! We could only ever travel along pre-programmed tracks. Fixing all the above problems would made rollyboi the best he could be for version 3. Eventually, I'd want this wheelbot to act as just part of a larger robot
Thanks for reading this saga of the rolling family, and have a nice day!