Phone Controlled Robotic Arm and Car
This will serve as a brief description of your project. Limit this to three sentences because it can become overly long at that point. This copy should draw the user in and make she/him want to read more.
Area of Interest
Mechanical and Electrical Engineering
My third milestone was to build the car chassis, connect the arm and the rest of the project to the car, and configure all of the necessary wiring. I had little trouble assembling the chassis, but attaching everything to the chassis was slightly more complicated. The challenges that I faced while trying to fasten everything to the chassis stemmed from the fact that it was far too small to fit the many parts of the robotic arm, which included the Arduino, breadboard, power supply, and the arm itself. I also had to attach the battery pack and motor driver that would power and control the motors for the wheels of the car. Additionally, I needed to ensure that all the parts could be properly wired without interfering with each other.
When first approaching the problem, I immediately tried to think of ways to eliminate unnecessary bulk, and I was able to come up with two solid methods to reduce the size of some of the parts. These two methods were to chop off the back half of the robotic arm’s base and to rewire everything onto a mini breadboard instead of the regular-sized one. I found these ideas to be optimal, as I realized that the back of the robotic arm base, which would normally hold the Arduino or breadboard, would be unnecessary with the implementation of the car. Additionally, I noticed that I was using less than half of the rows on the regular breadboard and would be able to fit everything onto a much smaller board even with the additional wiring for the car’s motors.
However, even with these changes, there were still too many parts to fit on the chassis. After looking at the available space, I devised a layout that incorporated the underside of the chassis. I decided to split the parts into two groups: those related to the cars’ DC motors and those related to the arm’s servo motors. I bolted the first group to the bottom and the second group to the top of the chassis, since the car motors had to be on the bottom and the arm had to be on the top. I also included the breadboard and Arduino in the second group, as this would make it easier to set up and modify the wiring.
Thanks to my planning, configuring the wiring was relatively straightforward. Since I had already hooked up the servos and bluetooth module to the Arduino on the large breadboard, I simply rewired them onto the smaller breadboard in a more organized version. I then wired the DC motors with the Arduino, battery pack, and L298N motor driver, which required me to learn how the L298N works. The L298N uses two H-bridge circuits to control the motors’ directions, while the Arduino uses pulse-width modulation, which I discuss in my milestone 1 documentation, to control the motors’ speeds.
As you can see in the image to the left, H-bridge circuits are capable of manipulating the direction that current flows through a DC motor. In this diagram, closing the bottom left and top right switches will cause current to flow from the right to the left side of the motor, and closing the top left and bottom right switches will cause current to flow through the motor in the opposite direction. This reversal changes the direction in which the motor spins.
As for the L298N wiring,
The reset button would send four commands as one.
Bluetooth messages would sometimes be truncated or separated.
Arduino program joining truncated commands and separating connected commands
Phone application in action
My second milestone was to create a working phone application that could thoroughly control the robotic arm; in other words, it was to complete the base project. To accomplish this, I programmed a phone application with sliders and buttons that would send a variety of instructions to the Arduino over Bluetooth. I then wrote an Arduino program that would allow the Arduino to interpret these instructions and use them to manipulate the servos in the arm.
Though I had little difficulty programming each of them individually, I ran into numerous problems when trying to integrate the two programs. As I state in the video, the servos made very twitchy movements when changing position during my initial testings of the phone app. By running simplified versions of the phone app and having the Arduino print the data it received from the phone, I was able to identify the Bluetooth connection as the problem, as the phone outputs and Arduino inputs were vastly different. After digging through my Arduino code and doing some research on Bluetooth, I found that I had set the wrong baud rate for the Arduino, which caused corruption in the data it received. After fixing the baud rate, it became significantly easier to identify other issues, both with the Arduino code and the phone app code, since the phone output now lined up with the Arduino input.
The limitations of Bluetooth caused the majority of my programs’ issues. The greatest of these issues caused the servos to sometimes move to a completely incorrect position when I moved the sliders or pressed a button. What made this error confusing was that it could occur during changes to any of the servos, sliders, and buttons, but it would happen randomly and infrequently. However, certain actions such as holding down a slider or pressing the reset button, which I designed to reset all of the servo positions back to their default/starting positions when pressed, would trigger this error more frequently. I once again printed the Bluetooth signals received by the Arduino to the monitor and went through the process step-by-step, and I discovered that the Arduino would sometimes either join together or truncate Bluetooth messages.
For example, when the reset button was pressed, the Arduino would read the commands for all of the servos as one command instead of four separate commands. I hypothesized that this issue occurred because the app was sending the data to the Arduino faster than it could distinguish between different commands. To further explain, the setTimeout method sets the amount of time that the Arduino will wait before cutting off the signal and waiting for a new command. Even though I had set this to one millisecond, the phone app would sometimes send multiple commands to the Arduino within this timeframe, which caused the Arduino to read them as one long command. This was the reason that holding down on the sliders would also cause this error to occur, since holding down on the sliders sends many commands in a short time frame. As for the truncation, I realized that this was happening because the Arduino would sometimes refresh the Bluetooth in the middle of receiving a signal, which would result in that signal being chopped in two.
To solve these issues, I first added a semicolon to the end of each Bluetooth output from App Inventor. I then wrote code into the Arduino program that would find the semicolons and use them to separate each Bluetooth message before executing them. If the program did not find a semicolon, it meant that the message was truncated, in which case the program would store the truncated command and join it with its second half. I have included pictures of what all of this looks like on the left (phoneOutput is the original Bluetooth message, outputN is what’s executed).
The issues I had with my code while working towards this milestone improved my debugging skills and taught me the importance of solving one problem at a time and analyzing each step of a program. I also learned a great deal about how Bluetooth works and how computers interact with it while working through these problems. In particular, I gained a much better understanding of how the computer treats and recognizes Bluetooth data from analyzing and solving the last problem that I discussed. Finally, I also learned how to use GitHub to upload and share code.
My first milestone was to assemble the robot arm with the servos, configure the wiring of the servos and Arduino, program the Arduino with test code, and run this code to ensure that the arm would move properly. I had no major issues with building the arm or wiring the servos and Arduino on the breadboard, but I encountered a few minor ones, which I highlight in the video. The greatest of these issues was overheating one of the servos while testing some programs that I was thinking of incorporating into my Arduino code. After the servo overheated, I realized that the servo was stalling as a result of a specific limitation of the mechanical design, not an issue with my code.
This mistake caused no permanent damage, but it served as an important reminder to be patient and not try to force progress and rush the problem solving process. If a program isn’t working, I now spend more time analyzing the issue before running it again, instead of continuously running the program while trying to quickly fix it. I also learned about pulse-width modulation (PWM), which is used to control the servos. First of all, Arduino uses digital signals, which can be set to 2 values: on or off. When using PWM, the Arduino simulates analog signals (which can be set to any value between on and off) by quickly switching on and off the voltage sent to each servo. This allows the Arduino to better control the voltage and current being sent to each servo, as it can increase the duty cycle (the ratio of on time to off time) in order to increase voltage/current and decrease the duty cycle to decrease voltage/current. By doing this, the Arduino can write the servos’ positions to precise degree measurements, instead of only being able to write them to 0 or 180 degrees.
Robot Arm – Right Side View hover for details
Robot Arm – Left Side View hover for details
Wiring as of Milestone One
Project as of Milestone One