proposal 23 aug

7/28/2019 Proposal 23 Aug

1/14

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


2/14


3/14

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 whichPlayer, 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 Sensors Image processing technique

Power High Low

Illumination Not required Not required

Capability in dusty conditions Yes May fail

Switching between manual and

autonomous operations.

Requires more equipment Easier; No additional equipment

required


4/14


5/14

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

#include

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 tasksubsystem in order to make sure that such things wont happen while performing tasks.

Communication Subsystem:


6/14

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 SubsystemPower 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


7/14

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 capability4. 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.


8/14

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


9/14

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.


10/14

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. Henceright 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


11/14

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.


12/14


13/14

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. dust less

2. quick

Mechanisms possible

1. Using conveyer belt

2. 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


14/14

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.

proposal 23 aug

Documents