Even More Super Mario Kart

Inspiration

We were inspired by Mario Kart and wanted to translate the game to real life.

As a group, we are interested in autonomous vehicles and would like to build one on a smaller and simpler scale. We also wanted to create a fun aspect to this project, adding a remote-control option for users to play around with. This project was both hardware and software-intensive, requiring a search/path-planning algorithm and vehicle-to-vehicle communication. We wanted to design karts that resemble the actual Mario Karts, which will be very design-intensive. We also want to add features to each car such as LEDs that light up based on the character chosen. We had one kart be fully autonomous with the ability to navigate a pre-existing path with obstacles, as well as two remote-controlled karts that can be used to play against. Each kart goes over items boxes that give it special powers to boost itself or neutralize opponents.

What it does

We created a playable real-life version of Mario Kart implementable in the hallways of Levine for students to play on against either an autonomous CPU kart or their friends.

We created two RC karts and an autonomous kart to allow players to play Mario Kart in real life. We also implemented item boxes through a photosensor activated by going over LED light strips and 3D printed obstacles that the karts will have to navigate through. We used the Hokuyo UTM-30LX LiDar to measure distances to barriers for the autonomous and the Arduino Uno and Mega + BLYNK to implement the many other features on our cars. We also added V2V communication between our RC karts using the nRF24L01+.

We believe our solution turned out really well, with the ability to play Mario Kart pretty effectively. We ran into some power management issues which could have been solved with some stronger batteries and limited some functionality of our karts, but other than that the karts moved and communicated well.

How we built it

In the end, we created two RC karts and an autonomous CPU kart controlled by LiDAR. The chassis of all the karts were prefabricated and we also used omni wheels for all three. All other components were individually wired and attached to the breadboard and overall circuit. We also 3D designed and printed a chassis cover to go over the wires and breadboard and a decorative front for the kart. We also designed and printed obstacles like bananas, bombs, shells, and mushrooms as well as item box markers to put by our LED strips.

We used two RGB LEDs connected in parallel to determine the character selected for each kart. The RGB LEDs were controlled using PWM, which was applied to each of the red, green, and blue pins. By varying the duty cycle applied to these pins, we were able to create many different colors, which we then used to color our LEDs. We used two L293D motor drivers which controlled the four wheels of the car. In order to control the speed of the motors, we used PWM with output compare. The Arduino Mega comes equipped with 5 timers, 4 of which can be used for output compare. We used the fast PWM mode and determined a duty cycle which we wanted the motors to be high for (which in turn would determine the speed) and applied it to each motor’s respective output compare pin.

We equipped a photoresistor to the bottom of the car and used ADC to determine whether or not we detected a light source. This was used so that we could detect item boxes, which were represented by LED light strips placed on the ground. Whenever the ADC value was greater than 900, which we determined through testing, a random item was generated from the list of provided items.

We used an Arduino Uno and the nRF24L01+ radio transceiver to implement our V2V communication. We were unable to implement SPI and radio protocol using AVR-C (not without trying!), as that required the creation of a new library, so we decided to use a library we found from the Arduino IDE. We therefore used a separate Arduino Uno to flash this code onto. The radio transceiver would receive an item from the Arduino Mega (after we determined the item) through a combination of output pins and would then transmit this item to the other kart. Upon receiving the item, the other kart would translate the item into a set of pulses which were transmitted to the Arduino Mega through input pins. Once the item was determined, the Arduino would act accordingly.

We used the Blynk app as our controller for the RC kart. We had two tabs on the Blynk app, one for character selection and one for game controls. All buttons for characters were set to virtual pins, which corresponded to output pins on the NodeMCU. These pins, after going through a logic level converter, determined the color of the LEDs on the car. Due to space constraints, we were forced to use these same pins to drive our motors during the race. We thus came up with a game state feature (signaled by the “Ready” button on the Blynk app) which changed these pins from being associated with the character virtual pins to being associated with the driving virtual pins. The driving functions were done using a joystick, which determined whether the car was going straight, veering in a direction, making a complete point turn, or drifting (using the drift button). We also included a “Deploy Item” button which would be used when the player detected an item (from ADC) and wanted to use it. Depending on the item, the item would either affect the player’s own car or the other player’s kart through V2V communication. In order to see what item the player received, we used an LCD screen on Blynk. We used PWM from the Arduino Mega after getting an item to send to the NodeMCU by assigning a certain duty cycle to each item, where we used the Analog input pin to determine what the duty cycle sent was. Once that was determined, we were able to display the item on the Blynk screen.

In the end, the autonomous kart was able to communicate with the LiDAR, correctly detect obstacles, and turn its wheels based on the path of fewest/most distant obstacles. It was unable to drive on the ground due to power constraints (detailed in the conclusion).

Challenges we ran into, What we learned, & Accomplishments that we're proud of

This project was very intensive yet rewarding. We all learned a lot on both the hardware and software sides by doing hands on work and debugging our issues. A big learning experience was the debugging itself, as we had to be able to determine whether our issues were from the circuits (whether there were faulty/unplugged wires, etc.) or the software. This experience led us to be well versed in serial printing and understanding our circuit schematic so that we could find the solutions to our issues more effectively. A major challenge and obstacle for the project was the relatively short timeline, especially because many components of our project built on one another and we often had to wait on parts to come in, which restricted our timeline and when we could work. An unexpected obstacle on the fabrication side for CAD was the supply chain issues faced by Tangen Hall Venture Labs, which is where we were printing our parts. We submitted our parts 2 weeks in advance hoping to have another round of re-design/printing before our final demo, but ended up not receiving our first original designs until the night before the final demo due to the shortage of 3D printing material at Tangen Hall. Thus, some of the decorative parts for the kart ended up being a bit too large/heavy. However, with more time, this issue could have been fine tuned and resolved. For the RC cars, we had to come up with a lot of unique ideas both in hardware and software on how to implement what we wanted given our power, space, and knowledge constraints. We learned a lot about circuit design in practice and power management concerns, especially with the Arduino and motors requiring different levels of voltage but still a high enough current to operate. We were very proud of creating a workable RC kart using the Blynk app. The character selection was a great bonus. We would have implemented a speaker with varying soundtracks on the car if our delivery schedule was more on time. I think the biggest challenge for the RC cars was the V2V communication, especially given that there was no inherent library to use, which required us to use another Arduino. This was the most inconsistent part of the project, and with more time we would have been able to work out the kinks to make a workable feature. I think the biggest unanticipated obstacles came from power management and breadboard space. If we continued this project, we would have used better batteries and possibly another breadboard to make our wiring neater. In terms of the autonomous kart, the primary challenge encountered was power management. The LiDAR required 12V DC, and the motors ran best on 12V as well. Because we were not able to use LiPo batteries, we had to resort to using 8 AA batteries, which is a lot of weight on the vehicle. However, because the current draw of the motors was so high, the AA batteries could not simultaneously supply enough current to the LiDAR while powering the motors. Thus, a separate set of batteries was required for the LiDAR, which added even more additional weight to the chassis. At this point, the weight was so high that the power was not enough to overcome the ground friction and sheer gravity of the car. Unfortunately, the only solution is to add even more batteries to power the motors more, which adds weight to the vehicle again, thus resulting in a stalemate between the battery power and the weight. The best solution to this would be to use high-powered batteries that are more compact, since rarely are vehicles of this type powered by AA batteries. Given the constraints of the project this was not an option, however it would be interesting to test this vehicle with a different power source given more time and correct safety measures of doing so. The greatest accomplishment with regards to the autonomous kart was being able to use ROS to effectively communicate between all devices. The LiDAR used was an extremely powerful device that has rarely been interfaced with an Arduino. Generally, it is used with much more intricate embedded modules. Thus, much of this part of the project had to be done entirely from scratch, without copying any existing code libraries. In addition, many skills such as detailed command line knowledge, unix, and learning how to use ROS from no prior experience were employed, which was a proud accomplishment of ours. One challenge was with trying to interface the Arduino with other ROS applications entirely in AVR C rather than in the Arduino IDE. As mentioned, this has rarely ever been done before and there are few if any resources available on how to do this without the Arduino IDE. We tried our best to do so and in the process learned how to flash code from the command line to an embedded application, write a Makefile from scratch to compile AVR C based on our specifications, and use exclusively nano/vim for code editing in Ubuntu Server. Unfortunately, we were unable to get this working and had to use Arduino IDE, but we are extremely proud of how much we learned in the process of trying to get this to work.