ECE 3400: Intelligent Physical Systems

Summary

In lab 4, we first set up RF communication between our robot and base station, then compiled the work we had done in previous labs and added more robust navigation in order to prepare for the Final Demo. During the Final Demo, we were expected to have the robot listen for a tone indicating it could start, autonomously navigate a maze we had not seen before, detect two treasures placed at random locations throughout the maze, and send the frequencies at which the treasure LEDs were blinking back to the base station using RF communication.

Part 1: RF Communication between Robot and Base Station

To start, we soldered pin headers and adapters to a custom PCB in order to connect the RF transcievers to the robot and base station breadboards. A diagram showing how this was done as well as an image of the final product on our robot are shown below.

Next, we ran the provided transmitter and receiver code, changing the frequency at which we were sending signals in order to avoid clashing with other groups' signals. We encountered some issues with this part of the lab but eventually found that the problem was a bad RF transciever. Once we finished this part of the lab, we combined this code with our seven-segment display code in order to display the values the base station was receiving.

Part 2: Preparation for the Final Demo

The next part of this lab was synthesizing everything we had done previously as well as implementing more robust navigation, including feedback control that would allow the robot to drive consistently as well as a search algorithm for the maze. After encountering some issues with interrupts when combining our code as well as receiving updated requirements (PID, DFS not required) for the Final Demo, we started from provided code that efficiently read and interpreted data from the ultrasonic sensors and built up from there. Because I primarily worked on navigation, I will be discussing the development of our feedback control algorithm and maze navigation algorithm.

To implement maze navigation, I started by making the ultrasonic sensor reading code as efficient as possible. The provided code took five measurements, replaced a five-element array, then calculated a median value. I made the code loop through a five-element array, constantly updating one value at a time and only calculating the median value of the array when required for the navigation of the robot. This reduced delays in sensing twofold, by cutting the time before which values in the array were updated by 1/5 as well as by calculating the median on-demand instead of separately from when the median values were needed.

Next, I had the robot drive forward and stop at a certain distance from the front wall to ensure the sensors and code were working correctly and consistently. Then, I began to implement right wall following by making the robot stop at a wall and choose to turn right unless there was a wall directly to the right of it, in which case it would turn left. After toying with the feedback control algorithm (described in the next subsection) for a while, I implemented something closer to true right wall following to ensure the robot could navigate the entire maze. In this algorithm, the robot would attempt to turn right twice unless the right wall was blocked for either of the two turns. This allowed the robot to turn 180 degrees around the right wall; however, due to time constraints and the inconsistency of the servos, I was not able to implement a true right wall following algorithm, as my algorithm relied on a front wall stopping the motion of the robot before it made attempts to turn.

After implementing a very basic navigation algorithm, I began to work on feedback control. PID was not required but I wanted to implement something that emulated aspects of PID, checking both how severe the error was and for how long the error had persisted. In this case, the error being corrected was the act of driving away from or towards the wall, not the absolute distance from the wall. The error was detected by taking the derivative of the robot's distance from the wall (computing the difference between last and current distance over time) to understand how rapidly the robot was moving towards or away from the wall. Then, the new error data was used in an iterative mean calculation, and that mean was used to determine how much the servo speeds changed. Therefore, under the condition that the robot was moving away from or towards a wall and had been doing so consistently for a sufficient amount of time, the robot would change its servo speeds to correct for that error.

Unfortunately, due to how inconsistent the servos were, we decided to move forward with a much simpler correction algorithm whose value by which to change the servo speeds was simply proportional to the error from the desired distance from the wall. Because problems with the servos arose without warning, it was difficult to tune or troubleshoot a more complex feedback control algorithm without being able to tell whether our algorithm or our hardware was causing issues with our robot's ability to drive. With a simple correction algorithm, we could very easily make the control system more sensitive by making it change the servo values more dramatically for each instance of error, which meant patterns of behavior caused by the algorithm (s-curves or small deviations from the desired distance from a wall) could easily be distinguished from hardware issues (the robot driving aggressively into the right wall).

Making the robot drive repeatably was by far the most challenging and time-consuming part of this lab. The servos were very sensitive to changes in battery voltage as well as the surface it drove on, which meant the functionality of our robot could change drastically within one work session and even between the mazes set up in the hallway and those inside the lab. However, these issues mostly impacted our robot's ability to turn correctly, as the turns were hard-coded for a certain duration. It was driving straight that caused the most issues. As briefly mentioned earlier, I tried to correct the robot's driving with a correction algorithm, but in the end, it was almost always problems with the servos that caused these issues. These issues likely stemmed from wear over time or from the robot running into walls, potentially damaging the servos. I found that the servos often went the same speed on both sides but would apply drastically different torque/power, causing the robot to turn no matter how much the servo speeds were changed to correct for these hardware differences. Throughout the course of this lab, we spent long amounts of time troubleshooting the issue of the robot driving into a wall, only to replace the batteries and servos multiple times.

Examples of these issues are shown below. To the left, the robot is shown slowly drifting to the left until it runs into a wall. This is an example of what was most likely a correction algorithm error; the robot was likely both placed too close to the wall at the start and was not programmed to have a sensitive enough correction algorithm to straighten again after the error was corrected. To the right, the robot is shown driving very aggressively into a wall, even in a very short stretch of the maze. Although this video demonstrates some of our navigation abilities, the turns are also very severe here. This is from moments after the first video and was found to be caused by bad servos.

Part 3: Final Demo

During the Final Demo, our robot unfortunately did not demonstrate some of the capabilities we had worked hard on. While minutes before the demo our robot was detecting and transmitting the correct treasure frequencies as well as navigating as expected, during the demo, our serial monitor began to show that no radio hardware was detected, and our robot's normally 90 degree turns were closer to 30. Luckily, our robot's radio hardware began to work again, and we were able to show outside of the maze that our robot was able to detect and transmit and that our base station could display the frequencies of the treasures. However, we did not have time to troubleshoot our robot's navigation during the demo timeslot.

Included below are pictures of our robot and base station.