Hyper Lapse Robot: Part 2/3
Redesigning Frame
The first goal for this week was to redesign the frame such that the rear wheel was replaced with a caster ball. The previous design of a single stationary wheel added a large amount of friction when the robot turned, decreasing it’s effective turning radius. The new design with a caster wheel would allow the robot to turn much more easily then before.
Initially, my plan was to model & print the caster wheel well myself, using a hyperlapse25 mm stryofoam ball. Due to limitations of 3D printing, the curved surfaces of the initial test prints were extremely jagged, causing the ball to not roll smoothly in the well.
I decided that a professionally manufactured wheel would be the easiest option. After some searching online, I came across these nylon roller balls, for the purpose of furniture. My research showed that alternative options designed for small robotics tended to wear easily, becoming hard to roll over time. Since this robot needs to be used in outdoor environments on harsh surfaces, a more durable option was needed. Though these nylon rollers are are not designed for this purpose, their low cost, durability, and ready availability (2 day shipping) made them the ideal choice.
After the design was modified to mount the caster ball, additional mounting locations were added to the frame to support the Pi Zero, the two drivers for the stepper motors, and the batteries.
Control with the Pi
The next step I worked on was setting up the interface the Pi would use to communicate instructions to the stepper motors and servos. Initially my plan was to control the steppers through an Attiny85, and then to send velocity instructions to the Attiny85 through rosserial. After experimenting with this approach, I decided against it for the following reasons. First, the combined power draw of the 2 Attiny85’s as well as the 2 stepper motors and 2 servo motors would have been too much for the 1A battery to handle. I decided the additional load on the Pi of having to constantly cycle through each stepper motor’s step phases was enough to bare.
To control the stepper motors, I first tried using the RPi Motor Library. Due to compatibility issues with the version of Raspbian Lite the Pi Zero was running, I ended up writing a stepper motor abstraction. This abstraction spawns a new thread for each stepper motor, allowing the script to perform other tasks while the steppers are being driven.
Controlling the servo motors was trivial due to the Pi’s built in PWM capability on select GPIO pins. I wrote a wrapper class allowing the servo position to be specified in degrees instead of duty cycle.
Now that we have an easy interface to control the bot, the next step is to build an API that defines a hyper lapse path and then converts that path into control outputs. Due to the Pi Zero’s limited compute power, installing and running ROS turned out to be a challenge. Because of this, adding ROS to the Pi will be pushed to the following week.
Progress & Additional Work
This week’s work introduced many unexpected roadblocks reducing the amount of progress in the bots completion. Because of this, my goal for the following week will be focused toward creating a functional and usable bot. More advanced features such as different pan/tilt types, and path constraints will not be focused on in favor of a working bot.
The final week will involve, creating a simple interface for the user to control the bot, as well as communication between the Pi and a GoPro. Once the Pi can stream pictures from the GoPro, localization can be performed allowing the correction of any errors that occur while following the path.
