Competition:

NASA's Lunabotics Mining Competition is a university-level competition designed to engage and retain students in engineering. Students will directly benefit from the competition by developing innovative lunar excavation concepts, clever ideas and solutions which could be applied to an actual lunar excavation device or payload. The challenge is for students to design and build an excavator, called a Lunabot, that can mine and deposit a minimum of 10 kilograms of lunar stimulant(BP-1) within 10 minutes. The complexities of the challenge include the abrasive characteristics of the BP-1, the weight and size limitations of the Lunabot, and the ability to telerobotically or autonomously control the Lunabot from a remote mission control center.

The Lunar Autobot-subsystems

Space exploration is viable only with the help robots. The tasks performed by robots are varied and extensive. Excavation is a main task which helps understand the vital aspects of the lunar or planetary environment. Even within the realm of excavation it would be beneficial to have different types of excavators for different tasks, as there are on Earth. Our team aims at no only building robot that could compete in the competition but also help ISRO in future space missions like Chandrayaan. The team is planning to make the lunabot autonomous along with a sound mining mechanism. The main components in a successful autonomous navigation are precision in maneuverability and its control algorithm. The team is planning on making an innovative mining mechanism. So the team got split in to two sub teams namely the Mechanical and the Electrical Electronics and Programming (EEP ). The goal of the project is to develop a lunar rover compliant with the. Using that approach the major subsystems are the following: 1. Communication Subsystem (COMM) 2. Command and Data Handling (C&DH) 3. Electrical power Subsystem (EPS) 4. Structure and Mechanisms Electrical power subsystem, communication and command & data handling came under the EEP team. The structure and mechanism which include the mining mechanism came under the mechanical team.

The following table shows the schedule

The project life-cycle as a Vee chart

R/A/C are the Requirements, Architectural Design and Concept steps SAITL is System Assembly, Integration, Test and Launch

Command and Data Handling (C&DH) -Control subsystem:

Control Subsystem It must control the whole system for 10 min using the control logic defined in it It must enable the user to switch between manual and autonomous modes wherever needed

It should be able to reply the status and give a feedback of the components of the bot to the user It must provide a simple GUI/command-line too for the user to communicate with the bot

Since the bot must operate in a complete autonomous mode, the team found out that it should need the following things: 1. Should give the control of the system via the communication subsystem using a Server-Client program. 2. Control logic must be defined for all the components that support task subsystem. 3. Ease in writing and compiling the source code. 4. Use an established technology as an aid for navigation Since most of the available components and program resources are compatible with/use Linux based operating systems the team chose to use Ubuntu 11.10/Backtrack 5 Revolution as the operating system that would be installed both on the on board computer as well as on the client computer. Also all the resources are open source. In addition to this using, Microsoft Robotics Developer Studio (MSRDS 4.0) was also considered but later discarded due to the complications involved in it. Now considering the first need i.e., a server-client program, available software were considered. Of which Player, ROS, Apache were considered. They are all prebuilt server programs for Linux. Now since writing a navigation algorithm independently is a complicated task. So the team started searching for platforms that could support writing navigation algorithms for robots. The first thing considered was ROS (Robot Operating System). It was learnt that it is a Meta operating system that provided many of the OS functionalities such as HAL (Hardware abstraction layer), message passing, device drivers for robot specific hardware, libraries and many more. These amazing functionalities drove the team towards using ROS as the Control Platform on our SBC (Single board computer). Also it has been licensed under open source BSD license. The next straight thing was how to navigate? The two main systems that served as an i/p for navigation algorithms are either use an array of sensors(such as IR) with continuous feedback or use some device like 3D laser range finder to map the whole terrain.

The decision matrix between the sensor array type and the Image processing type is as follows: Property Power Illumination Capability in dusty conditions Switching between manual and autonomous operations. Sensors High Not required Yes Requires more equipment Image processing technique Low Not required May fail Easier; No additional equipment required

Range Number of sensors Cost factor Data processed Number of inputs Probability of failure Control Algorithm

Less More Expensive Less More Higher High

More Only one. Cheaper More Less Lower High

The matrix thus said that Image processing technique would be the most suitable one for the requirements of the control system. Yet 2D image processing was a laborious task, 3D data processing using ROS seemed easy. So team started trying for devices suitable for acquiring 3D data. We found that the laser range finders were of high cost (about 3lakh rupees) while The amazing Kinect from Microsoft was very cheap (about 10,000 rupees) and also was accurate enough for our purposes. After that we found out that in order to map a terrain in 3D we need to use an algorithm called SLAM (Simultaneous Localization and mapping). Using SLAM algorithm and Point cloud libraries it is possible to possible to create a 3D terrain map (which contains RGBD data for the point cloud). All these are done using ROS. Also there is a package in ROS called RGBDSLAM which can directly give out the 3D map along with the localization of the system. All we need was to apply a control algorithm to navigate autonomously and do the assigned task. The task now was to devise a new or modify an existing navigation algorithms (for example the black hole algorithm etc.,) .Presently a literature survey is carried on the existing autonomous navigation algorithms. Another main task is to identify the hardware components needed to support motor controllers, ROS and Kinect. Initially Versa logic and Fitpc-2 SBCs are taken into consideration. Search for better technologies is being carried on. Conclusion (Control and communication subsystems): Use Linux on an SBC with atom processor on board. ROS will be the virtual operating system for the bot. Use SLAM on Kinects point cloud data to generate a 3D map. Use a navigation algorithm on that 3D map to perform the designated task.

In order to accomplish the tasks established previously, the first main thing was to learn and have a strong understanding of concepts in C++. Next the basic elements of computer science such as serial ports, Internet protocols, DNS servers, Drivers etc which were essential in order to understand the functionality of ROS. The source for defining the elements to be learnt was the online wiki of ROS. (http://ros.org/wiki). ROS has inbuilt support for interfacing robot specific hardware such as Phidget sensors, Arduino etc.

But the required operating voltages were beyond the scope of Arduino. Hence the Phidget motor controllers were taken to be used in the bot. The next task was to understand the data structure in ROS programming. So using the knowledge in C++ the team set to understand the it using the online documentation of ROS. We were able to publish messages from the board to the computer. Hitherto ROS works using publishing and subscribing for messages. The source code is as follows: #include <ros.h> #include <std_msgs/String.h> ros::NodeHandle nh; std_msgs::String str_msg; ros::Publisher chatter("chatter", &str_msg); char hello[13] = "Hello IIST!"; void setup() { nh.initNode(); nh.advertise(chatter); } void loop() { str_msg.data = hello; chatter.publish( &str_msg ); nh.spinOnce(); delay(1000); } The above code would publish the message Hello IIST! to ROS master server We were able to control a servo motor using the Arduino board. **We have been able to create a 3D map of a room using Kinect and ROS with the help of its package RGBDSLAM. The test was accurate enough. In order to compare the accuracy visually the real image and the built image were compared. The images were almost the same. The main difference occurred was that the image from a Digital camera contained pixels while the built image contained point clouds. Due to non-availability of Kinect the in college, the team was not able to show it to the advisor. Now since Kinect may not work properly in highly dusty conditions, this problem was reported to the task subsystem in order to make sure that such things wont happen while performing tasks.

Communication Subsystem:

Communication Subsystem It must be able to establish a connection between the user and the bot wirelessly The bandwidth usage must not exceed 5Mbps It needs to use the Wi-Fi as the network and must use IEEE 802.1 b/g standard for communication

Hitherto, it was understood that using a Linksys Wi-Fi router (as WAP: Wireless access point) would suffice the requirements for this subsystem. This follows the IEEE 802.1 b/g standard of communication which uses TCP/IP protocol. Also since the bot will be autonomous in nature there will not be much data transfer. The main data transfer would consist of sending the activation and deactivation commands. If at all any problem occurs the system on the bot will report the status and will give a feedback about the errors that occurred during runtime. Also it was decided that I would be safe if we take feedback from the voltage sensors in regular time intervals. Since the wireless antenna consumes more bandwidth it was decided that using a D-Link Ethernet to Wi-Fi Bridge will suffice the required conditions.

Electrical power Subsystem

Power Subsystem It must utilize18v standard power sources to power the system It must be able to supply enough current to all the components for 10 min It must contain an emergency stop button to stop the bot whenever needed It must provide a simple interface for other subsystems to connect to it

Structure and Mechanisms wheel:

Wheel design special considerations for a planetary rover: Restricted transport mass and volume Potential variations in temp -230 to 130 0C

 Exposure to radiation Rolling and sliding contact with un-weathered regolith and dust particles Hard vacuum Low gravity field Considerations for the competition run: Steer-ability of the wheel Supporting the whole weight with optimal sinkage (static and dynamic) Traction lateral and longitudinal for movement and control Ability to overcome obstacles

Promising wheel designs

Wireframe wheel (lunar roving vehicle): 1. Wheels of wire mesh (piano wire) with titanium cleats for threads. 2. Stiff inner frame and solid aluminium hub 3. Compatible with lunar environment, deforms significantly giving high tractive capability 4. Has low fatigue life due to stress concentrations and looped intersections 5. Thread strips arranged in chevron pattern provide side traction and prevent drifting 6. Large spacing between thread increases forward thrust capacity 7. reduced diameter and making the thread strips wider to protect side walls increases wheel life. Hoop design wheel: 1. Titanium outer band, hoop spring elements and a rigid aluminium hub with spokes 2. Grit added to the outer surface of the titanium grit increases wheel-terrain friction and thrust capability 3. The bump stop limits excessive deflection of the hoop 4. Excessive vibrations at critical speeds 5. Modified hoop (thinner and elliptical) had sufficient fatigue life 6. Reverse bending of hoops occurs when rolling over sharp obstacles leading to failure

Solid aluminium wheel (mars rovers): 1. Made out a single aluminium block no waste (scar) mass such as bolts, rivets, etc. making it very light 2. Cleats added traction to the wheel.

3. The wheel's shape bears the load continuously from inside to outside and prevents it from riding up on its outside edge. 4. Spiral flectures are designed to absorb shock and to protect the rest of the vehicle during driving 5. The outside of the wheels are anodized, or covered with a black coating, to provide additional strength 6. The spaces in the spiral flecture were filled with solimide (open cell foam) prevented dust rocks from being collected inside the wheel.

Marsokhod wheel design: 1. titanium wheels with cleats for traction 2. hollow conical shape provides more surface for load bearing 3. Design enables the rover to conform passively to very rugged terrain. 4. The shape of the wheels provides low ground pressure 5. The risk of high centring the rover is minimized by enclosing most of the frame. 6. The amplifiers, motors and batteries are mounted inside the wheels to produce a very low centre-of-gravity

Now considering the above things the team established a specification that a wheel similar to that of a marsokhod would suit the needs. Using the calculated dimensions of the wheel and after simulations using Autodesk Inventor Pro,a final design has been established. The motor and its gearbox will be fitted in to the wheel itself in order to reduce mechanical complexity.

The final wheel design.

Structure and Mechanisms

steering:

Taking the Drive subsystem requirements in to consideration, few numbers of steering schemes were examined. They are also being compared using a set of parameters. Kinematics of steering schemes

Steering comparison for 4 wheel lunar rovers

The main factor that influenced the consideration of a particular type of steering was the amount of control logic that stood behind it. The next main thing was the manoeuvrability. Of them skid and independent explicit steering types had low amount of control logic and high manoeuvrability. But skid type steering is eliminated because the surface was too soft so chances are more that it would become a mess during the run .Also since the manufacturing was possible with very less control logic (it was mainly due to its symmetry) the independent explicit steering looked the most promising one. Hence concentration was turned on to this type of steering in order to improve it and also to reduce the mechanical complexity. Conclusion for the steering component: The independent steering will be the most suitable one for that comply with the subsystem requirements a forth mentioned.

Now that the bot is being autonomous it should be fast enough to perform the tasks. The next considerations were either to use oblique or right angled steering. For oblique steering the wheels needed to rotate at the same place, acquire the required angle, then reorient an proceed in the required direction. The other was using right angled steering. There will be no oblique turns instead there will be only right angle turns. Analogously if we stand on a graph sheet and are asked to move only along straight lines that corresponds to a right angles steering. The time taken for the bot to reach target from a specified position using oblique steering was larger than that was for a right angled steering. Hence right angled steering was chosen to since it best fits the forth mentioned requirements. The next task was to simulate the stability of the steering. The steering type was tested using servo motors and wheels from the LEGO Mindstorms NXT 2.0 kit available in the robotics Laboratory. The system was stable and was able to gain traction fairly on hard ground but the motors were not powerful enough to test on a lunar stimulant.

Without transformation

With transformation

Structure and Mechanisms chassis and drive:

Chassis Subsystem It must support at least 110kg weight, and bear the forces generated It must create a slot for power source It must provide installation slots for other modules

Drive Subsystem The should be able to drive a load of 110kg The system should shield the motor from regolith It should not sink in to regolith It should gain traction on regolith It must be self-capable to relive from struck situations The manoeuvres must comply with the level of control logic the control subsystem will be able to establish

using the constraints provided by the other subsystems the design of chassis was initialized. Using the forth mentioned specifications and trade studies it was found out that the Aluminium80/20 T-Slot extrusion best suited the chassis needs. Using these specs a preliminary design was established and has been simulated for stability.

Structure and Mechanisms excavation:

Objectives 1. the robot should move less. 2. should be able to get more regolith in less time 3. Discipline (ordered) way of digging 4. use only a part of mining region to be safe. 5. the mechanism should be compact and compressible.

Four types of digging mechanisms 1. 2. 3. 4. conveyer belt (direct digging with conveyer belt) the Archimedes thread method) BUCKET wheel mechanism JCB mechanisms

Advantages of conveyer belt This mechanism is fast to get mud. Disadvantages of conveyer belt The robot should move fast for find mud, it cannot get mud by just standing at one place. The controlling will become complicate. Since this robot is autonomous the robot will move slow and smooth. Digging using conveyer belts leads to dust which is dangerous for Kinect to work. Dumping also causes dust. Advantage of Archimedes mechanism This mechanism is mainly used to get water from lower level ground to higher level ground. It produces less dust. Disadvantage of Archimedes mechanism This can dig but it cannot get the mud into bin easily. This is inefficient and requires high power to transfer mud from one place to another. This mechanism is mostly used in getting water out of river. Advantages of bucket wheel This is fast to digger and used to hard surfaces. Disadvantage of bucket wheel This has the same as conveyer belt and the bucket must very big to get the mud in the bin. The bucket requires high torque. The making of it is not so easy. It leads to dust. Advantages of JCB If the ground is hard then it is better to use JCB and dust is less. Disadvantage of JCB In this mechanisms we should control the motors and actuators in very efficient way if and this way is not very quick. The robot must be more stable comparative to other mechanisms.

We got conveyer belt mechanism to get the mud faster to bin. To use conveyer belt the availability of mud should be increased to make the robot stable. We also know that the bucket wheel is a fast digger. For the sake of gathering mud we can use big Archimedes screw because it reduces less dust. Can keep spikes at the edges of the screw to dig as well as collect. We use a conveyer belt to get mud from gather point.

This confirms that conveyer belt can be used to bring regolith, so there should be a mechanism the gaiters mud with making dust. This type of mechanism is used in blowing snow away, combining those two the digging mechanism is good. Since the availability of mud is high, speed of the conveyer belt is slow and the size of the bucket on the conveyer is big. This can reduce dust to the minimum.

Structure and Mechanisms dumping:

Objectives: 1. 2. dust less quick

Mechanisms possible 1. 2. Using conveyer belt Dumping directly with the help of actuators.

Archimedes screw. Since maximum height of the robot is .75m and bin is .5m height. So, giving ramp is not possible. Archimedes screw is dust resistance but slow and inefficient. If we use conveyer belt it leads to dust. The only option remained is directly dumping the mud into bin using actuators. The preliminary designs for task modules are as follows

Of these it has been figured out that using an Archimedes screw type task mechanism best suited the needs. But before moving on to a conclusion it needs to be tested. Also a constraint has been laid down by the control subsystem. So a need arose to test the dust factor of the mining mechanism. A small portable conveyor belt has been designed to

accomplish the task. The corresponding parts were machined in using the facilities available in the workshop. Now it will be tested for various bucket-chain angles to determine which one would result in less dust. Then the actual mechanism will then be tested.