The Rolling Stone
A Spherical Wheel Drive Mechanism

Obstacles and Challenges

During the course of this project every component managed to break or cause us serious trouble at least once and almost every electronic component we used broke requiring a seemingly endless cycle of debugging. The mechanical components required redesign as well when unforeseen problems became apparent at assembly. Here is an outline of some of hte problems we ran into.

ELECTRONICS

RF Interference. The Futaba Attack RC controller broadcasts at ~72 MHz. If the signal amplitude received by the servo was sufficiently high (ie. the RC controller was operated adjacent to the Rolling Stone), noise in the transmitted signal interfered with ALL digital inputs. This acute interference led to meaningless controller inputs. To solve this problem, we removed the antenna from the transmitter, and the noise was adequately reduced.

DSP Battery Hiccups. The six volt lantern batteries employed to power the breadboard and DSP fluctuated in voltage depending on the power drawn. Occasionally, the voltage dropped below the on/off threshold of the board; the DSP turned off/on abruptly, which erased the programmable memory. We solved this problem with new batteries and/or powering the DSP from the outlet.

Burnt I/Os, Faulty DSPs. The majority of electronics problems that we encountered resulted from faulty DSP boards and/or burnt I/Os. Eventually, we acquired a board that functioned.

Power Requirements. Motor actuation pulled up to two amps at twelve volts (24 Watts). While we attempted to use heavy duty general purpose lead acid batteries, adequate power came from the wall.

Heat Dissipation. As a consequence of the high power rate pulled by the motors, the H-bridges passed large amounts of current and often heated such that circuitry approached breakdown (melting). To solve this problem, we augmented the heat sink on each H-bridge by increasing their thermal masses. After this implementation, heat dissipation in the H-bridges was well facilitated. However, long operation of the device (10 minutes +) would heat the motors severely.

SOFTWARE

Memory. The central problem in our software implementation was a dearth of RAM. Many of the variables in the pidcontrol.c, xRCinput.c, and yRCinput.c functions were external or static. Even minimizing the number of static variables could not free enough space, and eventually, each time the program entered the pidcontrol.c function, memory addresses were reassigned. We often fought #.QNAN. In response, we removed the pid control code from the main block and optimized the timing on the RC controller input; in this way, we relied solely on human control. However, in more complicated versions of this device, pid control would be necessary, and a more robust DSP would be selected.

HARDWARE

Clearance problems. We suffered a lot of clearance problems that might have been avoided with more careful solid modeling. Many parts were made, then needed to be cut down to size to interface properly with other parts. For example: the motor mounts hung off of the equatorial plate and interfered with the ball. So they had to be disassembled and have a chamfer milled across one edge. The axles were initially too long and needed to be shortened. Then when the whole thing went together there was no room for the encoders, so the whole thing had to come apart again and be shortened, while the bearing mount holes needed to get turned into slots, for better positioning. Lots of assembly and machining time went into getting the motor mounts, axles, and encoders interfacing with the ball properly.

Manufacturing problems. Many of the parts in the driveline required extremely close tolerances, the press fit for the bearings, was the biggest manufacturing challenge as they had to be 0.0005in. undersized for a proper press-fit. It took several tries and several failed parts before I was able to reach this precision. The cut was made with an adjustable boring head on the mill. Also the stop-sign shape design for the final version of the equatorial plate was a bit of a challenge as it is 18in. across at its longest side while the travel of the CNC mill is only 15inches. The solution was to break up the machining program into two parts one that handled the first 14inches and another that handles the rest. The part stayed mounted in the chuck for both pars of the program. It worked like this: a hole referenced a zero point, after the first program was completed the head of the mill was moved forward 6inches, then the machine was re-zeroed at the hole, and the second program finished the shape.

Design problems. There were numerous challenges in the design of the machine, many parts were argued off of the drawing board, and many parts that were made needed to be made twice. Most of our design problems sprung up because many of the parts had to be interfaced with store bought parts in an intelligent way. For example: to Pick the motors, we needed to get a sense of how much torque they could put on the ball, the torque depends on the gearing between the motor and ball interface, the gearing depends on the motors gearbox and also the ratio of the diameter of the friction wheel to the sphere. The diameter of the friction wheel determines the o-rings to buy, both of these parts interface with the axle, which must be made to fit both the motors shaft and the o-ring, this also has an effect on the position of all of the motor mounts and bearing mounts. So when you go to choose a motor, you have to take into account the o-rings, and the axle dimensions. This gave us some trouble initially.