ME 30: Electronics and Controls I
Tufts University, Fall 2023
This two part project consisted of first building a robot that could ascend a ramp, then adding functionality for the robot to communicate with other robots in order to complete a collaborative task. One robot was built for the first part, and a new robot was constructed for the second task. The robots were controlled over an internet connection using HTTP requests and Raspberry Pi.
Tufts University, Fall 2023
This two part project consisted of first building a robot that could ascend a ramp, then adding functionality for the robot to communicate with other robots in order to complete a collaborative task. One robot was built for the first part, and a new robot was constructed for the second task. The robots were controlled over an internet connection using HTTP requests and Raspberry Pi.
Part 1: Simple Ramp Robot
Strategic approach and trouble shooting
|
To ensure that we would have a basic functioning robot to meet the requirements on time, we prioritized the electronics prototyping before the rest of the robot's systems as this was the most unfamiliar and bound to take the most time to complete. After deciding on rear-wheel drive with two motors, the motors, motor-driver, battery sources and raspberry pi were wired and troubleshooted.
As the electronics were being prototyped, I designed the steering system. Although the robot only needed to go up the ramp, we decided to build in steering capabilities to account for any corrections required due to the slight differences in motor speed. I proposed a simple linkage system controlled by a servo motor and prototyped the system. The physical design as well as the electronics and code went through multiple troubleshooting cycles. The wheel mounts were redesigned to be sturdier and the linkage system was revisited to avoid the pieces catching on one another. I was in charge of cable management and organized the wires for ease of troubleshooting.
|
Part 2: Communicative Robot
|
Part 2 of the project required the robot to communicate with the robot of any other group in the class in order to push a cardboard tube up a ramp as shown in the diagram. After evaluating the new design requirement against the existing robot from Part 1, my group decided to create a new robot.
|
Pivoting from Part 1- new challenges
Given the slow speed and fickleness of the steering system, we determined that the robot from Part 1 would be incapable of producing enough torque to push the tube up the ramp and so decided to design a new robot with the following design features in mind:
- Higher-torque motors
- Rails: We drew inspiration from another group's Project 1 design to include rails to keep the robot from falling off the ramp
- A mechanism to detect whether the tube was slipping
- Adding the ability to send HTTP requests from the robot
- Responding to specific, standardized HTTP requests: This was vital for communicating with all of our classmates' robots
Troubleshooting
After some brainstorming, it was determined that two limit switches, installed on either side of the front of the robot, could detect whether the tube was slipping. When both are depressed, the tube is stable. If only one is depressed, the tube is slipping and the robot will slow or speed up to compensate. This limit switch feedback system required a good deal of troubleshooting from a programming perspective on how much speed should vary, as well as ensuring a solid hardware connection.
In part 2, we removed steering capabilities and so had to ensure that the robot traveled in a straight line. This proved to be more difficult than anticipated. First, the two motors moved at different rpms, so we adjusted the speed via adjusting each motor's duty cycle. We also switched motors to higher rpm, which were significantly heavier than the motors from part 1. As a result, the robot initially would not move. After fiddling around with the front wheels, it was determined that the caster wheel we were originally using had too much friction and so it was replaced with two RC car wheels.
My group had trouble figuring out how to simultaneously handle requests and send requests to other robots based on feedback from the limit switches. We collaborated with other teams to ensure our code was compatible, and to get ideas for how to handle requests. Chat GPT was used to debug code and generate ideas.
In part 2, we removed steering capabilities and so had to ensure that the robot traveled in a straight line. This proved to be more difficult than anticipated. First, the two motors moved at different rpms, so we adjusted the speed via adjusting each motor's duty cycle. We also switched motors to higher rpm, which were significantly heavier than the motors from part 1. As a result, the robot initially would not move. After fiddling around with the front wheels, it was determined that the caster wheel we were originally using had too much friction and so it was replaced with two RC car wheels.
My group had trouble figuring out how to simultaneously handle requests and send requests to other robots based on feedback from the limit switches. We collaborated with other teams to ensure our code was compatible, and to get ideas for how to handle requests. Chat GPT was used to debug code and generate ideas.
Conclusion
This project pushed me to learn as I built. The prospect of controlling a robot over the internet was a daunting task, but I learned a vast amount about both hardware and programming through this project. I practiced allocation of tasks in group work as the timeline was challenging, and this was valuable practice for my teammates and I in communicating progress in parallel work streams. Additionally, this tested my ability to troubleshoot on multiple fronts and to eliminate possible failure modes in order to understand where the problem was stemming from.