FINAL REPORT
Each UCF Senior Design team was required to write and submit many milestone documents throughout the duration of their projects to document progress. On this page you will find our final report for our Senior Design 2 course.
Final Report
for
Aeroject Autonomous Rover
ADIONA
VERSION
Milestone 6
April 25, 2022
PREPARED BY
Alexander Davis (Mechanical Engineering)
Lauren Bravine (Computer Engineering)
Dillon Burns (Computer Science)
Charles McCampbell-Hill (Computer Science)
Jacob Sage (Computer Science)
Daniel Volpe (Computer Science)
FACULTY ADVISOR
Dr. Felix Soto Toro
SPONSOR
Aerojet
Executive Summary
With the rise of many private spaceflight companies such as SpaceX, Blue Origin, and Virgin Galactic, space travel has become far more common and accessible than ever before. With the new competition in space travel, creating sophisticated technology with the intent of celestial exploration is critical and will soon be necessary as humanity inevitably begins to visit, and perhaps inhabit, new planets and even other moons.
Our project attempts to address this need for technology capable of traversing an unknown environment. Adiona is an autonomous rover project sponsored by Aerojet with the intention of participating in the Friends of Amateur Rocketry (FAR) competition. Named after the Greek goddess of safe return, Adiona’s objective is to, after being deployed by a rocket mid-flight, safely land and return to the launch site without human intervention. In other words, the objective of the project is to create a rover that can autonomously navigate through an unknown environment wherever it may be placed. Whether located in an environment with large obstacles, such as rocks or plants, or an environment where the terrain is difficult - or even dangerous - to traverse, Adiona is set to have the hardware and software required to overcome such challenges and successfully navigate to its destination.
With regards to software, the entire project is completed in Python while utilizing technology like Robot Operating System (ROS) and various Computer Vision libraries such as OpenCV and DepthAI (a Computer Vision library dedicated to the rover’s camera, the OAK-D) to act as a bridge between the rover and its environment. To meet the rocket’s limited canister size requirements, the final rover design consists of four wide wheels with the ability to fold inward while in the compact space, that can then expand once the rover has left the canister. Lastly, a transmitter and receiver will be used in conjunction with the OAK-D to provide a live video feed to home base during the mission.
Table of Contents
Executive Summary
Table of Contents
List of Figures
List of Tables
Revision History
Glossary
1. Intro
1.1 History & Justification
1.2 End User Needs
1.3 Problem Addressed
2. Project Objectives and Scope
2.1 Semester
2.2 Long Term
3. Existing Technologies and Standards
4. Professional and Societal Considerations
5. System Requirements and Design Constraints
5.1 Live Video Feed
5.2 Object Avoidance
5.3 Pathfinding
5.4 Power and Data Distribution
5.5 Locomotion
5.6 On Board Power
6. System Concept Development
6.1 MK Evolution
6.1.1 MK I
6.1.2 MK II
6.1.3 MK III
7. Design Analysis
7.1 System Concept
7.2 System Visualization & Planning
7.3 Fundamental Engineering Principles
7.4 Boundary Constraints
7.5 Prototyping and Testing
7.6 Analytical Models and Engineering Calculations
7.6.1 Analytical Models - Size Constraints
8. Final Design and Engineering Specifications
8.1 Discrete Components
8.2 On Board Power
8.3 Video and Computer Vision
8.4 “Long Lead Time” Components
8.5 Development Critical Path
9. System Evaluation
9.1 Failure Modes and Mechanisms
9.1.1 Chassis
9.1.2 Power
9.1.3 Wheels & Movement (axles, servo, motor, motor controller, encoder, raspberry pi)
9.1.4 Navigation (GPS and Lidar) & Visibility (Transmitter and Oak-D)
9.1.5 Canister
9.2 Risk Severity
10. Significant Accomplishments and Open Issues
10.1 Unperformed Planned Tests
10.2 Future Design Change Recommendations
11. Conclusions and Recommendations
References
Appendix A: Customer Requirements
A.a Competition Requirements
A.a.1 All Competition Requirements
A.a.2 Competition Requirements ~ Regarding Payload
A.b Competition Scoring
A.b.1 Scoring
A.b.2 Scoring Bonuses
A.b.3 Point bonuses for payload selection
A.c Judging
A.d Deliverables
A.e Arcturus Team
A.f Our Team
Appendix B: System Evaluation Plan
B.1 Power
B.2 Motors
B.3 Structural Components (Chassis & Mounts)
Appendix C: User Manual
C.1 Parts & Specs
C.1.1 Motor: Jrelecs 3674 BLAC Motor
C.1.2 Electronic Speed Control: Odrive V3.6
C.1.3 Encoder: CUI AMT102-V
C.1.4 Battery: Zeee 4S Lipo
C.1.5 Camera: OAK-D
C.1.6 Transmitter: Immersion RC 2.4GHz 700mw A/V
C.1.7 Receiver: BosCam RC802 2.4GHz Wireless AV
C.1.8 Computer: Raspberry Pi 4 Model B
C.2 Steps
Appendix D: Cost and Manufacturability Analysis
Appendix E: Expense Report
Appendix F: Manuals and Important Documents
Appendix G: Design Competencies
Figure 1: UCF Autonomous Shuttles
Figure 2. Ending snapshot of the team’s Gantt chart
Figure 3. Adiona’s rigid front (left) and rear (right) axles
Figure 4. Gearing layout plan with possible differential orientations and resulting movements
Figure 5. 3D Printed vs. Salvaged Injection Molded Counterpart
Figure 6. Odrive’s PID cascade loop
Figure 7. How Gains Affect a System
Figure 8. Internal Canister Dimensions
Figure 9. Canister Height Dimensions
Figure 10. Internal Canister Visual
Figure 11. Canister Height/Internal Measurement Visual
Figure 12. Jrelecs 3674 BLAC Motor
Figure 13. Odrive
Figure 14. CUI AMT102-V
Figure 15. Zeee 4S Lipo
Figure 16. OAK-D
Figure 17. Transmitter
Figure 18. Receiver
Figure 19. Raspberry Pi 4 Model B
Figure 20. Connection 1.1, Odrive-Motor
Figure 21. Connection 1.2, Odrive-Motor
Figure 22. Connection 3.1, Odrive J4 Pins
Figure 23. Connection 3.2, Encoder Pins
Figure 24. Odrive USB
Figure 25. Connections 9 & 11, Raspberry Pi USBs
Figure 26. Connection 7, LiDAR
Figure 27. Connection 5, Battery
Figure 28. Odrive/Battery Mount
Version | Date | Name | Reason for Changes |
|---|---|---|---|
2.5 | 4/25/22 | Alex | Updated figure list and sections for m6 |
2.4 | 4/20/22 | Lauren | Adding components to fill for m6 requirements |
2.3 | 4/9/22 | Lauren | MK II updated and MK III introduced |
2.2 | 4/1/22 | Lauren | Added M5 |
1.0 | 12/15/21 | N/A | Initial document. |
2.0 | 2/25/22 | Alex | Included Information from M4 |
2.1 | 3/1/22 | Alex | Included Information from MK II Revision |
1. Intro
1.1 History & Justification
Space travel is becoming more accessible every year. As a result, inventions whose purpose is to explore space and it’s inhabiting bodies are increasing at the same rate. This rover is a demonstration of the technology and the design considerations that should be considered when constructing a vehicle that is to be used for lunar or planetary autonomous landscape surveying and exploration.
Some use-cases include:
-
Object / sample retrieval.
-
Package delivery system from a smaller base to a larger home base.
-
Autonomous vehicles that return explorers back to base after a research mission
-
Ability to see and access locations in space that would be difficult for a human to reach
In addition, autonomous vehicles are quickly becoming more common and attainable here on Earth in our everyday lives. While our research and applications are not quite advanced enough yet to be able to rely on them without any human interference, projects like ours are paving the way for a future where autonomous ground vehicles are one of the many conveniences we’ve created for ourselves, taken for granted as we do now with the computer.
These vehicles could prove advantageous for a variety of reasons, like the convenience factor of getting places without needing a driver, traffic efficiency, or having items delivered to your location without moving a muscle. They also provide safety features like a decrease in crash rates on the road, and environmental improvement since these vehicles are often electric and can reduce toxic emissions.
There are many organizations already trying to take advantage of these possibilities: car companies like Tesla, robotics companies, and even UCF. A recent addition to UCF campus is a free driverless shuttle [Figure 1] that drives along a predefined path through campus [1]. This allows students to travel between buildings with ease without needing a driver to sit in the shuttle all day.
Figure 1: UCF Autonomous Shuttles [2]
Since our rover’s primary mission is to return safely to the rocket’s launch pad, we have named it Adiona [3]. This name comes from the Roman goddess of safe return. The name originates from Latin, with the word adeo meaning “to approach or visit” and “to take possession of one’s inheritance”. This has come to be translated as coming home. The goddess is believed to provide travelers protection, which is precisely what our rover will need on its way home.
Another goddess with a closely related purpose is Abeona, the goddess of outward journeys [4]. She is known to protect travelers as well, but on their way out. Her name is taken from the Latin word abeo, meaning “to depart, go away, or go forth”. Seeing as our canister and sled assembly will have the sole purpose of getting our rover on the ground safely, this is what we have decided to call them.
When beginning our senior design course, each member of our team came in looking for a project that would give them the opportunity to display an impressive showcase of everything they have learned throughout their college career, as well as to learn something new to add to resumes. This project provided the perfect chance to do this. It has allowed us to get experience working with a team and taking advantage of a variety of skill sets and knowledge, figuring out how best to use each person's abilities and organize our work.
Since this rover includes a combination of hardware and software, we also all got to get our hands dirty in a variation of new fields we may not have gotten to encounter otherwise. We have designed a website [6] to display our work and everything new we have learned along the way. This will make it convenient for potential employers to see what we have accomplished.
The project was challenging but we chose it so we could compete and push our limits to excel among other payload and rocket teams. We were motivated to give an impressive representation of our school and team, with the added bonus of winning a trip to California if we get past the other payload teams to join Arcturus in the FAR competition, and a financial reward if we reach first place within that competition.
1.2 End User Needs
Our end user is a combination of the rocket team - Arcturus, and our sponsor - Aerojet. More about the exact requirements needed by them can be found in appendix A, but the basics include the following:
-
Small rover to fit in canister dimensions
-
Live video feed
-
Object avoidance
-
Path finding
-
Power and data distribution
-
Enough on-board power available for large/powerful components
1.3 Problem Addressed
Two companies in particular who have recognized the opportunities described in section 1.1 include FAR and Aerojet Rocketdyne Coleman Aerospace. They have noticed problems our society faces that could be reconciled with the possibilities that our autonomous rover can create.
FAR stands for Friends of Amateur Rocketry, Inc. They are an organization that promotes STEM education and advancement. [5] One of the ways they do this is through competitions, or launch contests, including the one we are competing in, called FAR 51025 [Appendix C]. They have organized this competition to give engineers and enthusiasts a chance to show what they can design and build in order to send a rocket containing a payload 10,000 feet into the air and successfully have it complete its mission.
Aerojet has also become aware of this contest and has taken it upon themselves to sponsor several UCF senior design teams to join together to compete.
There are a variety of payload options that can be taken to the competition alongside the rocket, all of which are being constructed by senior design teams who will compete internally for the chance to attend. By now it should be clear that the payload our team is designing is an autonomous rover which we have dubbed Adiona. If chosen, our rover will add 3000 points to the overall score for the UCF/Aerojet team. When we are finished, our rover will include the ability to autonomously return to the launch site while using object detection to avoid obstacles while transmitting a live video feed.
2. Project Objectives and Scope
2.1 Semester
To keep track of our objectives and when we wanted them completed, our team made use of a gantt chart.
Figure 2. Ending snapshot of the team’s Gantt chart
The main goals of this semester, after so much planning in senior design 1, mostly included execution of those plans. We needed to:
-
Build the rover chassis
-
Make connections and mounts for all components
-
Configure/program our motor, encoder, and motor controller
-
Integrate our physical rover with our software.
3. Existing Technologies and Standards
One obvious professional industry relevant to our project includes our sponsor, Aerojet. This company is a dominant part of today’s aerospace and defense industry. In regards to space, their work relevant to our project includes: “a full range of propulsion and power systems for launch vehicles, satellites and other space vehicles; strategic missiles; missile defense; and tactical systems and armaments” [7]. Aerojet and companies like them who are involved in space advancements, including NASA, SpaceX, and more could greatly benefit from more research and documentation on autonomous rovers.
Others who perform similar studies to ours include companies that build autonomous devices. These are becoming much more prevalent and could be the next big milestone of our technological evolution.
4. Professional and Societal Considerations
Companies like NASA and SpaceX who perform research in space could find a lot of benefit in purchasing a product like our rover for astronauts to use on a mission to space. This could help them travel farther than the astronauts would be able to themselves to gather samples and photos or videos with the ability to return to them without any work on the astronaut’s part, allowing them to continue with other important work simultaneously.
Rovers like ours could also be used to travel to places on Earth that are hostile to humans and that we would not have any access to otherwise. With the ability to avoid harmful objects and a robust enough design to endure many circumstances a human would not be able to survive - like heat for example - Adiona could be sent to new and exotic places that would be impossible to explore otherwise.
Seeing that our rover will use object identification and be adept in traveling through desert terrain, Adiona could also be a great opportunity for an autonomous desert search and rescue system to locate lost or missing people in the desert. With so many craters and cliffs, plus the extensiveness of land in desert environments, it can be incredibly difficult to locate a person who has lost their way or fallen far below the visible surface on land. Huge amounts of resources, time, and people could search for days and find nothing. With access to a rover that does not need food or water, can identify objects and people, can fit into small crevices to search, and also can transmit live data, many lives could be saved.
5. System Requirements and Design Constraints
Since our overall project goal was to succeed in the FAR 51025 competition, many of our needs were explicitly laid out for us by the rules of the competition. Any violation of these rules would disqualify us resulting in complete failure of our project purpose. While we will ultimately be our own users; Aerojet, UCF, and the rocket teams that we are collaborating with are all invested in our success and as such are akin to stakeholders for us.
This competition required a rocket, as well as at least one payload addition. Due to financial constraints, our senior design class was only able to send one payload group along with the two groups that are building our rocket in tandem. This added an internal competitive element to our group of senior design teams working on this project as a whole. With six other teams also building payloads, our team’s needs expanded not only to those requested by FAR and the rocket design, but also to be creative and impressive enough to add components to our design that give us the ability to outshine other payload teams in order to qualify to join our peers in the final competition.
The needs required by the FAR competition given to us included the following:
-
Minimum 2.2-lb (1.0 kg) payload.
-
Must be removable as a separate unit from the airframe
-
Minimum 3” (75-mm) airframe
-
No component should exceed 100 ft / sec during recovery
-
A rover that returns autonomously to designated launchpad with live video
As can be seen from the list above, our payload competition requirements are not too extensive. This is because the main component of our competition entry is the rocket being designed and built by our senior design Aucturus group peers. Though their group has many more restrictions than ours, this causes design constraints from them that we are also forced to observe. Some are new needs caused by the way the Arcturus team decided to construct certain elements, and some cause even tighter or more specific restraints on the needs already set forth by the competition. These needs include the following:
5.1 Live Video Feed
Our payload not only has to navigate by itself, but is also required to transmit a live video feed. We used a transmitter and camera on board to accomplish this. In addition, the transmitter used a receiver to send the data to so that we could watch the broadcast from our location once the rocket is launched. This transmission had to be able to operate over a long distance since the rover could be dropped up to a mile away, and outside of the frequency ranges of 420 - 450 MHz, and 1-2 GHz which are being used by the Arcturus team. Additionally the signal may have needed to be processed to remove interference from the rocket telemetry that is communication over the forbidden frequencies.
5.2 Object Avoidance
To autonomously navigate back to base through the Mojave landscape, Adeona needed the ability to recognize what lies in front of her, determine whether she will be able to proceed through/over it and if not, automatically route and maneuver around it. The most common hurdles in the Mojave include holes in the ground dug by animals, rocks, and bushes or plants too big for us to roll over. This information has been obtained through inquiries with FAR representatives, and images found on google maps of the competition location.
5.3 Pathfinding
The primary feature of our rover is the ability to autonomously navigate back to the rocket launch site. This means that our rover needs to be aware of where it is at all times in relation to the launch site. This required the use of a GPS system so that it can find both positions and calculate the best path between. It needs to combine this location information with its object avoidance functionality so that it can find a path through the desert that does not cause it to get stuck or harmed. This may result in a path that is not straight or fast, but we will still need to ensure its efficiency given all these requirements since we have a limited amount of power that it can hold at once.
5.4 Power and Data Distribution
Since our battery does not have the same voltage output as the input our components require, and they also need to transmit and receive data amongst themselves, our rover required a power distribution system and a set of connections for delivering data between sensors and components. Elements that require an energy supply include the following:
-
Raspberry Pi
-
OAK-D camera
-
Transmitter
-
Motor Controllers
The same parts also need to send and receive data. The OAK-D camera needs to report the object detection and distance statistics to the raspberry pi to determine how best to use that information, and also to send video to the transmitter for the live feed requirement. The Raspberry Pi has to take in the data from the OAK-D and tell the ESCs how to move in response to the surrounding environment being observed.
5.5 Locomotion
There are a few drawbacks we had to consider when designing our rovers method of locomotion. One was the sandy environment, and another was the size restrictions.
To operate through the sandy terrain, our wheels had to include an appropriate tread pattern and be wide enough that they could grip the granular earth.
This requirement and our canister size requirement unfortunately do not go hand-in-hand. While keeping our wheels big enough to easily move through sand, we also need them to be small enough to fit into our small canister. This required either a compromise on the tire width, or the availability of movement on the tires that allow them to take up unused space within the length of the canister.
5.6 On Board Power
One of the requirements set for us by the Arcturus team included on-board power to supply our rover with energy. To power our mechanics ourselves, we needed to consider:
-
how many components need energy
-
how much energy they each need
-
how long each function needs to last for
After discovering that we could land up to a mile away from the launch site rather than our initial assumption of 400 ft, we had to take extra precaution to be sure that we could supply enough power to last throughout the entire journey.
6. System Concept Development
As our design restrictions tightened month by month due to issues with our budget and procurement, Adiona went through three distinct major design iterations which we will refer to as MKI-III throughout this section.
MK I was the original four motor design illustrated earlier and in our previous design concept report. MK II maintained four wheel drive but using only two motors instead, one for the front axle and one for the rear. Finally, MK III was our attempt at keeping four wheel drive but shifting to only a single brushless motor. To best illustrate the logic behind these major changes, we’ve overlaid important design and procurement events with brief explanations where necessary.
11/23/21 MK I Design finished and production began. Ordered OAK-D, motors, ESCs, and batteries.
1/13/22 Received response. Parts arrived, tested, the motors and ESCs are returned
1/31/22 Ordered O-Drive motor controller for better motor control
2/21/22 Ordered LiDAR and motors that meet our specifications
2/21/22 Order denied. Out of budget at $479, expected budget was slightly under $2000 and planned spending was $700.
2/21/22 MK II Begins: To save money the rover was redesigned to utilize two brushless motors instead of four. After petitioning for more budget our order is approved.
3/3/22 Procurement informed us that the motor was out of stock now, and to advise for further instructions. Procurement is instructed to cancel the motor order and proceed with just LiDAR and the encoder.
3/18/22 Inquired with procurement about status of previous order. No response.
3/23/22 Inquired again about the previous order, in case the order wasn’t placed a new form was made with all in-stock components including motors.
3/24/22 Received amazon receipt from procurement for all components.
3/24/22 Inquired about the previous order to make sure that we don’t end up with two if they were already ordered.
3/24/22 Procurement asks us if we know that we’re over budget.
3/25/22 Informed procurement that the parts were approved in a previous order and inquired if they were approved by accident. Inquired again if we had two LiDAR sensors on order so we know if one needs to be canceled or if one is ready for pickup. No response.
4/07/22 MK III Begins: Design must now be adapted to only one motor. After visiting the procurement office in person, several packages were ready for our team, none of which we were emailed about (some of which had been there since February). Just like we were concerned about, there were 2 LiDAR sensors and for some reason only 1 motor.
6.1 MK Evolution
6.1.1 MK I
As stated earlier, MK I was a combined wheel leg approach. Each wheel had a motor inside the wheel and by attaching each wheel to a folding leg, the rover is able to alternate between an operating orientation and minimum-volume orientation. The minimum volume orientation took advantage of the relatively long canister to fit larger wheels for a larger contact patch with the sand to reduce the chance of slipping. The folding mechanism was spring-loaded and not only gave us the motion we desired but allowed us to increase our break-over angle so that we would be able to drive ourselves out of animal holes without worrying about our chassis hitting the ground. Additionally, this mechanism functioned as our suspension with the only problem being the planar motion resulted in a slight rotation of the wheel. If we wanted our wheels to not be cambered upon deployment we had to pre-rotate them in our design so that the rotation simply brought them back parallel to the ground. The main problem with this design was the motors and motor controllers. Using traditional ESCs and brushless quadcopter motors we could control our motor’s speed only over a specified throttleable range. Even at the lowest throttle setting these relatively low KV motors spun much too fast and even with planetary gears inside the wheels we were moving too fast for the software to keep up. Additionally, at low speeds, our ESC dissipated all excess voltage as heat which not only wasted energy but generated quite a lot of heat.
6.1.2 MK II
This two motor iteration connected each motor to a bevel gear that spun either the front or rear axle. The 170 KV motors in this iteration spun much slower than their MK I counterparts but even with a 1:2 bevel gear teeth ratio on the front axle we still had a minimum linear velocity of about 5 mph which again was too fast for our software to keep up with. Additionally the rigid front axle greatly limited the size of wheels that we could fit in our canister.
Figure 3. Adiona’s rigid front (left) and rear (right) axles
As a result this design changed slightly, first we added space for a rotary encoder which in combination with our O-Drive motor controller would give us precise position and velocity control over our entire voltage range. Then we cut our rigid axle and fed each end into universal drive shafts that we salvaged from other rc cars. This allowed us to transmit torque from the central bevel gears to the wheels while also allowing our wheels to fold upwards for storage to fit in the canister.
6.1.3 MK III
This design keeps the front and back bevel gears but connects them with a long rigid shaft which we can power with just a single motor. To ensure the wheels rotate in the same direction the bevel gears on each end need to connect on opposite sides as shown below.
Figure 4. Gearing layout plan with possible differential orientations and resulting movements
We chose the convention that clockwise rotation should result in negative -x translation and installed our bevel gears accordingly. One improvement made to these bevel gears in particular was the inclusion of gear differential assemblies so that during turning our inner wheels are allowed to rotate at different speeds without slipping. There are a total of 6 main gears in our assembly not including the planetary bevel gears inside the differential.
Gear 1 connects the motor to the driveshaft’s primary gear, gear 2. Gear 3_f and 3_r are the bevel gears on the front and rear of the driveshaft respectively and transmit rotation from main drive shaft to the differentials which we denote gear 4_f and 4_r. The gears are all module 0.5 to reduce backlash and are detailed as follows:
Table 1. Gear list and data
We used salvaged POM gears when available since they are self-lubricating and quite strong, since we had to make a custom gear for gear 1 that had to be made of 3D-printed PLA as that was the manufacturing method and material that gave us the most accurate involute teeth forms at module 0.5. The differentials were salvaged from another RC car and seem to be made of ABS or ASA as they are more rigid than PLA but do not seem to be as soft as the POM gears.
Figure 5. 3D Printed vs. Salvaged Injection Molded Counterpart
We reduced losses around rotating components with lubricated bearings and bushings. Since our desired RPM was quite slow we decided to use a lubricating grease instead of an oil like is normally seen in higher RPM gear boxes. Ultimately we used white lithium grease on all of our gears and bearings which gave us smooth power transmission with the lowest amount of mechanical losses we could manage.
7. Design Analysis
7.1 System Concept
Since we were given the project description and all of the qualifications it has to meet, it was given to us as a well defined concept. The FAR organization did a great job in describing the competition guidelines, and Aerojet in combination with the rocket design team were very descriptive in their own requirements that they expected us to meet to fit within the rocket’s restrictions and to have a quality submission. Designing components and integrations that could successfully fit those requirements was the real challenge.
7.2 System Visualization & Planning
Our team initiated all of our designs first with a rough sketch depicting shapes and measurements of our ideas. Next our mechanical engineer would get to work on solidworks to model each piece. This has allowed us to see how parts will fit together when combined in the chassis, as well as to be able to adjust and 3d print our own parts with very specific compositions.
Since many of the parts we are using have been 3d printed from our own designs, they have to be an accurate representation of our system. We know the measurements used to make them are correct because all of our components fit together very nicely. The only adjustments we’ve had to make have been some light filing and cutting due to small tolerances.
7.3 Fundamental Engineering Principles
The engineering principles that come up in our design are varied but mostly align under two main categories: structural and electromechanical.
On the structural side of the design we were concerned about mechanical failures of materials due to the combination of heat and force/shock events that our rover would encounter. We analyzed how our material properties, in particular the PLA thermoplastic that most of our chassis was made of, would change under the presence of the latent heat of our electrical components (i.e the batteries and processing components) as well as the impulse heat events from hot gas expelled along our canister from the rest of the rocket. In this analysis we used our knowledge built from materials, thermodynamics, and heat transfer.
The electromechanical side was concerned with voltage and current regulation in our electronics, our 3-phase motor control system with its subsequent gain-tuning, and lastly the drive train load configuration. Linear circuits came in as a very prevalent topic when ensuring proper voltage and current supplies as well when configuring the Odrive and connecting all the components. This side is especially critical as too much voltage sent either by power distribution design or by PID overshoot could easily result in melted wires and fire.
In designing the drive train, we used elements of machine design to ensure our gears would mesh and our gear ratio met our desired torque increase. With the calculated load configuration we modeled the system using our knowledge of mechanical systems so that we could best estimate our ideal gains, and system characteristics before tuning our PID cascade loop.
Figure 6. Odrive’s PID cascade loop
Then we used our knowledge of vibrations and controls to efficiently control our motor resulting in precise position, velocity, and acceleration control.
We adjusted the PID loop’s gains by using the following information:
Increasing…
Position gain:
decreases peak time & steady state error
increases position overshoot & settling time
Velocity gain:
decreases peak time, position overshoot, & settling time
no effect on steady state error
Velocity integrator gain:
decreases peak time & steady state error
increases position overshoot, settling time
Figure 7. How Gains Affect a System
*** See appendix A for project parameters
7.4 Boundary Constraints
Some of the most prevalent conditions that binded our progress include budgetary and size constraints. After being given a vague initial estimation of the budget put aside for our team, we were suddenly told that we had reached it when we thought we were only half way through. We combated this problem by finding used remote control cars and taking them apart for design inspiration as well as usage of the parts, and we were lucky enough to have access to a 3d printer for many of our elements, making them cost us only cents.
With the Odrives extensive list of abilities and commands, we were able to take electrical power measurements. After testing a variety of motors, we found a brushless inrunner motor that exceeded our expectations for efficient power consumption.
The Odrive also allowed us to use regenerative braking, so instead of wasting excess power converted to heat, it is sent back to the battery. We’ve taken the wattage each component will need and found that our 15v lipo battery could power everything for approximately 7 hours.
The PID loop used by our esc has to oscillate to any given value in order to find accurate positioning. Adding some adjustments in our gain values allow it to respond quickly to any changes in velocity.
7.5 Prototyping and Testing
Our rover has gone through dozens of prototype iterations. Each time we add or change a part, we need to make a new 3D model and print to test its fit and functionality.
In order to mitigate the occurrence of all our risks we tested each individual component rigorously, as well as the entire build put together. These include power consumption tests to ensure it can last long enough to drive up to a mile, size tests for internal rover elements, and the whole project so that it can enter and exit the canister, and durability and failure modes of our 3D printed components.
Our full-scale prototype was eventually converted into our final product as we used tested and replaced parts until we finally met our desired product. The concept of a full-scale prototype is also a little less applicable to our design scenario as we are building our solution for a competition rather than a marketable product prototype.
7.6.1 Analytical Models - Size Constraints
Figure 8: Internal Canister Dimensions
Figure 9. Canister Height Dimensions
Figure 10: Internal Canister Visual
Figure 11: Canister Height/Internal Measurement Visual
8. Final Design and Engineering Specifications
The final design of our rover was decided on based on its compactness and efficiency. With only one motor and encoder needed, we are saving a lot of room and power. The odrive and motor not only work efficiently, but the odrive allows used power to be recycled. The suspension and wheel design give us the capability to squeeze together enough to compress into our canister as well.
8.1 Discrete Components
A list of all discrete components our system is made up of can be seen below. The parts we have had to purchase are noted with an asterisk, and the rest of them have been fabricated by our team.
Wheels
Axles
Chassis
Battery*
Motor*
Encoder*
Esc*
Gps*
Transmitter*
Lidar*
Oak-D*
8.2 On Board Power
After performing extensive research on available parts, our team decided on using Zeee 4S 14.8V batteries. Appendix C can be referenced for more precise specs on the battery. This option proved to be the best bang for our buck, with a relatively low price compared to other batteries combined with adequate specifications that suit our needs, including a high amplitude and voltage. This battery is also fairly lightweight, which helps limit the load it has to supply since our rover will require less power the less it weighs. With our limited size constraints we also had to be sure that it could maintain a thin form factor.
What follows is all relevant components for our final design and their individual power usages where applicable.
Table 2. Component weights and power consumptions
With all of these components running in tandem this gave us a combined energy consumption per second of E=10.891 Watts . Given our battery’s rated capacity of 76.96 Wh, this gives us a total run time of 7.066 hours.
8.3 Video and Computer Vision
As illustrated in 3.5.2, the OAK-D integrated computer vision solution is an important inclusion for our project. Not only does it capture high-quality video for us to transmit for our mission requirement, it offloads a lot of our computer vision work to an efficient OpenCV powered integrated processor, which allows our central Raspberry Pi to focus on pathfinding and sending commands to the motor controllers. This results in a quicker overall control system response to obstacles and by extension allows us to navigate quicker, minimizing the overall time that we need to power the onboard computing and transmitting components, saving on our power budget. The OAK-D even incorporates an IMU, giving us another metric to use to determine our position, speed, and heading.
After quite a bit of trial and mostly error, we found VSLAM to be impossible to rely on completely without an unrealistic amount of further development time. As a result we would need to incorporate a second sensing solution in combination with our OAK-D. In particular we choose to add a LiDAR sensor. LiDAR allows us to generate a 360 degree point cloud around our rover and makes object detection and pathfinding extremely simple. The only downside of the LiDAR is that it’s quite large, has exposed moving parts that need covering and it has to be given a raised mounting location so the rover doesn’t see itself in the 360 scan.
8.4 “Long Lead Time” Components
Many teams struggled to acquire their parts quickly due to Covid, delayed deliveries, and supply shortages. Most of our parts were available on Amazon, which was pretty consistent in quickly providing us with our purchases. Some other parts that we had to buy directly from company websites, including our Oak-D and Odrive, have taken longer to get to us, so it has been important to make sure we put in our order requests as quickly as possible.
8.5 Development Critical Path
Since we finalized our design and prototypes as well our budget and timeline leading up to the practice launches of our rover, we had our critical development path laid out for us over the entire semester including manufacturing and testing. This had to change multiple times throughout the semester though as the budget we proposed was changed last minute twice and poor communication on the side of our procurement office resulted in us having none of the parts we needed to construct our original design.
Each time we redesigned our rover we updated our Gantt chart to try and still meet our rocket launch deadlines which after the last procurement event left us with only one week for CAD production and testing before the test launch.
Table 3. Critical Path
9. System Evaluation
9.1 Failure Modes and Mechanisms
Though our rover requires very tight size constraints, there are many components and subsystems carefully compressed into it. This causes the potential for many different points of failure within our design that we must keep in mind. The below text describes the subsystems that pose risk to our design, and the testing methods we used to mitigate these risks can be found in Appendix B. These subsystems include the following:
9.1.1 Chassis
Our chassis is 3D printed from PLA+ filament. It could fail by getting damaged when being dropped from the rocket or along our autonomous journey, and therefore being ineffective at protecting our internal components.
Even with relatively low infill (about 15% of the model filled, 85% hollow) PLA+ is highly resistant to impact force signals.
Most cracks or breakages in these components are very easy to spot and replace in our 3d prints. Since we have constant access to a 3d printer and all of our designs saved, we could easily overcome this kind of destruction by printing a new part, as long as they do not cause other components to break too.
If we were to notice a concerning or consistent issue with our chassis designs, we could alter the print design or increase the infill to make it stronger.
9.1.2 Power
Though we are using a very powerful 4 cell battery at 15 volts, having so many other powerful components that could need power for up to a mile drive produces the risk of our rover dying too soon. One mile is the maximum expected distance given to our team to navigate, however in an untested environment with unpredictable weather, we cannot completely dismiss the possibility of our battery being unable to power our rover through the entire distance.
We had the ability to take measurements and calculate power consumption, but it is difficult to evaluate this thoroughly with all the factors that could affect us on the day of competition. We believe, however, that as long as we sent out a fully charged pack, we would have been able to avoid this possibility being an issue.
9.1.3 Wheels & Movement (axles, servo, motor, motor controller, encoder, raspberry pi)
Being in the Mojave desert, our rover needed to be capable of traveling through terrain made of sand and rocks. Risks posed by the wheel design include being punctured and digging into sand. Since our wheels have an appropriate tread and are made of flexible rubber, we are able to ensure that it will be thick and wide enough to mitigate the chance of these failures.
Since the movement of our wheels involves so many elements, we ran the risk of failing to achieve accurate communication between all of them. If any wires or parts shift, this could cause data to be interrupted or invalid. To prevent this, we soldered on our own connectors to many of our wires and ensured a stable link between all of our parts.
Another risk is overheating, which could cause problems as severe as explosions. Since our rover is rather small, we have properly configured everything, and we have added heatsinks to items that get hot, the likelihood of this happening was small.
9.1.4 Navigation (GPS and Lidar) & Visibility (Transmitter and Oak-D)
Our GPS module and our transmitter both need enough signal to be able to receive data on our location. We must rely on this for navigation since our rover is autonomous. If this fails, we could lose our whereabouts and drive the wrong way, making it impossible to return to the launch site. Having the competition in the desert could have made this problematic.
We also needed the rover to be able to recognize and avoid obstacles for its autonomy, and be able to watch a live video feed. Our team used a LiDAR and an Oak-D camera to accomplish this. The LiDAR works by constantly spinning 360° to get a full view of its surroundings. Since the competition is in the desert, we risked sand getting between the belt and pulley preventing a smooth turn, and therefore causing an incorrect data transmission. Both cameras also ran the risk of being blocked, making it impossible to see our surroundings - a big issue for our autonomy and video feed.
On the software side of things, any error occurrence could also have resulted in incorrect data and telling our rover that it could pass when there was in fact an obstacle in its way.
9.1.5 Canister
Our canister posed the risk of inadequate protection from the drop and damaging components, and also prohibiting us from exiting once we reach the ground. This would have prevented us from even being able to even initiate our drive. Luckily the continuity senior design team took the liberty of making us a sturdy canister, so it would be able to properly protect our project and open upon landing.
Detecting these risks was not 100% achievable since it was difficult to test a drop with it from as high as the rocket would launch it, but we got close enough by determining how well it protects from any damage after being dropped from a lesser, but still high, location such as the top of a UCF parking garage.
9.2 Risk Severity
The exact point of failure and what is affected by it, as well as the timing both have varying effects on the severity of the problems. If we had a failure impactful enough to prohibit our autonomous navigation back to the launch site on the day of the FAR competition, we would ultimately be failing to succeed in our overall design criteria - which was our worst case scenario had we chosen to take part in the competition.
If any subsystems experienced failure during testing, the impact would have been less fateful, however the type of failure could still have resulted in varying levels of harm to our project. For example, if any of our 3d printed parts were to break during testing without causing harm to any other parts, we could easily have overcome the problem by printing a new part since we had constant access to a 3d printer and the designs saved.
If other parts were to break due to any of the above listed failures, their severity would depend mostly on the price of the component, as well as the availability. For example, if a wire were to break, we had plenty of extra wire and connectors at our disposal to easily recreate what we needed. However, if one of the more expensive components that need to be shipped were to break, this could have been catastrophic. Our team's budget ran out quickly, so we would have had to get a replacement out of pocket, and also wait for the part. Many companies are backed up or out of stock, so it was a possibility that we would not even have been able to obtain the new part in time.
Finally, if our software were to fail during testing, as long as it did not cause damage to any physical parts, this would be another easy obstacle to overcome since we have so many talented computer scientists at the ready to fix and adjust their code.
10. Significant Accomplishments and Open Issues
Given our extremely limited time frame on the final iteration of our design, we are very proud of how much we’ve accomplished out of our initial design goals. Our final iteration is under our weight and energy budget. It’s strong, simple and robust; capable of surviving all of the forces we anticipate with a reasonable factor of safety. The design is also cheap, easy to repair, and quite accessible as most parts are either able to be 3D printed or easy to find in most hardware shops.
Though we’ve had quite a few successes there were still requirements that we were not able to meet. Our current design has trouble fitting in the canister designed by the rocket team without elastically deforming the canister itself. Video transmission ended up being over long-range wifi which we found much less responsive and failure prone compared to transmission over radio bands. Also even with the processing power of our OAK-D, Raspberry Pi 4, and arduino we still ran into trouble with thermal throttling and our ROS2 object avoidance code would often freeze and crash during integration tests.
10.1 Unperformed Planned Tests
We conducted most of the tests that we planned throughout the semester but the ones we weren’t able to accomplish were quite significant. We were unable to perform large-scale drop tests with our design inside the canister with the parachute and shock cable and we were also unable to attend the mock launch that we were offered close to the end of the project during our last revision due to canister issues. We believe that, should we have had more time, these tests would have helped us bring to light many issues with our design that can’t be easily simulated. What would our rover do in the case that the payload canister or parachute gets snagged on a power line. Will the vibrations of the rocket shake loose an electrical connection that we overlooked? There is really no way of knowing these factors without large-scale hands-on tests. We’re first timers when it comes to designing a rover or even a project of this magnitude so we’re sure that even with our research there is still a lot for us to learn about the forces and elements that our rover would experience during each event between launch and arrival.
10.2 Future Design Change Recommendations
Our recommendations for those who seek to emulate our design challenge all mostly follow these issues left open by our final design. We recommend using a radio receiver and transmitter for video transmission at frequencies deemed acceptable by your rocket telemetry and distance requirements. 3D printed thermoplastics are great for this purpose but ensure that thermal events aren’t long enough to cause material failure. Keep software simple and design specifically for your hardware capabilities, or try to solve problems mechanically to save on processing power. A good example that we pursued was increasing our breakover angle and wheel differential so that we didn’t need to sense and map the ground for possible animal holes and small rocks; the rover would instead be able to keep acceptable contact patches without the chassis getting snagged or stuck during the maneuver.
11. Conclusions and Recommendations
Throughout the course of the year, our senior design team, the Autonomous Rover Green Team, worked very hard to create this comprehensive design document to cover all of the information surrounding this project. In the beginning, there were not many specifications other than “an autonomous rover that navigates itself back to base”. As time went on, we received more details about how much our rover could weigh, how it will be deployed, how far away from the launch site we can expect it to travel, etc. As new information came in, our designs had to be modified to accommodate the challenge.
On the software side, there has been much research and experimentation with Computer Vision and object detection with the OAK-D, video transmission of the OAK-D feed, Simulation in Gazebo and Rviz, motor movement testing with the freenove kit, GPS localization with a USB module, and ROS2 configuration.
On the hardware side, there were dozens of iterations of CAD designs based on new requirements or other hardware attachments, 3D printed canisters for dimension testing, varying wheel designs such as spoked or treaded for locomotion testing, PCB design to accommodate different power requirements from the attached hardware, soldering for radio frequency transmitter adapters for a Raspberry Pi, and servo testing for movement of wheel ‘legs’.
As Senior Design II comes to a close, we have come incredibly close to a successful implementation of the rover as specified. We pivoted after experiencing difficulty in getting all of our real-world sensor data properly formatted for ROS to a simpler object avoidance model. This process was successful. However, due to a day-of hardware failure of the steering mechanism we were unable to present our rover in an operable state. Instead, we were able to provide videos of our successful software simulation and show off the rover’s battery, suspension, and drivetrain design.
For those interested in constructing a similar rover we recommend keeping hardware simple to avoid delays in integration and learning curves for those new to the mechanical and electrical aspects of the rover. We also recommend exploring different solutions for geolocation. We used GPS but for the system, but for it to be viable for extra-terrestrial purposes it would be useful to compare other methods like comparing surface mapping data from the cameras to known satellite or telescope images of the landing zone. Also exploring more power solutions that are more viable for interstellar missions would be interesting as well, solar power for instance. There remains much to be learned about interstellar rovers and robots and we hope to have helped pave the way for young researchers like ourselves.
References
[1] “R/UCF - I haven't been on campus in a minute but this is new,” reddit. [Online]. Available: https://www.reddit.com/r/ucf/comments/mzsu3n/i_havent_been_on_campus_in_a_minute_but_this_is/.
[2] Attain central florida. FDOT. (n.d.). Retrieved December 6, 2021, from https://www.fdot.gov/traffic/its/projects-deploy/cv/maplocations/attain-central-florida.
[3] Took, T. (n.d.). Adiona. Adiona, Roman goddess of the return journey. Retrieved December 6, 2021, from http://www.thaliatook.com/OGOD/adiona.php.
[4] Took, T. (n.d.). Abeona. Abeona, Roman goddess of the forward journey. Retrieved December 6, 2021, from http://www.thaliatook.com/OGOD/abeona.php.
[5] FAR Mission. FAR. (n.d.). Retrieved December 6, 2021, from https://friendsofamateurrocketry.org/mission/.
[6] Overview: Adiona-senior design. Adiona. (n.d.). Retrieved December 6, 2021, from https://adionarover.wixsite.com/ucfseniordesign/overview.
[7] Aerojet Rocketdyne: At the Center of Defense and Discovery. Aerojet Rocketdyne | At the Center of Defense and Discovery. (n.d.). Retrieved December 6, 2021, from https://www.rocket.com/.
[8] Spot® - The Agile Mobile Robot. Boston Dynamics. (n.d.). Retrieved December 6, 2021, from https://www.bostondynamics.com/products/spot.
[9] NASA. (2017, September 19). Building curiosity: Rover rocks rocker-bogie – NASA's Mars Exploration Program. NASA. Retrieved December 6, 2021, from https://mars.nasa.gov/news/1057/building-curiosity-rover-rocks-rocker-bogie/.
[10] NASA. (n.d.). 'hedgehog' robots hop, tumble in microgravity. NASA. Retrieved December 6, 2021, from https://www.jpl.nasa.gov/news/hedgehog-robots-hop-tumble-in-microgravity.
[11] Diamond, Jared. “Transport mechanisms: The biology of the wheel”. Nature 302.5909 (1983): 572–573. Web.
[12] Tyre Review. (2018, December 10). How a Tyre's tread pattern deals with water. Tyre Reviews Australia. Retrieved December 6, 2021, from https://www.tyrereview.com.au/tyre-advice/how-a-tyres-tread-pattern-deals-with-water.
[13] NASA. (n.d.). Breaks observed in Rover Wheel treads. NASA. Retrieved December 6, 2021, from https://www.jpl.nasa.gov/news/breaks-observed-in-rover-wheel-treads.
[15] Mojave Google Desert https://www.google.com/maps/place/Mojave+Desert/@35.0117707,-115.4736044,21z/data=!4m5!3m4!1s0x80cf61476bd798cf:0xca4c53e5430da34!8m2!3d35.0109911!4d-115.4733551?hl=en
[16] Creosote. Creosote bush. (n.d.). Retrieved December 6, 2021, from http://mojavedesert.net/plants/shrubs/creosote.html.
[17] Amazon.com. spend less. smile more. (n.d.). Retrieved December 6, 2021, from https://www.amazon.com/.
[18] Oak-D. Luxonis. (n.d.). Retrieved December 6, 2021, from https://shop.luxonis.com/products/1098obcenclosure?variant=40558115881141¤cy=USD&utm_medium=product_sync&utm_source=google&utm_content=sag_organic&utm_campaign=sag_organic.
[19] Oak-D-intl luxonis: Mouser. Mouser Electronics. (n.d.). Retrieved December 6, 2021, from https://www.mouser.com/ProductDetail/Luxonis/OAK-D-INTL?qs=DPoM0jnrROXjQVWBpbQqSw%3D%3D.
[20] Amazon.com: Immersionrc 2.4ghz 700MW A/V transmitter (US ... (n.d.). Retrieved December 6, 2021, from https://www.amazon.com/ImmersionRC-2-4GHz-700mw-Transmitter-Version/dp/B07F3CNPSC
[21] 2.4GHz 700MW A/V TX. ImmersionRC Limited. (n.d.). Retrieved December 6, 2021, from https://www.immersionrc.com/fpv-products/2-4ghz-700mw-av-tx/.
[22] Boscam RC802 2.4ghz wireless AV receiver VRX for FPV & Wireless CCTV cameras. DronesVision. (n.d.). Retrieved December 6, 2021, from https://dronesvision.net/product/boscam-rc802-2-4ghz-wireless-av-receiver-vrx-for-fpv-wireless-cctv-cameras/.
[23] Raspberry Pi. (n.d.). Buy A raspberry pi 4 model B. Raspberry Pi. Retrieved December 6, 2021, from https://www.raspberrypi.com/products/raspberry-pi-4-model-b/.
[24] Buck converters and their cool applications - technical articles. All About Circuits. (n.d.). Retrieved December 6, 2021, from https://www.allaboutcircuits.com/technical-articles/buck-converters-and-their-cool-applications/.
Appendix A: Customer Requirements
The FAR competition outlines their complete competition guidelines in detail on their website (Appendix F - guideline ID) as seen below. We have ID’d each requirement in the form of (*Appendix A.category letter.section number.requirement number*).
A.a Competition Requirements
A.a.1 All Competition Requirements
-
(A.a.1.1) Minimum 2.2-lbs (1.0-kg) payload. Must be removable as a separate unit from the airframe. Payload may include avionics, video cam, telemetry, and payload option. Minimum 3” (75-mm) airframe.
-
(A.a.1.2) Redundancy required in the following systems:
-
Two motor igniters, dual ejection system per stage, dual altimeters/flight computers; at least one altimeter must be an approved COTS (commercial off the shelf) to be used for altitude verification.
-
-
(A.a.1.3) Dual deployment. Main deploys 500’ – 1500’ AGL. No component should exceed 100 ft / sec during recovery.
-
(A.a.1.4) Tracking system required. Either GPS telemetry, Radio Beacon or other approved in advance location method.
-
(A.a.1.5) Minimum K-impulse motor required (1,280-N-sec) and 40,960-N-sec total maximum limit ‘O’ impulse motor.
-
(A.a.1.6) Choice of payload ‘mission’ options required (see below) with points awarded for successful completion.
-
(A.a.1.7) Open Rocket file ( http://openrocket.info/ ) of launch vehicle to be emailed no later than May 29, 2022.
A.a.2 Competition Requirements ~ Regarding Payload
-
(A.a.2.1) Minimum 2.2-lbs (1.0-kg) payload.
-
(A.a.2.1) Must be removable as a separate unit from the airframe.
-
(A.a.2.1) Payload may include avionics, video cam, telemetry, and payload option.
-
(A.a.2.1) Minimum 3” (75-mm) airframe.
-
(A.a.2.1) No component should exceed 100 ft/sec during recovery
A.b Competition Scoring
A.b.1 Scoring
-
(A.b.1.1) Highest score wins
-
(A.b.1.2) 1 point is awarded for every foot altitude to the target altitude (5,000/10,000/30,000) ft
-
(A.b.1.3) 1 point will be deducted for each foot over the target (5,000/10,000/30,000) ft. altitude entry class
-
(A.b.1.4) Added to points for successful payload option and ‘Bonus’ points
A.b.2 Scoring Bonuses
-
(A.b.2.1) 2,000-points for experimental solid (non-COTS) motor…use of student-built motor encouraged.
-
(A.b.2.2) 3,000-points for use of experimental hybrid motor.
-
(A.b.2.3) 4,000-points added if motor is a bi-propellant liquid.
-
(A.b.2.4) 1,000-points for using a 2-stage rocket (available only for 25,000’ Class)
-
(A.b.2.5) 1,000-points for designing and constructing a nose cone that successfully carries a minimum 500-ml of water and safely releases the water at or after apogee to be dispersed in the air that demonstrates safe ‘ballast’.
-
(A.b.2.6) 500-points for a two-minute team build video or 25-photos of the build process.
A.b.3 Point bonuses for payload selection
-
Points are awarded for successful payload mission completion.
-
(A.b.3.1) 1000-points: Remotely Radio-Controlled Rover
-
(A.b.3.2) 3000-points: Autonomous rover
-
A rover that returns autonomously to the designated launchpad with live video.
-
(A.b.3.3) 1000-points: Remote Sensing
-
(A.b.3.4) 1000-points: Reconnaissance
-
(A.b.3.5) 2000-points: Reconnaissance Return
-
(A.b.3.6) 500-points: Remote Sensing
-
(A.b.3.7) 500-points for a user defined scientific payload that is contained in a CubeSat or CanSat form factor
-
(A.b.3.8) 500-additional bonus points: A secondary on board video source recorded to a memory card during the flight
A.c Judging
-
(A.c.1) Live video must be witnessed by a judge to be valid, or video must be recorded at ground launch area receiving station
A.e Arcturus Team
-
(A.e.1) Maximum weight of 9.5 lb (4.31 kg) (including payload, canister, and sled)
-
(A.e.2) Maximum of 12.7 cm width/height
-
(A.e.3) Maximum of 40.64 cm length
-
(A.e.4) Design/build a payload canister
-
(A.e.5) Design/build a payload sled
-
(A.e.6) Ability to withstand 8 G’s of force
-
(A.e.7) Ability to withstand rapid heating and cooling while maintaining original material strength (i.e. avoiding ductile to brittle transformation)
-
(A.e.8) Ability to operating within a frequency of 420 - 450 mHz, and 1-2 gHz
Appendix B: System Evaluation Plan
B.1 Power
Though the characteristics of our batteries were laid out in their documentation we thought it necessary to double check their acceptable voltage ranges to ensure that we don’t overestimate our available power capacity and accidentally over-discharge the batteries as replacing these batteries would be extremely costly for our team. We did this by plugging our battery into an advanced LiPo balance charger after each use and logging the voltage and capacity remaining.
We also did two tests where we would calculate our power consumption at idle using the power consumption values estimated for each of our components in their respective manuals and then run our system at idle for around 30 minutes so we could calculate and compare our power usage to the actual case. At idle we consumed exactly as much power as we calculated, though this is likely due to the fact that the Raspberry Pi 4 fluctuates in power consumption between 4.5 and 5.5 Watts, leading most to average this to around 5 Watts. However at idle we were likely only using somewhere on the lower end of this range, around 4.5 Watts. We believe the remaining power to be lost due to mechanical losses and heat.
B.2 Motors
Motors were tested with a variety of different electronic speed controllers to test efficiency at low RPMs, throttle ranges, and heat expulsion. We originally tested efficiency by measuring the voltage and current of the system with a multimeter but once we received the ODrive we were able to calculate these values as well as our mechanical efficiency by using the ODrive’s advanced motor calculators and onboard oscilloscope. Using the liveplotter function in OdriveTool we could easily compare values like output current, electrical power, mechanical power, phase offset, and steady state error. Using these values we were able to optimize our motor configuration to reduce losses and adverse effects like cogging at low speeds. This testing also allowed us to tune the gains of our PIV control loop so that we could achieve our desired speeds quickly with minimum overshoot and low steady-state error.
B.3 Structural Components (Chassis & Mounts)
The components of our rover are held together by mounts and parts designed and printed by our own mechanical engineer member. We printed a model commonly used as a benchmarking test to examine the weakest points to watch out for in our prints and designs with the filament used. To test it we tried our best to destroy it, including subjecting it to drops, ripping with pliers, and hammering.
We noticed that when it does break it appears to break due to buckling induced failure causing transverse shear. While parts did fail close to layer lines, it seems to have only failed at sharp corners (stress concentrations) and continued along transverse buckling shear directions from there. This seems to be supported as well by the fact that some cracks traveled from one layer to the next during failure.
Appendix C: User Manual
There are many parts that need to be properly connected in order for our rover to function. To make this process more user-friendly, we have added numbered labels to the wires and parts that need to be attached.
C.1 Parts & Specs
C.1.1 Motor: Jrelecs 3674 BLAC Motor
Amount needed:
1
Manufacturer:
Jrelecs
Specs:
Size - 3.7 x 2.4 x 3.1 inches
Shaft size - 16mm length, 5mm diameter
Weight - 317g
Motor type - brushless inrunner motor
Material - Aluminum
KV - 1900 KV
Poles - 4
RPM - 50000
Voltage rating - 26V
Max current - 70A
Resistance - 13.2 mΩ
Figure 12. Jrelecs 3674 BLAC Motor
C.1.2 Electronic Speed Control: Odrive V3.6
Amount needed:
1
Manufacturer:
Odrive
Specs:
Size - 140.5mm x 50mm
Input voltage - 12V - 24V
Peak current - 120A per motor
Includes:
ODrive v3.6 board
a power resistor (for brake energy dissipation)
USB cable
Heatsinks
nylon standoffs
Figure 13. Odrive
C.1.4 Battery: Zeee 4S Lipo [17]
Amount needed:
1
Manufacturer:
Zeee
Specs:
Size - 154mm x 48.5mm x 32.5mm
Weight - 213g
Capacity - 5200mAh
Voltage - 14.8V
Discharge - 100C
Configuration - 4S1P
Connector - EC5 Plug
Figure 15. Zeee 4S Lipo
C.1.5 Camera: OAK-D
Amount needed:
1
Manufacturer:
Luxonis
Specs: [21]
Multi-platform depthAI
Real-time spatial AI
1x 4K 60Hz color camera
2x 720P, 120Hz global shutter camera
Mono camera for high-quality, high-speed 3D perception
Display field of view - 83° or 81°
Display resolution - 1280 x 800
Frames per sec - 120
Lens size - ½.3 inch
Operating supply voltage - 5V
Figure 16. OAK-D
C.1.6 Transmitter: Immersion RC 2.4GHz 700mw A/V
Amount needed:
1
Manufacturer:
NexWaveRF
Specs: [23]
Length - 57mm
Width - 23mm
Height - 12mm
Weight - 22g
RF Output (50 Ohm) - 700mW/28.5dBm +/- 1dB
Video input (75 Ohm) - 1Vpp typical
Audio input (10K Ohm) - 1Vpp typical
Power Requirements - 2s-6s LiPo (6V – 25V)
Power Output - 5V, 1.5A Max
Frequencies: 2396, 2410, 2430MHz (USA version)
Figure 17. Transmitter
C.1.8 Computer: Raspberry Pi 4 Model B
Amount needed:
1
Manufacturer:
Raspberry Pi
Specs:
Broadcom
BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz
2GB, 4GB or 8GB LPDDR4-3200 SDRAM (depending on model)
2.4 GHz and 5.0 GHz IEEE 802.11ac wireless, Bluetooth 5.0, BLE
Gigabit Ethernet
2 USB 3.0 ports; 2 USB 2.0 ports.
Raspberry Pi standard 40 pin GPIO header (fully backwards compatible with previous boards)
2 × micro-HDMI ports (up to 4kp60 supported)
2-lane MIPI DSI display port
2-lane MIPI CSI camera port
4-pole stereo audio and composite video port
H.265 (4kp60 decode), H264 (1080p60 decode, 1080p30 encode)
OpenGL ES 3.1, Vulkan 1.0
Micro-SD card slot for loading operating system and data storage
5V DC via USB-C connector (minimum 3A*)
5V DC via GPIO header (minimum 3A*)
Power over Ethernet (PoE) enabled (requires separate PoE HAT)
Operating temperature: 0 – 50 degrees C ambien
Figure 19. Raspberry Pi 4 Model B
C.2 Steps
Screw the 3 red motor wires labeled 1 into the M0 motor screw terminals labeled 1.
Figure 20. Connection 1.1, Odrive-Motor
Plug the other end of the red motor wires into the three phase wires on the motor, put the motor into the white motor holder, and screw it onto the chassis with M3 screws.
Figure 21. Connection 1.2, Odrive-Motor
Plug the encoder wires into the J4 pins on the Odrive, both with the label 3. Be sure to keep the black GND wire on the right, and the separate red power wire into 3.3V.
Figure 22. Connection 3.1, Odrive J4 Pins
Plug in the other end of the encoder wires into the encoder (also labeled 3). Attach the encoder to the shaft of the motor.
Figure 23. Connection 3.2, Encoder Pins
Plug the Odrive USB wire (labeled OD in silver sharpie) into the micro usb connection on the Odrive.
Figure 24. Odrive USB
Plug the USB end of this wire (labeled 9) into the raspberry pi at label 9. Plug the USB end of the LiDAR into the raspberry pi label 11.
Figure 25. Connections 9 & 11, Raspberry Pi USBs
Plug the other end of the LiDAR wire (labeled 7) into the circuit labeled 7.
Figure 26. Connection 7, LiDAR
Plug the battery into the red and black wires attached to the Odrive, both labeled 5.
Figure 27. Connection 5, Battery
Screw Odrive onto white mount and put the battery into the holder under it.
Figure 28. Odrive/Battery Mount
Screw all remaining components onto the chassis with M3 screws.
Appendix D: Cost and Manufacturability Analysis
The cost estimate for the manufacturing of our product would probably actually cost more than the amount we spend creating it. Many of our items were expensive and would remain necessary, and a couple things were acquired for free from the UCF used parts inventory from past senior design projects.
With the addition of the cost of a raspberry pi (approximately $50) plus all parts in the expense table 4 in Appendix E (and assuming access to a 3d printer is available), the total cost would come to about $834.
Our product is for a very specialized purpose, so the likelihood of it being mass-produced is very low.
Appendix F: Manuals and Important Documents
Many of our components were open source and had so much documentation on how to set up, use, and troubleshoot our parts. We used their descriptions and datasheets to consider designs and to appropriately scale things in our CAD designs. Most of these datasheets can be found on the websites we purchased them from. These sites as well as links to many helpful resources can be found in the text below with their associated component.
Odrive
https://docs.odriverobotics.com/v/latest/getting-started.html
https://discourse.odriverobotics.com/
Encoder
Motor
LiDAR
Oakd
OpenCV AI Kit: OAK—D– OpenCV.AI
https://docs.luxonis.com/en/latest/
Transmitter and Receiver
Battery
