.png)
MACRO PROJECT REPORT
This is the full report of the management, design process, and results of the MACRO project put together by myself, Grace Whitaker, Sam Vander Missen, and Jacob Whitehouse at Purdue University.
EXECUTIVE SUMMARY
Problem:
The project goal was to create a Mars cargo delivering rover (MACRO)prototype. It needed to be autonomous and to maneuver the diverse terrain of Mars while delivering cargo in a timely manner. The simulated environment required following solid, dashed, or dotted lines, overcoming obstacles, delivering cargo based on sensing of magnetic plates, and maintaining a set speed. Problems that arose from these goals were how to build a durable, but agile vehicle, how to carry and release various cargo objects, and how to implement decision making processes based on input from a variety of provided sensors.
Features:
The final prototype, consisting of lego mindstorm pieces; various sensors; and brick, grove, and raspberry pi kits; uniquely featured a rear-wheel drive power system, a modified forklift cargo system, and an alternating left-right turning method. Rear-wheel drive with two motors on the back wheels provided an efficient solution regarding power usage, a sufficient amount of torque to overcome obstacles, and an excellent travel speed. The modified forklift cargo system utilized a motorized lever arm lifting the cargo until it rested against a ramp. The arm with varied power outputs and pinch grip between the lift and a ramp provided flexible size, shape, and mass capacity. The alternating left-right turning method in our code solved line following and turning because once a line finding sensor lost the line, the rover would begin making alternating left-right turns until checking a roughly 180 degreerange. This offered versatility because of its wide range of checking.
Performance:
The final prototype performed moderately well. The MACRO carried cargo and overcame a wooden dowel in 3/3 trials. It accurately detected magnetic plates and dropped off the cargo in 1/1 trialsduring the delivery phase. It failed to follow a dotted line or overcome a hill with 0/4 trialsreaching completion. It inconsistently achieved the target speed test with 2/4 trials. Altogether the prototype could have been optimized with a refined line following method to address dashed and dotted lines and a redesign of our ultrasonic sensor mount which determines if the robot should speed up to overcome a hill or obstacle.
DESIGN CONSIDERATIONS
As in every engineering design process, the first step that we went through was defining the problem. This involved reading through the project description. We spent about a full meeting on going through this and identifying all deliverables, requirements, criteria, and other important details given to us. After taking this time, we knew exactly what we had to do and from here it was just a challenge of building a robot to satisfy all of the deliverables.
The next step, which regarded research, was very minimal. The only type of research that we did in terms of our robot was regarding the sensors and code for the software. We hadn’t ever used the arduino interface, so we had to look into the new syntax that we were dealing with. We also had to look up the specifics of the sensor given to us so we knew how they worked and how to incorporate them into a robot.
Step three in the design process regards defining our criteria and constraints. Since we had a timeline, we felt that our project management fell under this step. In setting up our project management, we put together the design specification review. One deliverable was creating a functional block diagram for the MACRO, so we put that together as shown below. This helped us define how the robot’s hardware would connect together along with the flow of the software throughout the entire system.
Project Schedule
Other deliverables in the design specification review focused on the management of our project. These deliverables included a work breakdown structure and a Gantt chart. We used these to set a tentative schedule and assigned people specific parts of the project, as you can see. This kept us on pace throughout the entire project to finish on time, and gave us an outline for what had to be done. Shown on the right is the main Gantt chart used in the planning and execution of our final project design.
Decision Making
We brainstormed and combined different solutions for each function to come up with a total of seven possible overall solutions. These were evaluated against our technical needs in a decision matrix. We ranked each customer need on an importance rating of one (being the least important) to ten (being the most important). We ranked each of the seven solutions based on how we thought it would satisfy each customer need. These values were percentages for a performance ranking, which we then multiplied by the importance factor to get a numerical value for each solution for each customer need. We summed our normalized values for each solution and got a total for each where a larger value corresponded to a design better suited to satisfy the customer needs. This resulted in solution six being our chosen design. This solution included a forklift for cargo, 4 wheels with 2 motors, and a line follower.
Flowcharting Algorithms
As we coded our MACRO to complete the tasks outlined in the executive summary, we found it helpful to flowchart the main functions of our code. Below are the flowcharts of the six main functions that allowed our MACRO to complete the assigned tasks.
Calibration and Testing
We began running tests and just changing slight values in the code to get the robot to most effectively get through the course and get through all obstacles. We kept the physical robot the same as it had been, in which will be described. The final robot included four wheels. Only the back two were motor powered because we needed an extra motor slot in the brick pi for the forklift motor. Also, the front two wheels were without tires because of the insane friction that prevented the robot from turning with front tires. The three sensors were mounted with legos at the front of the robot so that it sensed things before having to adjust the movement. It was hard to use any of the 3D printed mounts because these were super bulky and were hard to fit in the design without impeding on any other parts of the robot. Then, the pis sat in the middle of the rectangle base of the robot, supported by legos. The cargo system on the back is made up of 2 walls connected by a slanted ramp. There was a motor that made up the slanted ramp that was connected to a forklift. This forklift lifted up the cargo and would hold it against the ramp, between the walls built to carry the cargo. The ramp helped the cargo slide down and off of the robot when it was released, and the forklift helped hold the cargo up while the robot was moving. Our design seemed smaller and wider compared to other designs, as we believed that this was best for accurate movement of the robot.
The final code was modified a little bit just before testing in order to best adjust to the demo track. The original while loop was cut once the cargo was dropped off and a new while loop was then entered. This second while loop was the same as the first except it disregarded magnetic sensing and it allowed time after the line finder lost the line to check for a break. These changes were implemented because there were no magnets to detect after the cargo drop off and there were no breaks prior to drop off, they all happened after. This final code was our best shot at completing the demo track with accuracy and efficiency.
PHYSICAL ANALYSIS
Regarding the physical analysis for our MACRO, we decided to focus on testing a few main things. The first was maximum speed of our rover. The second was then the maximum rotational speed of our MACRO. We also evaluated the average distance and energy loss due to friction with the ground. A final test we did measured the consistency of the speed in relation to the mechanical power setting of the motors. This analysis allowed for a greater understanding of our MACRO's parameters and will be further discussed below.
Maximum Speed
For testing, we set up the robot at the end of a tape measure and set the power of the wheels’ motors up to 99, which is the highest power setting for the motors. We then let the robot travel along the tape measure with this power setting for five seconds, before recording how far the robot traveled in centimeters. After a series of five tests, we found an average travel distance of 332.75 cm.
Then, by using the equation for average speed we can plug in this average distance and divide by the travel time of five seconds. This results in a calculated average speed throughout the tests of 66.55 cm/s. In comparison, this speed value is over twice the maximum required speed for the speed test. So, this signifies that our robot outperforms the base standard for the MACRO speed, which had a range of 15 cm/s to 30 cm/s. This bodes well for a potential Mars rover in terms of travel distance and speed.
Maximum Rotational Speed
We found this speed by recording the amount of time the MACRO takes to make one full 360 degree turn, then calculating rotational speed based on that time. To perform the tests, we set the robot on the ground, and set the back wheels to spin in opposite directions at full power, before recording the time for a single revolution. After a series of five tests, we recorded an average time of 8.23 seconds. This confirms a rotation time of about 8.23 seconds for our MACRO.
Following this recording, we can use the equation for angular velocity to find an average velocity for our robot as it rotates.
So, we can set the angle of rotation as 360 degrees, or 2 pi radians. By dividing these values by 8.23 seconds, we find an average angular velocity of 43.74 degrees/sec, or 0.763 radians/sec.
In the context of a Mars rover, this rotation speed is perfect. This speed is not so slow that the rover turning would be inefficient, and it’s not so fast as to potentially endanger the cargo that the rover is currently carrying.
Frictional Losses
We began this calculation by doing a comparison of the distance the robot travels when it is and is not touching the ground. We first set the robot’s wheel motors at a lower output and placed a piece of paper on the outside of one of the robot’s wheels. Then, we let the robot run for five seconds and counted the number of full revolutions of the wheel. We then multiplied these values by the circumference of the wheel to find the theoretical distance traveled by the robot when it is not touching the ground. To complete the comparison, we held a series of five tests where the robot traveled along the ground with the same speed and motor power, and we recorded the distances the MACRO traveled. Finally, averages were taken for the distance traveled in air and the distance traveled on the ground, and the MACRO had a 21.74% distance loss when traveling on the ground as compared to the air. We can then validate this loss of distance using a theoretical mathematical model. By comparing the final energy values of the system between when the robot is on the ground versus mid air, we can observe the total amount of energy lost to friction. In this model we are assuming no other factors other than the motor power and the friction of the ground are affecting the energy of the system. Furthermore, the weight of a full Lego Mindstorms EV3 kit is about 2.2 lbs, so we can assume that the typical weight of a Lego Mindstorms robot is 2 lbs. Converting pounds grams, we find a value of 907.1 g for the MACRO. We are then able to find the final energy in the system as the robot is traveling at a fixed speed by using the equation for Linear Kinetic Energy.
Speed Consistency
To find the robot’s conversion values, we ran a series of trails where the robot’s motors were set to different mechanical power settings and the distance the robot traveled at that power over a period of five seconds was recorded. This distance and time was then used to calculate an average speed for each trial. Following the trials, the data was plotted on a graph, with the power setting set as the independent variable and the average speed set as the dependent variable. The plot reveals a nearly linear relationship between the power and speed, so a linear representation can be used to model this subsystem. By using the first and last points of the system, an average slope and therefore a point slope formula can be derived. Using this theoretical equation, we can predict the robot’s speed based on the power levels of the motors. For instance, if we increase the power level to the maximum of ninety-nine, the robot should be able to reach a ground speed of about 70.28 m/s. This value is very close to the value of maximum speed found in a previous specification, further supporting this analysis.
SCALING TO MARS
The prototype we have is a great base for a potential MACRO to be run on Mars, however, significant differences in the Mars environment will warrant some very crucial changes to the overall design. Some of the issues we may face include the gravitational difference on Mars, the atmospheric differences resulting in a difference in temperature, and the celestial differences on Mars that result in a severe lack of sunlight.
The gravity on the surface of Mars is much lower than it is on earth. The difference is by a factor of about 0.38, meaning that something weighing 100 kg on earth, would only weigh 38 kg on Mars. (Williams,2016) This would impact our design quite a bit, most importantly, our cargo pick up system. The way that the forklift works right now, The cargo could accidentally be launched above the robot and not be held in once the forklift activates, depending on the mass of the cargo it’s attempting to carry. One solution to this would be to build a casing around the top of the cargo section of the MACRO in order to hold the cargo in place. The difference in gravity could also impact the mobility of the MACRO. Lower gravity environments tend to cause higher amounts of wheel slippage according to research published by the Journal of Terramechanics. They also state that in low gravity settings “ the wheel mobility deteriorates due to the relative decrease in the driving force.” (Omine, 2009) This doesn’t necessarily require a design change but this factor does need to be taken into account when calculating the relationship between motor power, speed, and turnability.
The atmosphere of Mars makes for a much colder environment than earth’s. According to Sciencing, average temperature in the mid-latitudes is negative 50 degrees Celsius. One problem this creates is with the idea of power. Right now, we have a rechargeable battery powered system. Batteries lose their charge much quicker when exposed to that cold of environments. Typically, “a battery that provides 100 percent capacity at 27°C. will deliver only 50 percent at –18°C.” (“Discharging at High”, 2010). A potential way to resolve this issue would be to install multiple battery packs on the vehicle. These battery packs would be rechargeable by solar power so they could charge during the day and store energy for when it’s needed. The cold weather also suggests a need for materials used in the robot that can withstand that type of weather. If the MACRO is not made out of material suited to withstand extended periods of time in extreme cold, it will break down quicker and more often. One solution to this issue would be to use Kevlar. Kevlar is a synthetic fiber that is not very sensitive to temperature and could easily be utilized as a casing for the MACRO. Roboworld Molded Products LLC makes Robosuits that do in fact contain Kevlar for this reason. It has proven very effective in protecting sensitive parts of robots in extreme environments.
One other major concern is the position of Mars. Mars is much further from the sun than the earth is, so it gets less than half of the amount of sunlight that earth does. In addition to this, Mars’s well known dust storms are most common and much more likely to occur during perihelion. This is when Mars receives the most amount of sunlight, however these dust storms can block out the sun for days, weeks, or even months. The combination of these events results in a severe lack of consistent sunlight. Without the consistency of sunlight, using solar powered battery packs is an unreliable and frankly unrealistic choice, so power generation would have to be done in a different way. One possible solution to this issue, would be to have a field of solar panels connected to high capacity solar batteries that the MACRO can switch out when its power is running low. The only issue with this solution would be that the MACRO then has to return to a base frequently, potentially limiting the amount of exploration it could do. The more likely solution would just be to install more high capacity solar batteries within the MACRO. With the frequent dust storms, another concern, would be the line finding abilities of the vehicle. That ability would be severely hindered if the ground was covered in sand and dust from the most recent dust storm. The sensors would need to be updated to adjust to this sort of unpredictable weather, as our testing and results show that the MACRO’s ability to find a black line once it has lost it is minimal. This system in particular needs major improvement, along with gyroscopic ability of the ultrasonic sensor and the range of the hall sensor in regards to our navigation system.
Technical Specifications
The estimated volume of the prototype based on maximum length, maximum width, and maximum height is 11,389.95 cubic centimeters. The average estimated volume of a typical Mars rover, according to NASA is roughly 17,820,000 cubic centimeters, about the size of a compact car.(NASA, 2020) That size of rover has proven effective in the same conditions our MACRO will need to complete tasks in, so the prototype should likely be scaled up to a similar size. In order to make this happen, we will have to scale up the prototype volume by a factor of 1,564.537, and adjust the dimensions accordingly. The dimensions should not change between the testing at the Earth site and the runs on the Mars site. The wheel to body ratio will not be changed when moved to the Earth Site and the Mars site, so the wheel diameter will increase by the same factor as the rest of the dimensions.
As for materials to be used on the wheels of the MACRO, the earth site and mars site will be slightly different. For the earth site, titanium wheels will be used. This is because titanium tends to be much stronger than aluminum. Aluminum wheels are more likely to be damaged from terrain. One reason the MACRO would use aluminum wheels on Mars as opposed to this titanium is because of the extremely cold climate of Mars. Titanium in this temperature could become brittle.(Titanium,2020) Aluminum is also much less dense than titanium. Although the titanium would be stronger in tension, it would probably be more susceptible to tearing from a point load like driving over a sharp rock. This is something that could be avoided and even fixed easily at the Earth site, but less so on Mars. For the same reasons, titanium and aluminum will also be used for the main body build for the MACRO on earth and in mars respectively.
The weight of the vehicle, because it is using similar materials and has similar dimensions to the Mars rover Curiosity, should also have a relatively similar weight to Curiosity at about 900 kg. For the Earth site, the MACRO will be slightly heavier, as titanium is heavier than aluminum. According to Proto Labs, titanium is about two-thirds heavier than aluminum. Assuming that roughly 70 percent of our vehicle is made up of this metal, the weight should increase by a factor of 1.4667 for the Earth site MACRO. The weight on Mars is 38% of the weight on earth, as discussed earlier however, for clarity purposes, in the table below, the weight for the full scale Mars MACRO will be listed using its weight on Earth.
Resources for Scaling
." How Products Are Made. . Encyclopedia.com. 16 Oct. 2020 . (2020, November 21). Retrieved November 23, 2020, from https://www.encyclopedia.com/science-and-technology/chemistry/compounds-and-elements/titanium
Matthews, K., & Matthews, K. (2019, August 19). Materials to evaluate for designing and building robust robots. Retrieved November 23, 2020, from https://www.therobotreport.com/materials-rugged-robot-design-building/
Papiewski, J. (2019, March 02). Jupiter's Core vs. Earth's Core. Retrieved November 23, 2020, from https://sciencing.com/jupiters-core-vs-earths-core-21848.html
Kobayashi, Taizo & Fujiwara, Yoichiro & Yamakawa, Junya & Yasufuku, Noriyuki & Omine, Kiyoshi. (2010). Mobility performance of a rigid wheel in low gravity environments. Journal of Terramechanics. 47. 261-274. 10.1016/j.jterra.2009.12.001.
CONCLUSION AND RECOMMENDATIONS
Overall, our MACRO prototype performed very well in the cargo based aspect of the design challenge, but performed rather poorly in general course navigation. For the cargo, the robot consistently and accurately carried and dropped off the cargo, and the robot was able to accurately choose different paths based on magnetic detection. This reflects a well written code for magnetic detection and drop off along with a well built cargo carrier. However, for navigation, while the robot was able to follow a solid black line, the robot was unable to follow dotted lines or pass over the hill on the course. These results show that the robot needed a better sensing technique, since the current sensor set up and code led to the inability to follow the dotted lines and detect the hill. Furthermore, the robot was built too low, preventing the robot from passing over the hill on the chance that the robot managed to detect the hill.
Based on these findings, the first major improvement to make would be a new line following technique. A more accurate line finding technique could consist of using multiple sensors, such as two line finders on either side of the robot. This set up would limit the chances of the robot losing one of the black dots and never finding the next one, since a second line finder would increase the probability of the robot catching dots as it rotates and checks.
The second major improvement would be the general build of the robot. In its current state, the robot nearly touches the ground and drags against the ground at the top of the hill. If the robot was given at least an inch of clearance from the ground, all risk of dragging would be eliminated, increasing the consistency of the robot’s ability to clear the hill and removing the risk of dragging from added weight such as the cargo.
The third major improvement necessary for a second iteration of the robot is improved obstacle detection. While the ultrasonic sensor worked well for detecting and passing the dowel, it failed to detect the hill due to the angle of the hill. A potential fix for this could be to use the gyroscope abilities of the IMU sensor, then writing code so that the robot picks up speed when the front of the robot is tilted up, which would allow the robot to ramp up speed once it starts to attempt to traverse the hill.