Click this link to view the RoboMaus in action
- Introduction
- Hardware
- 3D Printing and Modelling
- Data Structures
- Concurrency
- Challenges
- Future Improvements
- Special Thanks
- License
The roboMaus project was used to explore hardware programming, data structures, and concurrency.
The idea was to see if independent treads of a tank could be controlled via software rather than a gear system. In order to implement and test this idea our team had to develop hardware drivers for each physical component, software to populate data structures with path information and facilitate communication amongst the hardware components.
The main hardware used for this project:
SAM4SD32 Microcontroller
- This is the brain of the project.
- Code is flashed and stored on the ROM
- Extension pins allow for connection to all other hardware components
ATMEL OLED1 Xplained Pro
- Used to initialize the program via a button push
- Display statistics (number of rotations) on OLED display
L298 H-Bridge Dual Bidirectional Motor Driver
- Used to initialize the program via a button push
- Display statistics (number of rotations) on OLED display
Hall effect sensors
- Used to measure distance by counting wheel rotations
Brushless Motors with 1:10 Gear Reduction
Included Kit Treads
..and a 14V RC battery pack!
The chassis was an opportunity to explore 3D printing using a Tinkerine DittoPro 3D Printer. Two prototypes were developed before finalizing the chassis. All three are shown below:
Prototype Chassis 1
- The first prototype was built to confirm the dimensions of the chassis were printed accurately
Prototype Chassis 2
- The second prototype was built to determine the fitment of the motors, tread and tread axels, and battery pack
- This chassis also indicated a need to create a separate layer to host the computing hardware
Final Chassis
Each tread is controlled independently. Instructions for are stored in two separate stacks for each tread as a ‘tick’ value. These values represent the number of ticks we want to receive from a hall effect sensor.
A path is populated into each stack via ‘tick’ instructions. As instructions are popped off the stack they are sent to the tread drivers which then sends the instruction to the tread. Once feedback that the instruction was executed is received from the hall effect sensors, the next instruction is popped off until no instructions remain.
Each hall effect sensor is connected to independent GPIO pins. This means that the signals are being sent at the same time. To compensate for this we implemented a pseudo-concurrent solution using boolean values. Each sensor has a boolean value associated with it to determine if it should still count ‘ticks’ or not. Unless both of the boolean values tell the program to stop counting, we prevent the next instruction from being popped off the instruction stack.
While not a true concurrent solution, we found it to work within our expectations. Each boolean value is being updated concurrently and this solution solved our problem without having to attempt implementing a monitor, semaphore, or other complex concurrent solution in C.
Working with hardware was more difficult than anyone on our team imagined it would be. Countless hours were spent consulting documentation, making wires, testing voltages, and rewriting driver software.
This project was also my first experience with the C programming language. Coming from Java this was difficult at first to pick up and I spent a long time getting comfortable.
Originally, we had planned to experiment how different data structures affected performance however due to time constraints we were limited to only using a stack though various other data structures were on our list.
A huge part of this project is built on top of MiniOS, an operating system built for the SAM4S micro controller by Rafael Roman Otero.
This project is licensed under the MIT License - see the LICENSE file for details