NASA Robotic Mining Competition

Transcription

1 Abstract University of Arkansas CSCE Department Capstone II Preliminary Report Spring 2015 NASA Robotic Mining Competition Susan Everett, Rachel Findley, Carl Smith In the 1960s, NASA brought to mankind impressive advancements in space exploration, enabling travel to the moon. Since this time, Mars has ignited human curiosity as well. As Earth s second closest neighbor and more suitable environment for exploration than Venus (Earth s closest neighbor), Mars captivates us with it s implication for greater knowledge about our Solar System. In order to improve current technologies for exploring Mars, the NASA Robotic Mining Competition is held annually to encourage the development of an innovative robot that could help humans acquire greater knowledge about Mars. The robot mission is to navigate the simulated Martian chaotic terrain, mine the Martian regolith in 10 minutes, and preserve the soils until they reach the researchers. This year s University of Arkansas team includes students from the Mechanical, Electrical and Computer Science/Computer Engineering (CSCE) department. This paper focuses on the computer technologies that are used in the robot such as the connection between the controller and the robot. The first phase would be remote control telemetry. In this phase, the Raspberry PI and Arduino would be utilized to connect the controller and the robot. In the next phases, the mining robot could use autonomous behavior to work independently. Problem Rachel Findley The last 40 years have seen more explorations to Mars than any other planet in our Solar System [5]. In recent years, we have successfully landed rovers capable of exploring the Martian landscape. Drilling from the Opportunity Rover has revealed mineral ores and water in Mars soil. As our second closest neighbor and most viable option for additional mineral resources and possible habitation, mining of Mars may become necessary in future years. [7] Mining of Mars soil due to its specific qualities as well as due to Mars unique environment has presented many problems which need to be solved. In an effort to attract fresh ideas for rover technologies, the NASA Robotic Mining Competition invites University students to work together to produce their own robots. The winners of the competition will receive the Joe Kosmo Award for Excellence. The competition seeks to simulate challenges an actual rover would experience when navigating Mars, with its rocky, chaotic terrain and 3/8ths Earth s gravity.[1] The CSCE section of the University of

2 Arkansas group will focus a great deal on the communication challenges as well as the autonomy challenges proposed by the competition. As clearly stated by the competition requirements, the robot must be controlled from a remote location. Issues that need to be considered in the design and implementation process include the lag that will be introduced in order to simulate the lag experienced when controlling a robot on Mars. Other communication issues to consider are the amount of data required to send messages and encryption. Self autonomy, although optional for the competition itself, would be an ideal capability for any rover on Mars. The CSCE group will be heavily involved in this part of development. Self autonomy would also present many challenges in implementation such as avoiding obstacles and craters. Objective Rachel Findley The objective of this project is to work with students from different Engineering backgrounds at the University of Arkansas in order to participate in the NASA Robotic Mining Competition. This year, the CSCE group will focus on improving the communication component as well as improving manual control functionality and developing self autonomy for the robot. Approach Carl Smith In order to realize robot behavior objectives, a new communications network will be integrated into the system. Once the network is in place and functioning correctly, code for context sensitive motor actualization can be produced in parallel with an added simulation component. The simulator, although not required to meet competition requirements, will be ideal for testing code in cases where limited access to the robot might prolong times in between implementation cycles. Additionally, manual control improvement takes precedence over non crucial self autonomy functionality and will be the focus of our efforts on a case by case bases, depending on hardware availability, which is subject to change. Background Key Concepts Susan Everett, Carl Smith The key technologies that are related to the project are the Raspberry Pi, Arduino, ROS(robot operating system), V REP simulator, Xbox controller and infrared/proximity sensors. The Raspberry Pi is a small computer that can be connected to a tv or computer monitor and programmed by keyboard and mouse in a variety of computer languages including python and scratch. It was originally designed to help teach people of all ages about computer science and learn more about computer languages. It was engineered by the Raspberry Pi Foundation which is a registered educational charity.[6] The Raspberry Pi that will be in the project is used to communicate between the computer (via wifi) and the Arduino (via cable) and will be considered the master in the master slave architecture. The Arduino is a small micro controller that can be used in a variety of projects that comes in a variety of sizes and capabilities. It can be used alone or in conjunction with a computer. The Arduino software is free to download and uses a C type computer language that is easy to understand.[8] Since it is inexpensive, can be run on multiple platforms and is open

3 source hardware and software, it makes the ideal micro controller for the four motors on the wheels. Four Arduino Uno s will run the four motor controllers built by the Electrical Engineers. Also the Arduino Mega from last year will be used to take in sensor data and control the bin/extractor. All Arduino s will be considered slaves in the master slave architecture. ROS (Robot Operating System)[2] is an open source API which allows inter process communication (node geometry framework) through message passing. Nodes are used to perform computations used for sensor and motor control as well as for control and monitoring tools. The network includes node swarms maintained in other computers where ROS is installed. A 3D visualizer, called R VIZ, provides visual feedback of robot sensor data. The framework also allows the sending of Topics which allow for asynchronous communication over TCP/IP socket connections. Messages sent can include primitive types, arrays of primitives, data structures, nested structures/arrays. Proximity sensors are being added to the list of components that will be used in the project. Six to eight Sharp Long Distance Measuring Sensors will be attached, possibly two to each side of the robot. This was decided so that autonomous behavior could be added to the code and some of last years issues could be resolved. An Xbox 360 controller was also added to make the robot easier to drive. ROS also has a joystick library that would enable the team to add this feature. V REP is an open source simulation environment for robots. Important features include sensor simulation, 3D physics engines, complex terrain/obstacle modeling, collision detection, and external model robot control. The GUI provides drag and drop options for models in or out of real time as well as scene visual hierarchies[3]. Related Work Susan Everett Currently there are a few successful Mars rovers that are in operation. Opportunity has been residing on Mars for over ten years (even though it was only supposed to work for 3 months) and is still surfacing rocks and finding soil samples. [7] Launched in July 2003 by NASA and landing on Mars over six months later, this rover has been exploring the crater Endeavour, 33 kilometers from where it first touched down. [12] Curiosity or the Mars Science Laboratory(MSL) is also working on Mars and has made excellent work of its time while there. It was launched in November of 2011 and touched down on the surface of Mars in August of It is much larger than the Opportunity rover coming in over three times as long and is twice the weight. Both the Curiosity and Opportunity rovers have found evidence in the last year that Mars in its youth could have supported life with a water rich environment. [11] [12] In June of 2003, one month before the launch of Opportunity, NASA launched the Mars Exploration Rover Spirit which landed on Mars in January of 2004 a few weeks before Opportunity. Spirit remained operational until 2010 when it became stuck in some sand. [12] According to NASA, even though it was stuck, it was still operational. NASA continued using it as a stationary science station until 10 months after it initially got stuck when they lost contact with it. Although it is no longer operational, in its lifetime, Spirit also found evidence of water on Mars. [7]

4 Design Use Cases Rachel Findley, Carl Smith and Susan Everett Use cases have been motivated by the requirements outlined by the NASA Robotic Mining Competition. These include navigating the terrain using manual controls, simulated robot behavior, and navigating the terrain using autonomous behavior. Use Case: Navigating Terrain using manual controls Author: Rachel Findley Primary Actor: Arduino x4 Goal in context: Send commands to the wheel motor actuators Preconditions: Commands are sent from the laptop to the raspberry pi and then to the Arduino Trigger: User input from laptop Scenario: 1. User sends command from laptop 2. Raspberry pi receives command via wifi 3. Raspberry pi sends command to Arduino units 4. Arduino units individually control each motor s movements using motor controller 5. Each Arduino responds to sends encoder and temperature sensor data Exceptions: 1. A state change occurs due to sensor readings and appropriate counter behavior and notification messages are performed (example of crucial autonomous behavior)

5 Priority: High Channel to Actor: Command sent via wifi from laptop Usage Frequency: Used back up if non crucial autonomous behavior fails Secondary Actors: Laptop, Raspberry pi, motor controller, wheel motor actuators, temperature sensors and encoders Channels to secondary actors: Laptop: wifi Raspberry pi: wired, TCP protocol wheels: wired Open Issues: 1. When are commands ignored? 2. Are there levels of priority for sent commands: eg. some commands being accepted regardless of state? Use Case: Simulated Robot Behavior Author: Carl Smith Primary Actor: V Rep Goal in context: Robot model accurately displays environmental sensitive behavior

6 Preconditions: Actuator/sensor drivers properly functioning between ROS and V Rep Trigger: Simulated environmental or controller input Scenario: 1. Input received from simulator or user input 2. ROS directs data to appropriate custom or provided driver nodes 3. Output data is then sent to V Rep which produces and displays behavior which may or may not affect actuators depending on state. 4. Actuator case: go to scenario 2 5. Communication case: robot sends response message to user about sensor data and behavior which was or was not taken. Priority: Channel to Actor: Usage Frequency: Secondary Actors: High V rep through ROS Weekly at least, every other day at most Crucial self autonomous state, well as communication nodes. Channels to secondary actors: ROS : Network Open Issues: 1. What sort of state changes produce actuator behavior? 2. What sort of state changes produce message responses?

7 Use Case: Navigating Terrain using Autonomous Controls Author: Susan Everett Primary Actor: State Nodes through Robot Operating System (ROS) Goal in context: Utilizing information from peripherals then reevaluating necessary behaviors Preconditions: A command is sent from the laptop to ROS(Raspberry Pi) to start autonomous behavior. Trigger: User input from laptop (start). Scenario: 1. User sends start command from laptop 2. ROS(Raspberry Pi) receives command via wifi and evaluates state 3. ROS sends command to Arduino to move appropriately 4. Peripherals detect obstacle and send information back to ROS 5. ROS reevaluates and sends corrected behavior to Arduinos 6. Robot reaches dig site, ROS sends command to stop wheel movement and start excavating regolith with collection system 7. Excavating ceases after allotted time and ROS sends command to stop collection system and move back to dump site 8. ROS reevaluates and sends corrected behavior to arduinos 9. Robot reaches dump site, ROS sends command to stop wheel movement and lift bin to dump collected regolith in dump site collection bin Exceptions: 1. Autonomous behavior fails or there is a need for overriding autonomy with manual controls. Priority: High Channel to Actor: Command sent via wifi from laptop Usage Frequency: Primarily used unless manual override is needed Secondary Actors: Laptop, peripherals, motor controller/arduino Channels to secondary actors: Laptop: wifi Raspberry Pi/ROS: wifi and wired Arduino/motor controllers: wired Peripherals: wired

8 Open Issues: 1. When manual override fails to take back commands from autonomy. Requirements and Design Goals Rachel Findley, Carl Smith Many of the current design goals have been motivated by problems that arose from last year s robot design: Error handling in communication: if the connection is dropped the robot will repeat the associated action for its last command; this occurs between the Raspberry Pi (which sends a char value) to the Arduino unit responsible for motor function. The connection between the Pi and the Arduino unit is prone to drop when interrupted, and is more so the case with the laptop/pi link than the Pi/Arduino. If the robot is not turned off and the command program in the laptop tries to establish an IP connection to handle the robot, the program will crash. The Arduino is currently hard coded to accept certain char values to send motor commands. We might want to move this functionality to the Pi unit. Encoders might be added to the wheels to track the distance moved by the robot, we can work with these when developing adaptive behavior. Instead of sending sequential single commands, implement a way to send/process a batch file. There is currently no feedback of instruction acceptance from the robot. We can implement this along with a way to send from the base(laptop) a command to manually or automatically initiate the robot's accepted command(s). Install Ubuntu on the laptop and Arch Linux on the three on board computers, considering both Linux distributions are compatible with ROS[9]. The current micro computers are limited by running heavier weight operating systems. Setup the ROS communication network between our three computers. Develop accurate custom robot models and driver wrappers within V REP and ROS, if necessary. Create ROS control and receiver code in the simulator for interchangeable control between hardware and the simulator via joystick.

9 Detailed Architecture Carl Smith, Rachel Findley, Susan Everett i. Architecture and Technologies Used Above shows the current design which incorporates planned components with field colors separated according to primary computer controlled systems. The architecture was inherited from a project currently in development along with two planned modifications. The first is highlighted in blue, which covers the ROS network: shared between the primary PC along with the on board computers (attached via Ethernet switch). The second is highlighted in gold, which involves the integration of V REP along side ROS. The green field deals with the motor control of four wheels; 4 Arduino units are being used to send motor actuator input and receive rotary encoder and temperature sensor data for the Raspberry Pi. In the red and orange fields, sensor data of the environment or the robot s relation to it, are sent to their respective embedded, computer systems. Another Arduino unit may be used to direct sensor and perform bin actuator control; however, hardware components are subject to change.

10 In the next design, the ROS network example field contains a mock up of node connections which represent developer program implementations for hardware (or simulated) robot component handling, as well as for monitoring and control tools. The network only shows two instances of node registration for message passing (topics), but in reality all nodes will have to register for connections to other nodes in the swarm as publishers or subscribers; the master node, which is linked to the primary computer, will act as the centralized server, negotiating connections for the network. The steps taken to refine the inherited design involved assessing current requirements and reading about competing simulation and communication frameworks (documentation and tutorials). The decision to use ROS was based on it s centralized communication features (which would aid in solving feedback issues) as well as the benefits of using V REP for remote incremental, testing, data monitoring, and simple expandability of future software modifications to the system. Additions to the design were added in a way which highlight these important features. With respect to R Viz (detailed in our previous report), design for the model has changed by removing the component due to the type of visual feedback devices we ll be using: cm infrared, ray, proximity sensors; R Viz would be preferred for point cloud generation of

11 an image, but for simpler analysis, using ROS s rqt_plot package would allow us access to 2D graph plotting without the overhead. The simulator also has become considerably more important due to delays in the state of the hardware compared to our initial expectations. That being said, the majority of our current design is centered around our 3D model, which will ideally reduce the amount of irrelevant or incorrect code produced by our team while the hardware is undergoing maintenance and development. ii. Interface Design ROS control nodes will be implemented to provide singular code for both the simulator and the physical model, in terms of control, sensor and actuator handling, and possibly autonomous behavior. Lua scripts will need to be created on the receiving end of the simulator in order to offer similar input/output handling into ROS. This also means that for every encoder and actuator on board the robot, there will likely need to be a counterpart in the simulation, alongside similar tolerances for handling physical components. Sensor data can also be tied into V Rep with custom nodes and loaded into graph frames for side by side comparisons. iii. Implementation ROS: Aside from our primary computers, we decided to forego the installation of ROS on Archlinux due to support issues and the fact that Raspian (the official OS for the Raspberry Pi) can operate quite efficiently with its GUI disabled. We also decided on integrating ROS Indigo, despite the increased support of older versions due to Indigo s age, documentation, and comparable ease of use. Simulator (V Rep): Above displays the current simulated model of the robot, complete with two pairs of the aforementioned infrared sensors, four wheel motors, and a functioning excavator

12 unit. The current design of the excavator was taken from the team s latest Solidworks file, however, all joint and motor information was lost during the transition. The current design was built on top on a conveyer belt design provided by V rep and then heavily modified to produce analogous functionality to the physical counterpart. A stretch goal for the project is to create a 6 bucket scoop system to mimic the actual hardware although the current design has close enough functionality to reduce the priority of this task. Regolith extract is approximated by primitive cuboid shapes, as is the invisible collision layer of the robot. Both were created using simple shapes in order to decrease computational costs, which can range anywhere from 4 frames per second under a heavy load, to about 30 for an inexpensive scene. On the excavator end, a special collision layer was made, matched to the regolith, but distinct from the terrain, in order to simulate extraction without having the unit interfere with movement by being partially submerged. Lua scripts tied to the robot body and the extractor are used to generate stand in code for control and movement. Current operations include forward, reverse, left, right and zero point turning. The unit currently operates off of keyboard input, but once communication code is complete, we can tie ROS control to the scene. Torque and weight values are also being manually migrated from Solidworks and spec sheets from our mechanical engineering team mates as well as assistance for creating fluid dynamics for the terrain to help imitate the physical properties of driving through the fine moon dust like material we ll be navigating through during the competition. Above shows off the IR sensor distance data over time for the front and rear after interacting with the wall using a zero point spin. This data is currently being used to handle unmanageable terrain avoidance and the unit final positions will eventually be used to determine where their physical counterparts will go on the actual machine..

13 Additionaly sensors will be added to the sides when they become available to the hardware. iv. Lessons Learned When participating in Robotics projects, there is a particular hierarchy in access to the robot. First, the Mechanical Engineers develop the physical design and build it. Then, the Electrical Engineers build custom circuits and wire the robot. Lastly, the programmers are able to test their code on the robot. Once this hierarchy was understood, it became clear that in order to test the code incrementally, the simulator would be important. Because of this, the simulator became the highest priority. v. Potential Impact Due to the extent of documentation with ROS and V Rep, future teams working on the robot will have more options on the software end to apply new design ideas and to see how they work within the system before committing to an addition. Access to the robot model will also allow for incremental coding in order to limit wasted code on untestable or unavailable hardware subject to change. vi. Future Work Creating a 3D real time visualization of the robot s environment using hardware capable of producing a depth map (such as Microsoft s Kinect camera) along with R Viz is a stretch goal the team hopes future students will be able to implement. This would allow for better manual manipulation of the robot as well as improved autonomous behavior. Other future work would include utilizing shorter range IR sensors to ensure avoidance of blind spots around base of robot, especially the wheels. Much of the future work is in the area of autonomous behavior. The simulation will aid in its development. Autonomous behavior that could be implemented would include path finding algorithms (using the camera data) which would allow the robot to navigate the terrain independently. Risks Susan Everett, Rachel Findley, Carl Smith Risk Failure at competition Not completing on time for competition Failure to reproduce movement control using ROS Conflict with hardware due to physical modifications. Risk Reduction Intensive testing Strict deadlines for deliverables and incremental testing Integrate ROS during the Fall 2014 semester Keep up to date with and periodically participate in the extended group s plans for altering the robot.

14 Tasks Carl Smith, Rachel Findley 1. Co mmunicate with team: materials requests, file requests, material info requests RF, SE, CS 2. Set ourselves up as contributors on GitHub RF, SE, CS 3. Establish connection between controller computers and Pi CS, RF, SE 4. Configuration of Pis CS, RF, SE 5. Become familiar with using github repo using software of choice CS, RF, SE 6. Establish connection between Pi and 4 Arduinos using I2C SE 7. Accomplish control of turtle sim via laptop master RF 8. Accomplish ROS/VREP bridge RF, CS 9. Fine tune simulation parts (correct weights and torque values) CS 10. Add controls for bin dumping and excavator power in simulation CS 11. Fine tune movement code in simulation CS 12. Accurately simulate competition terrain in V rep CS, SE, RF 13. (ongoing) Adjust simulation code to accept corresponding ROS communication nodes CS 14. Tie in ROS joystick control to V Rep to move robot RF 15. Create ROS sensor handlers RF 16. Create ROS actuator handlers SE 17. Create ROS reactive handlers (uses sensor data for avoidance, for example) RF, SE 18. Complete proper movement for robot SE, RF, CS 19. Complete bin and excavator functionality for robot SE, RF 20. Produce working demo of robot for competition RF, SE, CS 21. Produce accurate simulation demo for competition CS 22. Testing CS, RF, SE

15 Schedule: Week January February March April 1 X Continue 6 Start 7 Finish 4 2 X Continue 6 Continue 7 Continue 6 Finish 18 Start 19 Manual Control will be finished Continue 6 Start 9 Start 17 Finish 19 3 Start1-Ongoing Start 2 Start 3 Start 4 Finish 5 Continue 6 Finish 7 Continue 6 Start 14 Finish 9,10,11 17 th = Preliminary Presentation Finish 17 Finish 20 Finish 21 Finish 22 4 Finish 3 Start 5 Start 6 8-RF, CS Continue 6 Finish 6 Finish 11 Start 15 Start 16 Start 18 May 5 th = Final Presentat ion Start 12 Deliverables Carl Smith Proof of Maintaining Current Functionality (for extended Robotics group) Code Final Report Simulator Demo for Competition Research Paper for Competition Key Personnel All Students: Susan Everett Everett is a Senior Computer Engineering major in the Computer Science/Computer Engineering (CSCE) Department at the University of Arkansas. She is currently taking Artificial Intelligence and has completed Embedded Systems, System on a Chip and Computer Architecture classes. Everett will be responsible for communication from peripherals such as sensors and camera to help provide autonomy for the robot and assist in passing information from the Raspberry Pi to the Arduino and vice versa.

16 Rachel Findley Findley is a Senior Computer Science in the CSCE department at the University of Arkansas where she has completed Programming Paradigms and Algorithms and is currently taking Artificial Intelligence and Formal Languages. She has also had some experience learning the basics of computer hardware via her Digital Design and Computer Organization classes. Findley will work closely with Carl to implement ROS and V REP in the existing framework. Findley will also work to improve existing communication issues. Carl Smith is a Senior Computer Science major in the Computer Science and Computer Engineering department at the University of Arkansas. Related courses completed and enrolled in include Programming Paradigms, Software Engineering, and Artificial Intelligence. This student s objectives will include ROS and V REP implementation into the current framework along with creating an accurate 3D representation of the robot. Champion/Advisor name, Industry champion/professor: Dr. Uche Wejinya Dr. Uche Wejinya is a professor in the Mechanical Engineering Department at the University of Arkansas. He mentors the NASA Robotic Mining Competition group at the University of Arkansas. Dr Uche Wejinya has B.S. and M.S. degrees in Electrical and Computer Engineering and has interests in mechatronics, control systems design and applications, and robotics.

17 References [1] NASA Robotic Mining Competition, da [2] Robot Operating System, [3] V Rep, [4] ROS wiki page, [5] Mars Exploration topics/space missions/missions to mars.html [6] Raspberry Pi, is a raspberry pi/ [7] Life on Mars/water resources video from nasa on 10th anniversary of marsrover program/?_php=true&_type=blogs&module=search&mabreward=relbias%3aw%2c%7 B%222%22%3A%22RI%3A13%22%7D&_r=0 [8] Arduino, [9] ROS Tutorial: [10] Player: [11] Old Mars Rover Finds New Signs of Life, mars rover finds new signs of life/ [12] Missions to Mars, topics/space missions/missions to mars.html