(the infamous all-nighter before competition)
Hi! Welcome. This blog post is made to show off the robot that my team and I developed over the summer. If you have any questions, please leave a comment or send me an email. I want to help any way I can!
Table of Contents
- Robot Objective
- Mechanical Design
- Controls and IO (line following, arm and claw control, navigation)
- The “Disaster Bug”
1. Robot objective
The Engineering Physics Autonomous Robot Competition (known colloquially as robot comp) is a five week hands on project course in which teams of four work together to build an autonomous robot from scratch. And when I say scratch, I mean scratch. There is a lot of work involved when it comes to creating the chassis, wheel mechanisms, circuits (for control and sensors), and then creating code to navigate the course.
This is what the course participants have access to:
- Andre Marziali provided H-bridge circuit schematics using the LTC1161 gate driver, as well as a crash course on development boards (STM32 “Blue Pill”)
- 3D printers
- Laser Cutters / Waterjet cutter with particle board and various plastics
- STM32 “Blue Pill”, DC motors, mosfets, optoisolators, gate driver, Li-Po batteries, NAND gates and other electronic components [with restrictions, no integrated H bridges for instance, some other motors are banned].
- Raspberry Pi allowed
The rest is up to us (using our fantastic instructors for guidance)!
Robots compete head to head in 2 minute heats. The goal: Collect as many stones as possible and place them in your gauntlet. The team with the most stones wins!
In accordance with previous years, 50% of teams captured a grand total of 0 stones during the competition day.
2. Mechanical Design
Most of this work was done by the fantastic Gabriel and Fiona. They put a lot of work into the design but this section will be short.
Our robot got its name from an Ikea lamp, due to its visual similarities:
We built an arm prototype out of Mechano but it’s not very 𝕒𝕖𝕤𝕥𝕙𝕖𝕥𝕚𝕔 so I will not include it here.
The arm design is especially unique. It uses a series of double parallelograms, which keeps the claw parallel to the ground at all times. It is controlled with two motors attached with worm gears. Its angle relative to the robot was controlled by a centrally mounted servo:
Yes, the circuits were messy. At least we had nice connectors between them. I would do this differently if I were to rebuild Hektar.
The chassis was made from particle board. The wheels and geartrain were designed to ensure a proper balance between speed and torque to push the robot up the ramp.
3. Controls and IO
Our robot was somewhat unique in that it was being controlled by a Raspberry Pi in addition to the STM32 “Blue Pill”. Why did we do this? Truthfully, it was mostly for learning opportunities. The team was really excited to learn Robot Operating System (ROS) because of its widespread adoption elsewhere.
Our robot had ’em.
Dual H-Bridge Design:
As mentioned above, this design was taken from Andre Marziali but it’s worth showing here:
The LTC1161 gate driver eliminated the need for P-channel mosfets, thus (according to the program director) making this a cheaper and more reliable design. Sounds good to me!
And, the soldered version (I think we all ended up making one or two of these):
There were a few more hiccups with this circuit we encountered. Our robot needed two of these circuits (because our arm was driven by DC motors and not stepper motors/servos), which lead to a shortage of PWM-capable outputs on the Blue Pill. To resolve this, instead of using two PWM signals per motor (forwards and backwards), I built 2-way demultiplexer so that the H bridge could be controlled with a single PWM signal and a forwards/backwards pin. This is the only change that we made to the above circuit (not pictured)
Line Following / Feature Detection
Our robot had an array of 5 infrared reflective sensors (QRD1114) to detect tape. The circuit output was regulated to 3.3v so the raw input could be fed into the blue pill.
Right: a testing of the soldered protoboard in action, transmitting data from the Blue Pill analogue read to the Raspberry Pi through ROSserial.
The Raspberry Pi/ROS did offer use one advantage that very few other teams had: WiFi. While of course we couldn’t use this during the competition, this made software tuning and debugging a breeze when compared to other teams. our PID tuning was performed with a GUI over realVNC!
For the curious, here is the component network that controlled all of Hektar’s motion:
ir_error_node: reported the state of how far Hektar is from the centerline. Also sends a flag when it believes a feature to be present (a T or Y intersection, for example).
control_master: keeps track of how many features the robot has hit and tells it what to do accordingly (line follow, stop, dead reckon). Also controls the arm.
The rest are somewhat self explanatory and are also visible on the github repo.
The use of a Raspberry Pi also meant that we could manually control our robot remotely:
4. The “Disaster Bug”
They all said that something would break the night before the comp for no apparent reason. I didn’t belive them, but they were right: it’s a measly 12 hours before our robot is put on display in front of hundreds of people, and Hektar forgot how to follow lines!
What is going on!? We should be calibrating setpoints for the arm locations*. After an arduous debugging process, we found the invisible culprit: EMF. Whenever the left motor was running, the unshielded serial connection between the Blue Pill and the Raspberry Pi would be interrupted (scoping the connection showed only the Hi logic level). Uh oh. That connection was our robot’s spinal cord, and without it Hektar could not walk.
How was this happening when our circuits were electrically isolated? Also, why was our robot working flawlessly for weeks beforehand, only to have it fail the night before? I actually still don’t know the answer to the latter question…
*we had shown that Hektar could pick up stones as well as deposit them. He could also stop at intersections and know which way to go. Collecting one stone was close and realistic, it was just a matter of putting 2 and 2 and 2 together.
The fix was two pronged. Firstly, we reduced the noise that the motor gave off by following this guide. But it wasn’t enough.
Then came the crash course in electromagnetic shielding and antennas:
The USB serial connection typically has 3 pins: Tx, Rx, and Ground. However, the Blue Pill and Raspberry Pi were already connected to the same ground because they were sharing the same power supply. The result: I had created a beautiful and large loop that is the perfect antenna for motor noise.
Once we removed this unnecessary ground, the robot’s future was getting brighter. Coincidently, so was the room we were in, because we had spent all night figuring out this problem and the sun was starting to rise.
You might be wondering why we opted for a USB serial instead of using the Raspy’s built in GPIO pins. Fair point, however the GPIO pins don’t have overvoltage protection and frankly I don’t trust my electronic taping skills very strongly.
5. Takeaways and Mistakes
I think the biggest takeaways from this project were not technical. They were to do with the organization of people in a small timescale project.
5.1. When it comes to Gantt charts and timing, you really don’t know what you don’t know. We found that it was rarely the technical challenges that impeded our progress, but instead all the “trivial” problems we didn’t foresee, such as dealing with library errors or setting up your environment, soldering things incorrectly, and integration. In this project I would say that finding and fixing small bugs took up more time than our actual engineering design work. This is not something I expected going into the project.
5.2. Stick to the agreed upon standards, even if it isn’t the “most logical” thing to do. I made this mistake and here I have to own up to it. The team decided upon a standard for the power rails on our breadboards ( I believe it was ground, 3v3, 5v from outside to inside). I realized while planning the new H-bridge design that if I swapped one of the rails, the circuit could look a lot cleaner and it would feel more “correct” to me. This decision was rash and lead to confusion amongst the team (and maybe a blown capacitor if I remember correctly).
5.3. Things that seem like great ideas due to the cool or clean/purity factor may not work that way in reality:
- We built the jointed arm because we thought it would be really cool to have it, therefore ignoring the additional challenges we took on and did not have time to properly implement.
- Our robot was meant to look clean and simple, and I think we succeeded on Hektar’s exterior. But, by making the external cute and compact, we were left trying to shove our all our circuits into the tiny box we had made (hence our resort to tape). The better solution would have been to make a larger chassis and create more room for circuits, sacrificing the cute small size for internal modularity and order.
- 5.2 was an example of me trying to make a cleaner design at the expense of design standards and modularity, and it ended up backfiring.
5.4. You can’t do it all. What is your goal here: To learn the most? To have the most innovative design? or to win [with a minimum viable product]? 5 weeks is not a long time. Our team chose to innovate and learn in the process, and the proof of that can be seen in the design of our robot. However, in a real engineering job (as my experience at Broadcom has shown) what matters is to deliver something that meets or exceeds the design specifications with the least amount of human/economic capital. Sometimes the best solution is not elegant or sophisticated. This was the truth that we decided to ignore for our project.
5.5. People aren’t robots: trust is everything and everybody has a distinct communication style. Often during times of tension there is no wrong person or perspective: the two are just speaking different languages. I encountered this with one of my group members. Some people like their ideas to be challenged head on. Others have a greater need to feel trusted (perhaps in the form of validation from the group) before an analysis of their work can be done. I see myself in the wrong for not recognizing this right away. At the end of the day, everybody has emotional needs and I believe your relationships are what matter far more than whatever work you can push out by yourself.
5.6. It can be a trap to spend too much time hypothesizing where problems may occur and not enough time running experiments to actually figure it out (though the contrary is also true). This is a trap I fell into, and this especially becomes a time sink when multiple opinions are involved. A failure during testing is not a waste of time or failure at all; it’s an invaluable resource.
5.7. Take more pictures. Document More.
5.8. Being calm is a skill and a strength.