I2C is not ideal when only one slave is most often being addressed: We expect that the Raspberry Pi will predominantly be talking to the steering controller MCU, but since that MCU has other auxiliary functions, it would be inefficient to add an extra command byte. The MCU is an Attiny24, which has a bare-bones USI hardware for I2C to be complemented by user software. This allowed the MCU to have two addresses in software, one dedicated for steering, and one for auxiliary functions.
Power supply spikes: Servos can create some nasty spikes on the supply rail. The steering servo was originally on the 5V rail shared with the MCUs, but this would cause the MCUs to reset periodically. Moving the servo to a separate 6V line solved the reset issue, but the spikes, albeit smaller, were still on the 5V rail. We faced this reset issue again when working with the drive motor. This time, the Amazon NiMH batteries were limiting the current rate of change such that supply spikes when the motor was switched on caused some MCUs to reset. This is probably a consequence of manufacturing the batteries to have a higher cell voltage and function as better equivalents to Alkaline batteries. The stock batteries and increasing the PWM frequency solved the issue.
Some of the problems we encountered and solved:
We will be competing with a new robot built on an RC Car and powered by a Raspberry Pi with custom motor and sensor hardware. The hardware consists of three AVR microcontrollers, to control the drive motor, steering servo, and auxiliary sensors. The Raspberry Pi communicates with these over an isolated I2C which prevents voltage suppply spikes caused by the motor from affecting the Raspberry Pi while allowing for compact bidirectional communication. In the fall semester we assembled a nearly functional platform that can drive without feedback. In the spring semester we will finish the hardware/firmware with a PID controller on the drive motors, then move to the Raspberry Pi for line detection.
20th Annual Mobot Race (2014)
In Spring 2013, we competed as a team of 6 undergraduate students from the Carnegie Institute of Technology (5 ECE, 1 Mech). The robot took 1st place in the Undergraduate category, passing through 12 gates in 1:48 on the first try. The wind and rain became an increasing problem on the next two official trials, but it successfully completed the race five minutes after our last trial on an unofficial run! Just comes to show the complexity of operating in an outdoor environment.
The School of Computer Science at CMU holds an annual competition where robots must follow a painted 255' white line on the concrete sidewalk outside Wean hall. Robots must navigate several curves and two steep inclines as well as branches at the end of the race for the fastest time. Holding the competition outdoors poses several issues, primarily that traditional line sensing components that operate in the infrared spectrum can be blinded by sunlight.
20th Annual Mobot Race (2014)
We will be competing as a team of 4 sophomores this Spring with a redesigned faster and smaller robot. It will use an RC truggy platform and have a Raspberry pi for image processing as well as two AVR microcontrollers for motor and steering control.
19th Annual Mobot Race (2013)
blue: PWM to Servo
green: 5V rail to MCU
yellow: 6V rail to Servo
Both rails from 7.2V battery