ebook img

NASA Technical Reports Server (NTRS) 20130000010: 2012 Alabama Lunabotics Systems Engineering Paper PDF

9.8 MB·English
Save to my drive
Quick download
Download
Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.

Preview NASA Technical Reports Server (NTRS) 20130000010: 2012 Alabama Lunabotics Systems Engineering Paper

2012 Alabama Lunabotics Systems Engineering Paper r School: University of Alabama Team Name: NASAC AR Team Members: Justin Baker, Jessica Colburn, Justin Headley, Adam Melton, Dalen Mullenix, Andrew Price, Logan Ream, David Sandel, Mitchell Spryn, Stephanie Troy, Jason Watts, Matt Westberry Faculty Advisor: Dr. Kenneth Ricks ABSTRACT would do well with reconnaissance, and a mobile Excavation will hold a key role for future lunar gripper arm would be fit for manipulation, while an missions. NASA has stated that "advances in lunar excavator would be comparatively clumsy and slow in regolith mining have the potential to significantly both cases. Even within the realm of excavation it contribute to our nation's space vision and NASA space would be beneficial to have different types of exploration operations." [1]. The Lunabotics Mining excavators for different tasks, as there are on Earth. Competition is an event hosted by NASA that is meant The Alabama Lunabotics Team at the University of to encourage "the development of innovative lunar Alabama has made it their goal to not only design and excavation concepts from universities which may result build a robot that could compete in the Lunabotics in clever ideas and solutions which could be applied to Mining Competition, but would also be a multipurpose an actual lunar excavation device or payload." [2]. tool for future NASA missions. The 2010-2011 Teams entering the competition must "design and build resulting robot was named the Modular a remote controlled or autonomous excavator, called a Omnidirectional Lunar Excavator (MOLE). Using the lunabot, that can collect and deposit a minimum of 10 Systems Engineering process and building off of two kilograms of lunar simulant within 10 minutes." [2]. years of Lunabotics experience, the 20 ll-20 12 While excavation will play an important part in Alabama Lunabotics team (Team NASACAR) has lunar missions, there will still be many bther tasks that improved the MOLE 1.0 design and optimized it for the would benefit from robotic assistance. An excavator 2012 Lunabotics Competition rules [I]. A CAD model might not be as well suited for these tasks as other types of MOLE 2.0 can be seen below in Fig. I. of robots might be. For example a lightweight rover Figure l: MOLE 2.0 robot with base (top), 2012 competition module (left) and 2011 competition module retrofitted (right). To Table of Contents Table of Contents INTRODUCTION .......................................................................................................................................................................3 SYSTEMS ENGINEERING ....................................................................................................................................................... 3 Phase A: Concept Deveiopment. ........................................................................................................................................... 3 -Mission Objective: ........................................................................................................................................................................... 3 -System Requirements: ..................................................................................................................................................................... 3 -Architectural Dcsign: ....................................................................................................................................................................... 4 -Concept of Operations: .................................................................................................................................................................... 4 -Base: ................................................................................................................................................................................................ 4 -Module: ........................................................................................................................................................................................... 5 -Data Processing: .............................................................................................................................................................................. 6 -System Definition Review (SDR) .................................................................................................................................................... 7 Phase 8: Preliminary Design ................................................................................................................................................. 7 -Base: ................................................................................................................................................................................................ 7 -Mechanical: ............................................................................................................................................................................... 7 -Power: ....................................................................................................................................................................................... 9 -Controls: .................................................................................................................................................................................... 9 -Module: ......................................................................................................................................................................................... I 0 -Mechanical: ............................................................................................................................................................................. I 0 Oftloading: ................... .............................. ........................... ...................................................... ................................. . .. 10 Storage:. . ............................................................... . ........................ ............. .............. . ........... 10 Digging ............................ ..................................... ......................................................... .......... ...... ....... ................. . ........ 10 -Power:............................... ................................................................................................ ............................ . ......... II -Controls: .................................................................................................................................................................................. 11 -Data Processing: ............................................................................................................................................................................ 11 -Automation: ............................................................................................................................................................................. II -Front End: ................................................................................................................................................................................ 12 -Back End: ................................................................................................................................................................................ 12 -Preliminary Design Review (PDR) ................................................................................................................................................ 13 Phase C: Final Design and Fabrication ............................................................................................................................... l3 -Base: .............................................................................................................................................................................................. 13 -Mechanical: ............................................................................................................................................................................. 13 -Power: ..................................................................................................................................................................................... 13 -Controls: .................................................................................................................................................................................. 14 -Module: ......................................................................................................................................................................................... 14 -Mechanical: ............................................................................................................................................................................. 14 Oftloading: .......................... ................................. ................. ... ..... .. .................................................................................... 15 Storage: ........................................ ................ .................... . ....................................................................................................... ........... 15 Digging: . . ... . ...................................... ............................. ........... .. ............................... .. ............................................................... 15 -Power: ..................................................................................................................................................................................... 16 -Controls: .................................................................................................................................................................................. 16 -Data Processing: ............................................................................................................................................................................ 16 -Front End: ................................................................................................................................................................................ 16 -Back End: ................................................................................................................................................................................ 16 -Critical Design Review (CDR) ...................................................................................................................................................... 17 Phase D: System Assembly, Integration, Test, and Launch (SAITL) .................................................................................. I7 -Base Testing: .................................................................................................................................................................................. 17 -Module Testing: ............................................................................................................................................................................. 17 -Soflware Testing: ........................................................................................................................................................................... 18 Technical Management. ....................................................................................................................................................... 18 -Technical Resource Budget: ........................................................................................................................................................... 18 -Risk Management: ......................................................................................................................................................................... 18 Project Management. ........................................................................................................................................................... 18 -Configuration Management: .......................................................................................................................................................... 18 -Management Structure: .................................................................................................................................................................. 19 -Schedule: ....................................................................................................................................................................................... 19 -Financial Budget: ........................................................................................................................................................................... 19 CONCLUSION ......................................................................................................................................................................... 20 BIBLIOGRAPHY ..................................................................................................................................................................... 21 2 gaining experience with efficient hardware design and INTRODUCTION software-architecture planning, learning the processes involved in working with a multidisciplinary team, Team NASACAR used the Lunar Engineering obtaining valuable engineering skills for future careers, Handbook, written by David Beale, as a guide to the and spreading enthusiasm for Science, Technology, application of a Systems Engineering approach [3]. The Engineering, and Mathematics to K-12 students. This team defined mission objectives, derived system paper documents the Systems Engineering process requirements from these objectives, divided the project followed by Team NASACAR during the project. into clear subsystems, and in general followed the phases of the Systems Engineering life cycle as seen in SYSTEMS ENGINEERING the Vee Chart in Fig 2. Within each phase the II Systems Engineering functions (as seen in Fig. 3) were Phase A: Concept Development implemented. Due to the directed nature of the project and The primary goal of this project was to apply a limited time, Pre-Phase A and Phase A were Systems Engineering approach to the design and combined so that a single system concept could be implementation of a modular lunar regolith excavator more thoroughly developed. Below is the Mission and to demonstrate its capabilities during the 2012 Objective along with the system level Requirements, NASA Lunabotics Mining Competition. The secondary Architectural Design, and Concept of Operations goal of the project was to design the robot so that it (RIA/C). could be easily expanded in the future to be applied -Mission Objective: toward functions other than excavating that are also The Mission Objective for Team NASACAR is to important for lunar missions. Other objectives included use the MOLE 1.0 robot as a foundation for creating a modular robot (MOLE 2.0) capable of performing i! Ptt..pbyt A: Cpnetpl Studfn multiple functions viable to a lunar mission as well J MultipMlel uSlyoante Omb RjeJNetClv cno +n cepti competing in the 2012 NASA Lunabotics Competition. !.---_.....-----, 1 -System Requirements: !!:.!!!!~~~~=~ The main system requirements, shown in Table l, ~ L__ _________~ were split into two categories: requirements derived '! I from summarizing the Lunabotics Rulebook [I] and the Mission Objective requirements not pe1taining to the .. competition. The requirements are labeled according to their requirement type: Functional, Performance, ·cc Interface, Verification, and Other. !L-----------~----- '5 Table I: System Requirements i5. u 00 Lunabotics Requiremmts Figure 2: Systems Engineering Life Cycle Vee Chart F: The robot must collect, transport, lift, and deposit the lunar regolith sirnulant. IF: The robot must be either autonomous or teleoperated. P: The robot must collect at least lOkg of regolith in 10 minutes. P: The robot must lift the s imulant at least 0.5 1reters above ground level. V: The robot willn1eet all system require1rents by April30, 2012. 0: The total project costs must be less than $20000. 0: The total mass of the robot with an excavation n'Odule must be within 80kg. 0: The robot must fit into a .75m width X 1.5mlength X 0.75m Output: Proceed to height footprint. ·- next Phase. ending at Operations (Phase E) R.~;nitining Mission Objective Requiren1ents 1: The robot nust be n'Odular. That is, it must be capable of supporting multiple ll'YJdules that perfonndifferent functions Figw-e 3: The II Systems Engineering Functions and are easy to instalVremove. To Table of Contents 3 -Architectural Design: considered these options, weighing the pros and cons The team determined that the MOLE 2.0 design and simulating different point outcomes. After several would be broken down into three main subsystems: discussions the team concluded that a fully autonomous Base, Module, and Data Processing. The Base and robot, while possible, would likely be out of the scope Module subsystems were also broken down into three of this year's project; however partial autonomy identical subsystems: Mechanical, Power, and Controls. (autonomous traversal of the obstacle area) should be The Data Processing subsystem was composed of two within reach. In order to achieve this goal and to keep main subsystems: Front End and Back End. The open the possibility of full automation the team set a Architectural Design Product Hierarchy can be seen in subset of members to focus on researching methods of Fig. 4. This layout differed significantly from the automation. The resulting system level ConOps can be MOLE 1.0 architecture in two key aspects. seen in Fig. 5. The first major difference was that the Base and -Base: Module subsystems contained their own independent Throughout the design process of Team power and controls subsystems. In the previous design, NASACAR's 2012 competltton Base, several an Electronics Module subsystem was used as a central improvements and concepts were considered. While hub for all the power and controls hardware. This many other forms of locomotion were studied in the change was brought about to help simplify electrical design of MOLE 1.0, a unanimous decision was made and controls interfaces and to allow for more efficient to keep the locomotion method from the previous placement of power and controls hardware. design which consisted of four wheels with the ability The second major architectural difference was that to sweep into other driving positions. This feature gave the robot software was abstracted into its own Data the MOLE 1.0 robot its omnidirectional characteristic, Processing subsystem. This allowed for a clearer but its main advantage was that it provided the robot perspective of the software layout as a whole. with the ability to perform a "neutral tum" (where the -Concept of Operations: center of the tum coincides with the center of the wheel The Concept of Operations (ConOps) for the robot base) with almost no wheel slippage. Wheel slippage is will be largely determined by which modules are being a key factor on the moon since the top layers of the used. This paper focuses on the ConOps of the regolith have very low densities. If too much slippage excavating modules for the competition. The system occurred, especially under a load, then the robot would level ConOps derived straight from the competition be in danger of bottoming out and being unable to rules. The only system level choice left to be made was whether the robot would be autonomous or teleoperated. Turn on robot. I Turn offrobot. i Due to the large amount of points being given for both full and partial autonomy, the team carefully Mission 1i rnc I BASE I ~~--~~~~~ ~~r~4 ~ ------------ -----·····----~ ~-- ~~ ~ Ie o~eZT -i~l j. ..: -~1 I~""' I 1~1 ·jii:;l; .... j I . -I .... DATA PROCESSING - /----- ............ ~ ......... .,.'!~\,. to starting area. Figure 4: Architectural Design Product Hierarchy Figure 5: System Level Concept of Operations To Table of Contents 4 move. The same turning ideology is currently being Table 2: Base Requirements employed in many of NASA's robots including the 1 Mars Rovers, the Centaur 2, and the Space Exploration ~~~~~~&seMechanical ---- --- Vehicles (SEVs). These can be seen in Fig. 6. F: Will use provided Power and Control comrmnds to enact Looking back at the MOLE 1.0 Base design, the appropriate physical response. I several weak points were found and cataloged and Locomotion ~~ ~~- J improvements were ranked by priority. The top priority F: Must provide contact area large enough to support Module and Regolith. was to increase the torque and power available to the P: Must support full load ofModule and Regolith. wheels so that the Base could handle larger and more P: Must provide loconl:ltion to accommJdate as rmny nl:ldule varied modules. On top of this, the Base dimensions designs as possible. needed to be optimized to the 2012 competition rules so _______ .... 1: Must nl:lunt to Base Frame System that the new goals could be met while still leaving as I Suspension many options for Module design as possible. Once F: Will support the Base Frane and keep entire Powertrain in these criteria were decided upon, a list of requirements contact with lunar surface. was constructed. The Base mechanical requirements F: Must be comprised of passive elements. can be seen in Table 2. P: Must support 250kg+ load. -Module: 1: Must connect Powertrain to Base Frane. The cost of transportation is a major constraint Powertrain on colonization and exploration of the moon and other F: Will provide loconl:ltion of entire Base system. planets. It is much more cost effective to have a system F: Must run on provided 18V or lower power grid. that can be easily modified for a variety of missions P: Must not stall under250kg+ full load. once in operation on the lunar surface than to have 1: Must Jll)Unt to Suspension system. Frarre multiple specialized systems. This section will describe F: Will support all Base and Module Systems. the design process for Team NASA CAR's 2012 P: Must be able to support 200kg + Lunabot mass. competition Module. Throughout the process a balance P: Must have minimal deflection under full load and between innovative solutions and proven processes was locoll'l)tion. sought. Taking advantage of insight from our sponsors Physical Module Interface and team members' experiences with working at earth 1: The Module n11.1st rmunt toT-slotted aluminum 8020 via mining operations, the team explored ways to adapt appropriate fasteners. earth mining processes to the specific challenges faced 1: Must be stiff enough so that the nl:ldule load does not warp by NASA on the moon. the base chassis. Power Each team member was asked to bring forth F: Must be disconnected upon drawing >500A of current. F: Must have a red kill switch that cuts power. F: The box must be properly protected fi-om lunar environn--ent. F: The box must be protected fi-om EMF interference. F: The base power system n11.1st provide a way to nl:lnitor the power consumption of the battery. P: Batteries must be able to supply a minimum continuous voltage of 18.5V and a minimum constant current of 125 A. (A) P: Batteries n11.1st weigh <3Kg. P: The box must be completely stable while running. P: The base power system must be able to supply a snl:loth, continuous current to all electron--echanical devices. 1: Must have a quick n--eans of connecting to any nl:ldule. I Controls F: Must provide wireless communication to the Front End. F: Must accept feedback fi-om Base wheel positions. (B) (C) F: Must accept feedback fi-om battery voltage. F: Must accept feedback fi-omcurrent n--easuring circuit. Figure 6: Examples of NASA robots that configw-e F: Must provide control over Base nl:ltors. their wheels for zero slippage neutral tw-ns: (A) Mars P: Must be able to support back end processing requiren--ents. Rover. (B) Centaw-2. (C) SEV. 1: Must communicate with Jl'l)dule via interface. To Table of Contents 5 ideas in which lunar soil could be collected and The concepts considered were given transported. This phase presented a variety of processes, codenames to help separate the design from the however not all of them were feasible for our team to designer. It should be noted that the codenames implement. Also during this time, the Module team reflect the "spirit" of the concepts. The "Aardvark" leaders were tasked with providing requirements for concept was a dual bucket wheel excavator. The whichever concept that would move into Phase B. The "Puppy" concept was a bucket-chain system Module requirements can be seen in Table 3. augmented with an oscillating percussive digger. The After significant discussion and concept "Starfish" concept was a rotating blade/paddle that visualizations using Solidworks, the team agreed that would feed a conveyor system, and the "Dolphin" the optimal excavation approach was to have a digger concept was a percussive shovel that could be driven which fed a center storage hopper and a rear conveyor forth to feed a conveyor system. The digger decision to offload the material. This was a prevalent method in matrix can be seen in Table 4. As one can see, the the teams concepts and one that has been demonstrated Aardvark design was the standout among the group. in this competition and in real mining processes to be The Aardvark, Puppy, and Starfish concepts at the an efficient method of transportation and delivery. time of discussion can be seen in Fig. 7. The main decision remaining in this Module -Data Processing: concept was the type of digger to be implemented. The The purpose of the Data Processing subsystem submitted concepts were narrowed down to four was to provide the user control over the robot hardware designs to collect and deposit lunar soil into the and feedback on the robot status. To achieve this onboard storage. With each design thoroughly objective, the subsystem was further broken into two explained, the team proposed a set of weighted metrics sections: the Front End and Back End. The Front End that could be quantitatively applied. Once the designs would consist of a user interface to accept user input were examined under each of these metrics, they were and display robot status. The Back End would react and ranked competitively against each other and the overall Table 4: Digger Decision Matrix lowest numerical value was chosen as the teams' design. p'f'·!-si"'h·i Table 3: Module Requirements Qorml ~~gr;;ts f . J Time to Completion 0.5 I I 4 Offioading " P: Must have a maximum unloading time of I min. j IS implicity 0.7 4 2 I P:Must not cause significant rmment of inertia changes due to 1 Weight 0.2 3 3 I 2 Penetration 0.8 2 4 2 the process alone. P: Must keep center of mass inside base profile without use of j Digging Modes 0.9 2 3 3 counterweights at all times. Rate I 3 2 4 I _ Percussion 0.3 4 2 3 _u -· Storage: :::: :: : ::::::::::: :: ::::::: 8.3 11.7 11.5 11.9 P: Must keep static profile inside base dimensions. IV: Initial load capacity of2 times the base mass. To be adjusted pending base testing. Di in P: Must have a digging time of 1.5 min. P: Must not cause center of mass to rmve outside of base at any time. F· Must have the ability to collect compacted material. F: Must have the ability to implement a percussive/resonant p~cess to ~n c~~tion. - Power ··~ F: Must safely supply power to all rmdule electronics and mechatronics. P: Must be small enough to be rmunted to the rmdule itself. 1: Must be able to accept the power from the base power supply. ... .... __..._. . """"_. .... ____ Controls ~ ·F"":' "'M--~ u~st provide video feed and other feedback to the Base rmdule. (B) (C) F: Must control rmdule rmtors and actuators via commands Figure 7: The Aardvark (A), Puppy (B), and Starfish received from the Base rmdule. (C) digger concepts. 1: Must receive commands from the Base via a rmdule interface. To Table of Contents 6 respond to requests sent from the Front End while a PID controller, image processing of the Lunarena running background tasks to keep the robot hardware enviromnent, and simple beacon tracking. within its structural limitations. The overall design -System Definition Review (SDR) follows a basic client-server architecture in which the At the end of Phase A the team met with the Back End represents the server and the Front End takes Project Manager for the SDR. The Manager concluded the place of the client. The key advantage of using this that the system requirements were defined and formed architecture is that time critical tasks, such as the basis for the proposed conceptual design. He controllers for coordinated hardware movement, can be confirmed that the system architecture was adequate, placed behind the network latency of the wireless linlc and the ConOps aligned with the mission requirements. The client-server interface also provides the option for After the SDR the team was cleared to advance the different client implementations, such as an project to Phase B. [4] autonomous Module. The Front End and Back End Phase 8: Preliminary Design requirements can be seen in Tables 5 and 6 respectively. In Phase B the subsystem designs went through While the points awarded for autonomy in this several iterations and trade studies were performed year's competition were significant, the team decided to comparing different components and parts. The goal at focus primarily on creating a robust, effective the end of Phase B was to have a design that met "all teleoperated digging platform. Since the dimension and the system requirements with acceptable risk and within mass requirements for the bot shrank from last year's cost and schedule constraints and establish[ ed] the basis competition, the team needed to completely redesign for proceeding with detailed design" [3]. The the Base. This cut down on the testing time for any subsystems evolved concurrently whenever possible. autonomous control systems dramatically; thus there Verification plans for each subsystem were developed. would not be enough time to implement full autonomy -Base: into the contest entry. However, the team decided that it would be -Mechanical: prudent for a subset of members to research In Phase B team members were encouraged to autonomous methods that could be applied to partial come up with preliminary Base mechanical designs that autonomy for this year's competition or full autonomy met the criteria while incorporating the desired for future competitions. To this end, several promising improvements over the previous design. Three designs methods were conceputalized including: IR LED were submitted and compared. The first two options triangulization, Internal Measurement Unit (JMU) with were modifications of the MOLE 1.0 Base design and Table 5: Front End Requirements mostly comprised of retrofitting larger/stronger drive motors while simplifying some of the complex frame. The third option was a complete redesign that ~------~~!)' Contro~--~~--------J W: Must provide access to drive 1mtordirection and velocity. F: Must provide access to change wheel sweeping position. Table 6: Back End Requirements F: Must provide access to controlJmdule 1mtors and actuators. Sexver ' Prirmry F: I Feedback M~;t;-;;~pt~o~~nds fi·o1;th~·~Tient on how to drive the I. F: Must provide feedback of1mtor currents and velocities. robot. F: Must provide feedback of actuator positions. F: Must drive the robot's hardware based on connnands received. F: Must provide feedback ofbattel)' status. ! F: Must be able to stop the robot when commmded by the Debugging client. 'F: Must log all coJTesponden~~ ~th the rob~t to a file. 'F: Must provide feedback on the robot's status to the client. P: Must have a high level of fault tolerance, in particular F: Should provide the amount of energy consumed to the feedback parsing. client P: Must provide connectivity debugging tools. P: Must use less than an average of5 Mbps during a nm. Other P: Should react to user commands with no noticeable latency. F: Must have the ability to execute either client or server side P: Should provide low level hardware control to the client. 1mtion macros. P: Should provide high level task automation to the client. F: Must have the ability to show desired (setpoint) values vs 1: Must communicate with the client over the wireless link. actual (reported) values. 1: Should have a well-defined protocol for conn11unication. F: Must send 500rrn period heartbeat signal when control input is inactive. 0: Should be able to safely handle dropped connections. To Table of Contents 7 incorporated the core mechanics of MOLE 1.0 while robust and effective, they weighed a total of - 12kg. simplifying the overall frame and mechanical design, This was obvious area for improvement due to the large offering several methods of sweeping the wheel penalty for robot mass at the 20 12 competition. positions, and incorporating the new requirements from The task of redesigning the wheels was the outset. The benefit of the first two designs was that delegated to a subset of the Base mechanical team, and they had fewer unknowns in the design, as most of the two competing designs emerged. Both designs design had already been tested in the previous consisted of an internal hub structure supporting a competition. While the redesign had very few knowns, fiberglass surface and "paddles" mounted to the surface it showed a greater potential. After much debate, the for traction. Wheel designs one and two can be seen in decision was made to finalize the complete redesign. Fig. 9. After some discussion and comparison of the Afterwords, the method in which the wheels designs through trade study, the team decided to move were to be swept was considered. The proposed forward with option 2. The wheel decision matrix can methods involved using actuators (like what was used be seen in Table 7. in the MOLE 1.0 Base), a rack and pinion design, and a Each component of the Base mechanical system worm gear driven design. The worm gear method was would be tested to verify functionality. The mechanical ultimately chosen after a closer look revealed that the subsystems could be tested as they were assembled. rack and pinon would be too complicated, and the For example the worm gear sweeping assembly could actuator method would have 50% ofthe sweeping range be tested independent of the Base frame or locomotion. due to the reduced space of the smaller Base. Fig. 8 Finally a Base subsystem test would be implemented by shows the MOLE 1.0 actuator method compared to the driving the Base with and without a mass load and with MOLE 2.0 worm method. different wheel positions. The final maJor decision for the Base mechanical subsystem was design of the competition -Power: wheels. W11ile the MOLE 1.0 wheels proved to be very The Base power system of MOLE 2.0 received a major revamp from the MOLE 1.0 design. This was due mainly to the increased power requirements of the (A) (B) Figure 9: W11eel option I (A) and 2 (B). Table 7: Wheel Decision Matrix Criteria ,Wheel I Wheel2 ,Adwntage I Weight 1.2kg/whccl 1.35kg/whccl Wheel! Conl)lcx due to custom . . f Very s 1mplc, very easy Wheel Compexity spokes and nnunling o to build. 2 cleats. More expensive than Wheel · Cost -? d uc to ad d'· tt·o n a 1 p1nr ecfxapbc npsalrvtcs., nnst 1y Whccl2 rmchining charges. Figure 8: The MOLE 1.0 (top) used linear actuators to Strong enough to sweep the wheels while the MOLE 2.0 design Structural Strong enough to hold hold expected loads, Whccl2 (bottom) implemented a worm gear method. Integrity expected loads. but rmrc robust than Wheel!. To Table of Contents 8 larger motors. The general topology of the power individually to make sure no issues arrised. The system can be seen in Fig. 10. components would then be integrated into the Noting the success of MOLE l.O's electronics electronics box and the whole subsystem would be shielding system, the team decided to use a similar checked for shortages. The power subsystem would enclosure. This would consist of an aluminum box with then be checked during Base subsystem tests and full a removable lid. The main advantage of using an system tests to ensure that heat dissipation was aluminum enclosure was due to its heat sinking adequate and batteries were stable. characteristics. The heat generated by the power components would be quickly transferred to the box, -Controls: which in turn would tranfer the heat to the aluminum The basic controls requirements for the MOLE Base frame where it would dissipate. 2.0 Base subsystem were very similar to the MOLE 1.0 For MOLE 1.0 the team used Sealed Lead Acid system. The main area that the team saw room for (SLA) batteries to power the robot. These batteries have improvement was in the Base/Module controls the advantages of being cheap and easy to usc. interface. In the MOLE 1.0 system, each feedback line However, these batteries could not supply the voltage provided its own individual connector. To interface a and cutTent that the MOLE 2.0 required, and they were Module many connections had to be made. However extremely heavy. After examining alternatives, the team the decision to separate the Base electronics from the settled on Lithium-Polymer (LiPo) batteries. These Module electronics provided the opportunity to greatly batteries arc able to create a much greater voltage and simplify this interface into one connector. current source than SLA batteries, but at a cost: they are Besides the Module interface change and the much more prone to explosions and fire. In order to usc offloading of the Module controls hardware, the Base these batteries, individual ovcrcurrent protection would controls hardware design was nearly identical to the be required for each battery. MOLE 1.0 Electronics module. This included a router Part of the power requirements was to be able to for wireless communication, a Single Board Computer measure the robot's power consumption. This can be (SBC) for processing, motor controllers for driving and done by monitoring both the cuiTent flowing out of the sweeping, and feedback electronics to control the wheel batteries and the battery voltage. The simplest way to positions and read the battery and shunt voltages. A measure current is through a shunt resistor circuit which Base controls flowchart can be seen in Fig 11. simply provides a mcasureablc voltage reading across a Each component of the Base controls subsystem low resistance calibrated resistor. By measuring the would be tested independently as the were acquired to current and plotting it against the battery voltage over verify functionality. The Back End software would be time, the total power consumed can be determined. installed on the main controller to ensure the hardware The Base power subsystem would be tested met processing requirements. The motors and motor incrementally. Each component would be powered controllers would then be assembled as an independent T "' r----7 .... ..__ I ( Q.llnen415 ConnKtor ~ Cur renCti rMCUt>lai liurif'\8 t- / ~::.~ ;---------+\;;;;:::~~=:!, i j_ -{ B•u,Motors Modulf> 1Jn11 ) __i_ .... r Base Motor CCJorCnU nitory/ f Coamndm Cuonnic:t.ract»io n I+ Elf>ctronic.s Figw-c I 0: Base power system topology. Figw-c II: Base controls flowchart. To Table of Contents 9

See more

The list of books you might like

Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.