Skip to content
This repository

Discussion 

ZacharyTaylor edited this page · 5 revisions

Several major design decisions were made during the development of the Mario-kart system. The first of these was to use a distributed system comprised of several small micro-controller boards instead of one large board. This decision was made as the board would have to control a large number of peripherals that would be located all over the kart. This would have meant that a single board would have had to be very complex to accommodate all these requirements. Distributed boards also had the advantage of being more flexible allowing for more boards to be added to the system as needed. A third advantage was that as the sensors and actuators would be located all over the kart a single board would require long wires to connect them. These long wires would be highly vulnerable to noise from the large DC motor. A system using a large number of small boards meant that the boards could be placed right next to the systems they were to communicate with and communicate with each other via a more complex and noise tolerant protocol. For a detailed look at the boards see the Board Design page.

To allow the boards to communicate in the presence of the large amount of noise given off by the DC motor the CAN bus system was used. This was chosen over other communication systems as it was commonly used for long distance communication and automotive applications due to its high tolerance to noise. For the CAN bus system it was decided to use the SAM7 chips with a built in CAN controller and to use the ATMEL libraries implementation of the CAN to minimize the work that we would have to do on this system ourselves. This proved to be a mistake as the ATMELs CAN implementation was full of faults and several questionable design decisions that made the system unusable and led to us being forced to rewrite most of the CAN implementation from scratch.

On the actuator side of the implementation it was originally decided to use a servo to control the steering system, however once investigated the large price tag of the available systems and relatively low torque caused us to rethink the approach and instead implement a system that used a gear motor with a magnetic encoder to turn the wheel. For the braking system it was decided to leave all of the original hydraulic system and simply drive the brake pedal with a linear actuator. This decision was made as it would allow for rapid change over times from manual to automated control which was a requirement of the system. The selection process for the specific actuators used can be found in the Servo Selection section.

For driving the actuators we developed our own motor driver boards that would attach to the boards that required it. It was decided to create our own board instead of buying a commercial one as all the commercial boards looked at did not meet our needs. This was because none of those looked at exactly fit our requirements for voltage, current, connections and size, in addition to this these systems were substantially more expensive then designing our own board. In retrospect this may have been a mistake as the motor driver boards had the most issues of any of the hardware components to get operating in a correct manner.

For safety reasons a decision was made to create a State Machine that recognised if an error in the system had occurred and caused all the systems to transition into an error state. This error state would keep steering and sensors but would remove power to the motor and immediately apply the brakes. While there would be situations that this error state would not be the correct response it was implemented as in most situations it was the best possible resolution to an error situation and a more complex error handling system would over complicate the system. See Safety considerations for more details on this system.

Something went wrong with that request. Please try again.