The following report contains a record of what my group and I have done in the past four weeks working on the Planetary Rover. Here, the three sub teams worked together to build one working demo where a rover completed three missions around the Olin oval: navigating the “wasteland”, docking at a station, and payload dropping.
This report is divided into five sections. The thirst three explore the details of how the team designed and built the rover, focusing on the mechanical design, the electrical design, and the development of software to control this apparatus.
The last two sections focus on our rover’s actual performance during the demo and my contributions to the project. The first one highlights what went right and what went wrong on demo day, giving reasons why this could have happened, while the second provides a somewhat detailed list of what I have done in these last four weeks.
You can use content blocks to arrange your articles, large texts, instructions. Combine these blocks with media blocks to add illustrations and video tutorials. You can use various content blocks to work with your text. Add quotations, lists, buttons. Select your text to change its formatting or add links. Mobirise is a simple website builder that helps you create amazing web pages without knowing any code.
The first component we designed was the sensor suite. This was made out of Sentra board, and allowed us to mount all sensors in a way that allowed them to be used for their intended purpose. Shaped like the “hood” of the truck, the sensor suite featured five IR sensors vertically mounted at different headings spaced 30° apart. We actually came back later and revised the rightmost sensor, changing its angle to the ground so that it would hit it when the rover was 26 inches or more away from a wall or curb. Next, the pan/tilt turret, mounting a PiCam and 2 Sonar sensors, was attached to the horizontal part of the sensor suite. This was done to give us the option to orient these three input devices at different angles and headings. Finally, two hidden mounts were built on the inside of the shell. These were used to secure the Qwiic boards to the chassis.
Rover Main Body
The main body of the rover consisted of various 2D pieces cut out of Sentra board, assembled to provide anchor points for the sensor suite and the mounts for the other electronic components. As our initial idea was to have an arm on the side of the rover used for payload dropping and retrieving, a big part of the body was kept empty to create clearance for the payload and relative servos. When we iterated to a different design, this space remained empty, and was therefore used to hold the motor battery, initially placed under the chassis, for easier access. A hole was drilled in the “floor” to allow wires to pass through. At the back of the truck there is a housing for a battery for the logic components of the rover. This is in an enclosed space to keep it away from rain and water.
Rover Payload Claw
As the original idea was to be able to both deliver and retrieve the payload, a claw that opened and closed commanded by a servo was created. This was meant to be attached to an arm, which in turn was allowed by two servos to swing up and down and get closer to the ground. However, as the mission requirements changed, so did our plans for the claw. We decided to place it in front of the rover, using a metal part of the chassis as a mount for it.
The claw therefore consisted of three parts: a servo casing, an arm, and the chassis mount.
The casing was custom built to fit a HiTEC servo, providing a solid and reliable way of attaching it to the main body along with the chassis mount. The arm was designed to have interlocking gears. This was done so that, when the servo motor turned its “head” both arms would open or close equally. The payload was then placed in the middle of the two claws, from where it was easily dropped every time they opened.
The rover was built with two main circuits running in parallel: one for the logic side of the project, and one for the motors.
The first circuit had 4 servos and one motor. It was powered by a single 7.2V battery, connected to an E-Stop button for safety. This actually came in very handy later, as it allowed us to test our code without the rover actually moving around. After the E-Stop, the power was split between an Electronic Speed Control board and a power distribution board (PDB). The ESC is in turn connected again with the servo PDB, so that it can receive signals from the RPi. In fact, the PDB is connected to a PiHAT, thus allowing communication between the motors and the RPi. The PDB distributes power to all servo motors, enabling the steering, the claw, and the pan/tilt turret. It is important to notice that there are two kinds of servos on the rover, one running at 7.2V, and three running at 6V. This means that three servos are slightly overpowered. However, this is not enough to cause any damage to them.
This section of the circuit includes the Raspberry Pi and 8 forms of input (5 IR sensors, 2 Sonar, 1 PiCam). These are all connected to two Qwiic boards that provide power to them. One board is running 3 IRs and 1 Sonar, while the other one is running 2 IRs and 1 Sonar. In both of these boards, the sensors are wired so that they share a common pin for power and ground, but each has their own signal pin, allowing us to read each sensor individually. On the Qwiic boards, pin 3 has a potentiometer in it, which had to be adjusted in order to read the sensors properly. The two Qwiic boards then feed back to a connector on the PiHAT, allowing the sensors to connect to the RPi. The only input that is not connected this way is the PiCam, connected through a built-in ribbon connector directly on the Pi.
After working on the hardware side of the project, Esme and I decided to help out the software team. We identified the main behaviours needed to accomplish each of the missions and divided ourselves in groups to tackle these.
This mission can be divided into three main behaviours: a hardcoded turn, advancing towards a wall using feedback from IR sensors, and using sonar to follow a wall.
As we have encountered lots of issues making the robot understand where it currently is at the start of the mission, all missions started with a hardcoded part. In this case, the code makes the rover take a left turn towards the MAC, and then makes it go ahead for ~10 metres.
After getting closer to the wall, another piece of code will be running. This code will bring the rover to approximately 1.5 metres from the wall, and then make it turn to be parallel with it. This was done in an attempt to standardise the distance from the wall at which the rover would be at the start of the next section, as hardcoding it using time as a variable proved itself to be a very inconsistent method (affected by CPU usage, wifi connection, battery charge, etc…).
The following code shows the details of the SENSE_IR.m function. In order to make each iteration of the main loop as fast as possible, only the necessary essential sensors were read. However, to obtain a more reliable reading, multiple readings were carried out, and the average recorded. Once the voltage was read, this was passed through a previously determined linearising function to convert it to centimetres.
After making the right turn, and therefore being a set distance from the wall, the following lines of code were run. These measure the distance from the wall through the use of sonar sensors, and then determine whether the rover should turn right, left, or go straight to maintain a constant distance from the wall. This is done until the sonar returns a distance of 3 or more metres twice. This means that the wall isn’t there anymore, thus implying that we have reached the end of the course.
The readings from the sensors were obtained through the following function. This is essentially the same as the SENSE_IR function explained in the previous section, with the only differences of using sonar instead of IR, and therefore needing a different linearising function to convert from voltage to distance.
Once the previous function returned a distance, this was used to determine how to turn the wheels. Knowing a target distance from the wall and the distance we were at, the difference was taken and recorded. Then, the value ended into one of five categories, each with a different course-of-action to take. As a general rule, we can say that, the further away from the target distance, the sharper the turn taken to maintain the rover on track.
Taking such sharp turns, however, risked making the rover reach the wall at too sharp of an angle, and not being able to steer in time. We actually encountered this problem in testing, but realised that the benefits of having such sharp turns outweighed the chances of this happening, and therefore, given the time constraint, decided to go forwards with this idea.
This mission can be divided into five main behaviours: a hardcoded approach to the curb, following the curb using feedback from IR sensors, recognising an April Tag, path finding using image masking, and docking.
Again, a hardcoded approach was used to bring the rover to a rough position, from which autonomous behaviour could take over. In this case, this part consisted of something very similar to the first mission. Driving the rover forwards until it was close to the curb, and then turned sharply left to end up parallel to it. From here, the following behaviour took over.
This part is very similar to what was being done with sonar in Mission 1, where distances from an object were used to determine whether we should turn left or right. However, in this case, we actually measured whether the IR was seeing the ground or not. Knowing the angle at which the sensor was oriented, as well as it’s height, it was sufficient to use basic trigonometry to find the distance from the sensor to the ground. We then told the rover that, if it was seeing the ground, it was too far away from the curb, and therefore needed to turn right. However, if it saw anything else from the ground, it was too close to the curb, and needed to turn left.
The previous behaviour continued until we found an April Tag with an ID of 4, 5 or 6, meaning that it was a payload station. At this station, the rover took a right turn into the path leading to the center of the oval. From here, path finding using the camera and image masking was the main behaviour observed. The April Tags were read using the following function, which was given to us in the project documentation. This function outputs the center and id of any April Tag found, which is what was then used to determine if we were at the intersection or not.
Here, color masks are used to find a path across the Olin oval. After the right turn at the first intersection, the PiCam takes a picture for every iteration of the loop. The image is then analysed for any colors matching the previously masked ones, and any centroids identified are returned. As the buildings were a relatively similar color to the path, we decided to crop the image to ignore them.
Once the center of the path is identified, this is passed through another function to create the required brainwaves. Here, the function determines how left or right the center is on the image, converts it to an angle, and creates a normal distribution curve centered at this angle. This curve represents “how much” we want to go in any particular direction.
Here, the function that identifies the April Tags is used in a slightly different way. Once an April tag with an id from a docking station was read, the rover’s arbiter weighed this heavier than any other input, and therefore pushed the rover into that direction. The rover moved slowly in the direction of the dock until the front IR registered a distance of 8 inches or less. At that point, the rover was centered on the dock, and therefore stopped.
You can use content blocks to arrange your articles, large texts, instructions. Combine these blocks with media blocks to add illustrations and video tutorials. You can use various content blocks to work with your text. Add quotations, lists, buttons. Select your text to change its formatting or add links. Mobirise is a simple website builder that helps you create amazing web pages without knowing any code.
As the path that was going to be taken in this mission was the same as the one taken in the first half of the previous mission, the code used was exactly the same. It is therefore explained in the previous section.
For the following two parts of the mission, April tag recognition, approach and payload dropping, code from mission 2 was taken and adapted. The code is very similar, except for the fact that, instead of going towards a dock, the rover is going towards a payload dropping point, and instead of stopping once reached, it drops the payload.
Here, the rover is constantly checking its surroundings for an April tag with an ID of 4, 5 or 6. Once it sees this, the rover starts its approach towards it. As we know there will be no obstacles between the rover and the payload drop box, this behaviour takes precedence above all others. This continues until the rover is less than 20 inches from the dropbox.
Once the rover is close enough to the payload station, this will slow down and continue to move towards it. Once this was close enough to the box, a signal was sent to the servo controlling the arm telling it to open and release the payload.
Overall, I think our rover performed quite well on demo day. We had previously run the missions multiple times and were getting consistent results and errors (as with the wifi problem explained below). The night before demo day, our steering servo suddenly burned out, leaving us to recalibrate many parameters that were tailored for the previous motor. Although we managed to recreate most of the behaviours, there was still something, something that we were not able to point out, that made our rover behave slightly differently from what we wanted.
Mission 1 went pretty much as planned. The rover got out of the starting dock just fine, completed its left turn, and started advancing towards the glass wall of the MAC. Once about 1.5 metres away from the wall, the rover did a right turn and started advancing parallel to the wall. The autonomous behaviour worked throughout most of the mission, but failed when the RPi switched wifi routers. This happened in the same locations as in the practice runs, and we believe this issue could be solved by running code directly on the rover instead of wirelessly. Overall, the rover reached the end of the building and stopped accordingly, needing only one “readjustment” halfway through the course.
The second mission also worked out quite well. The rover was able to get out of the starting dock and advanced towards the curb, taking a sharp left turn just before it. It then proceeded with its autonomous behaviour until the first intersection where, at the sight of the April Tag, it decided to take a right onto the path in the middle of the O. Here, image masking was used for path finding, allowing the rover to get close enough to the final dock to recognise the April Tag and start docking maneuvers. At this point, the rover slowly advanced towards the dock, stopping when it was ~2 in from the wall. Overall, I think this mission went great. We only had to readjust the rover once during the first part, where one of the IR sensors protruding from the rover “clipped” one of the granite blocks, making the rover stuck.
The third mission worked out great. As with mission 2, the rover was able to get out of the dock and follow the curb autonomously. As the same code was used in both missions, the same errors showed up again. The rover clipped a wall once, and processing time increased by far when the rover switched between wifi routers. After reaching the intersection, the rover, instead of turning right, scanned for an April Tag, and started travelling in that direction. As with docking, the rover slowed down, stopping when it was close to the payload box’s wall, to then open the arm it had at the front and drop the payload.
My team decided to divide ourselves into three sub-teams: hardware, electrical, and software. Esme and I were responsible for the hardware part of the project, Liv and Jeremy for the electrical one, and Jaclyn, Shamama and Elvis for the software side of it.
The first thing we did was get all together to discuss the expectations and requirements for the rover. We defined what our goals were, and found a general way of meeting them. This was done so all sub-teams knew what their end-objective was, and did not come up with solutions that were not compatible with one another.
Then, Esme and I started working on the physical side of the rover design. We created a “crayola CAD”: a CAD document where rough versions of the components were placed with correct dimensions onto an assembly file, so that we had a clear idea of clearances and what went where. Once this was done, Esme took most of the digital CAD drawing, while I decided to focus on the mechanical fabrication and assembly of the parts Esme designed. This was true for most parts, except the payload dropper, which I decided to both design, prototype, and build on my own.
We actually finished quite early with the hardware side of the project. This was when we decided to help the software team,who was a little bit behind because of one of our team members not being able to make any more contributions to the team. Once Liv and Jeremy finished their section too, they also decided to help out on software.
The software side was a little chaotic at first, mostly because we were trying to figure out what worked and what didn’t. We were therefore trying out many different things on our own, all going in different directions. After a while, however, we decided to reconvene, and decided what was the best course of action. We developed “hard code” being able to complete all three missions, just in case we needed that as a backup, and then started programming the autonomous behaviour of the rover. Here, I focused mainly on the April Tag finding, running sensors, and approaching the dock. Obviously, each task came with its fair share of debugging. Overall, the rover ended up working mostly out of autonomous behaviour, except for the first part of all three missions, where we struggled making it understand where it was and move in the right direction. However, I am confident that, with time, we would have been able to solve this issue too and have a truly 100% autonomous rover.
HTML Website Generator