Back to the first page   Back to the first page.
Reference information and image gallery   Next page: Reference information and image gallery.

A detailed look at the systems

The system consists of the rover and the lander mock-up, and the control computer.

The rover has the following modules or sub systems:

 

The MiRo rover. Image: SSF

The docking and sample delivery port (DSDP) is divided into following parts:

The software is presented on the last chapter:

 

The MiRo rover. Image: SSF






Rover Functional Mock-Up, RFMU

Rover

Rover Functional Mock-Up (RFMU) is a tracked tethered vehicle, serving as a platform for DSS.
It's function is to enable DSS to sample in desired locations and to deliver these samples back to the lander.

Articulation

Articulation of the payload cab makes it also possible to adjust the clearance of RFMU. This feature significantly improves the roving ability. Clearance can achieve even negative values. This makes it possible to operate in capsize position. The articulation actuators are equipped with angle sensors to determine the pitching angle and the height of the payload cab.


Video clip: Drilling Subsystem in operation
[size: 21 Mb, type: wmv]

Video clip: Rover articulation abilities
[size: 8877 kb, type: mpg]

Video clip: Preparing to drill
[size: 6885 kb, type: mpg]

Video clip: Rover pulls >10kg load
[size: 6885 kb, type: mpg]

Video clip: Rover climb-test
[size: 11721 kb, type: mpg]

Video clip: Rover on soft sand
[size: 7315 kb, type: mpg]

 


Payload cab

The payload cab is totally reserved for DSS. Payload cab can be articulated. This makes it possible for sampling angle to range from vertical to horizontal.

Tracks

Two tracks are needed to guarantee that RFMU is able to rove even in very difficult terrain. DC-motors with attached encoders and gears for roving are located inside the tracks. Track 1 additionally accommodates a capacitor, connected to the main power circuit of RFMU. Track bodies are made of aluminium and the track belts are made of steel plate. The track belts include cleats with bearings. The track bodies include channels where the cleats interface to track bodies. The tracks interface to the other parts of the RFMU through the two levers.

 


Tether

All the communication and power of rover are going trough tether. Tether is totally 41 meters long and it can be unwinded and rewinded. Tether subsystem includes the tether reel, the tether unwinding roller and the cleaning device. The cleaning device is passive. The reel and the roller are actuated with separate motors. See image on right.

 






On-Rover Electronics, ORE

Equipment Compartments

The RFMU includes two equipment compartments. Equipment compartment 1 is attached to the bridge and is mostly occupied with the equipment required for articulating the payload cab. Also Tether s/s is accommodated here. The equipment compartment 2 is attached to the payload cab. All the electronics needed to control the RFMU and the DSS are located here. This electronics includes the PC/104 with related I/O and PWM cards, the motor controllers, plus controllers for the rest of the electrical equipment.

Bridge

On the rear side of RFMU there is a bridge that connects the levers on both sides of RFMU. The bridge is an essential part in ensuring that RFMU structure is sufficiently rigid. There is some spare space in the bridge that can be used in accommodating some equipment. Since the inclinometer measures the attitude of the rover, not the payload cab, it is accommodated in the bridge.

 


Rover computer system and software

The PC104 board has an Intel 486DX4 / 100 MHz computer which runs Linux Real-Time operation system. There's a Solid State type 32 MB Disc-On-Chip hard disk and a smaller Flash RAM disk memory. The RT Linux kernel, device drivers and compiled Ada software occupies some 17 MB of the hard disk.

During debugging and development phase of the project, the PC104 stack had fourth board installed on it, which was the IDE Hard Disk, floppy disk and VGA module (on top of the stack in the image on right). The Disc-On-Chip hard disk is not suitable for software development, since it has limited write times and capacity (for the source codes and compilers).

 





Drilling Sub System, DSS

This is the subsystem that performs the actual sampling. Acquired samples are also stored here prior to their delivery to the Lander. The Drilling and Sampling Subsystem (DSS) is restricted in volume to 110 x 110 x 350 mm and in mass to 5 kg.

EXTANDABLE DRILL STRING

In order to satisfy 2 meter penetration depth requirement and still be able to meet volume and size restrictions, the DSS features an extendable drill string. The string is assembled from up to 11 separate pipes. Pipes are 20 cm long and 15mm thick.

 

The DSS module

[Above: The DSS module]

 

The DSS module

[Above: Spindle]

DRILLING ACTUATORS

Drilling is performed by two independent actuators, one for rotation up to 30 rpm and one for thrust up to 30 N. The rotation actuator is mounted on a sledge moved in and out by a spindle, which is propelled by the thrust actuator. Both actuators have encoders and the sledge position can be read from potentiometer.

The linear feed motor and the spindle motor are equipped with encoders in order to get feedback about the motor operations. The linear feed motor is also associated with two micro switches that limit the operational amplitude of the spindle. The micro switch associated to the spindle motor is used to indicate the zero rotating angle of the drill string.

SOLENOID HOOKS

The pipe gripper is the means by which the last pipe of the string is attached to the rotation actuator. The gripper holds the pipe when drilling is performed.

CLAMPER

String holder keeps the drill string attached to the DSS when the gripper is handling a new pipe to add to the string.

CAROUSELS

Individual pipes and drill bits are stored in two carousels, called pipe and tool carousel. There is space for eleven pipes in pipe carousel. In tool carousel there is space for 10 tool bits. The positioning of carousels is done with micro switches.

Both of the carousels are equipped with two micro switches that are used when orientating the carousel. The pipe carousel is further equipped with the third micro switch to indicate either the current position of the carousel has a pipe or not. Both sides of the clamping device are equipped with potentiometers to indicate the current position of both of the jaws.

TOOLS AND SAMPLE CONTAINER

The tool also will serve as a sample container. In this configuration, the DSS will carry individual tools for each sample to be acquired during a single trip between the lander and the sampling location. Fresh tool will be attached to the drill string before each sample acquisition, and then subsequently detached with the sample inside.

DRILLING SEQUENCE

1-2: The drilling sequence starts with attaching the first pipe. This is done by driving the linear feed motor down so that the string holder can be closed.
Next the string holder is closed so the linear feed can press the pipe gripper into pipe and close the solenoid so that the pipe stays in gripper.

3: Now the sledge drives up so it can get the tool from tool carousel. Then it finds the correct tool and retrieves the tool bit from the tool carousel.

4: Now the tool carousel is driven into its initial position. Drilling starts now.

5-6: When the sledge has reached its down limit position, the string holder is closed and the pipe gripper solenoid is opened.
Then the sledge moves up. Next we rotate the pipe carousel so that we get a new pipe.
Next the sledge push this new pipe down so that the two pipes and the pipe gripper connect. The pipe gripper locks the pipe and the system can continue drilling deeper.

 

The DSS module

[Drilling sequence]

After reaching the wanted drilling depth, the rotation direction turns to counter clockwise and the drill starts to drill backwards.

Detaching two pipes is done so that another is jammed to string holder and another is pulled up with a force of 100 N. Then the feed drives up and the pipe gripper releases, and the sledge goes to its upper limit. Now the forks detach the pipe into its position and the system can rotate the pipe carousel into next empty position.
Next the pipe, which is jammed in string holder, is retrieved. Again the pipe gripper closes, and string holder opens, and the sledge drives up.
Initially the sample is brought into its place in the tool carousel.




The docking and sample delivery port, DSDP

The Docking and sample delivery port contains two functional units, alignment guide, and sample delivery port.

Alignment guides

The DSDP has two mechanical solutions to provide the RFMU with an alignment guide for successful docking:

  • The ramp has ladder-like steps.
  • The DSDP has a Y-shaped barrier.

The sample delivery port, SDP

To perform sample delivery the DSDP has a sample delivery port. The sample delivery port has conical part to help the drill positioning. This part can also move a little so the drill always goes to centre of port.

 



Software and the graphical user interface, GUI

This chapter describes the top-level design of the MiRo2 software. The Rover SW, the Control Unit SW and the test software are described in separate chapters.

Requirements

The original software requirements were:

  • Rover subsystems and payload controlled and monitored using TC and TM packets
  • automatic drilling, mobility, sample delivery
  • manual control for all rover operations provided
  • housekeeping, monitoring and reporting TM
  • external debugging interface
  • control and monitoring through GUI

The system uses Embedded Linux operating system with a real-time kernel. A real-time kernel makes it possible to satisfy strict real-time requirements.

The MIRO2 software divides into two parts. The rover on-board software controls the rover functions and performs the external communications. The Control Unit substitutes the lander and it has some similar functions such as the control of the TC/ TM.


Design Methodology

HOOD software design method is used. The rover software will be implemented with Ada-95. GNAT compiler is used. The Control Unit was implemented using Ada and the user interface was implemented with Java. The Linux kernel modules containing the device drivers use ANSI-C. The Simulation software was implemented with Ada. CVS version control is used in both platforms.

 

Miro SW blocks

[Above: Miro SW overview]


The system

Figure on right illustrates the main building blocks of the system. Control Unit GUI (Graphical User Interface) receives an user input and it is sent to Control Unit through an UDP socket. Control Unit creates a TC and sends it to Rover through tether using UDP. Rover TC/ TM Communications receives it and if the data packet header is valid, the command is forwarded into TC buffer. TC handler reads the TC buffer and parses the TC. The TC starts related Control Tasks and they command Device Interface. Device Interface consists of Unix device drivers, their nodes and implements read/write operations. TC handler and Control Tasks report the execution process sending TM reports to TC/TM Communications through TM buffer. TC/TM Communications creates appropriate data packet that is sent to the Control Unit. TM Handler is running independently from the TC Handler. It periodically reads sensor data from Device Interface and sends it using TC/TM Communications.

 

System main blocks

[Above: System main blocks]


Rover Software

The Rover software receives telecommands through the tether interface. The Rover SW executes the commands and monitors their execution. SW controls rover devices and monitors rover sensors. The Rover reports sensor information and software state via tether telemetry. The SW provides the telecommands to control rover functions and to run activities. In addition, low-level control of rover devices is provided, i.e., it is possible to drive each motor independently. The rover operations consist of several functions. Functions can be active or in-active. They behave like rover working modes.

 

Rover SW

[Above: Rover SW overview]


Graphical User Interface

The Graphical User Interface (GUI) is a separate Java application without any control logic. It receives the TM packets from the rover, transmits the user commans to the rover and displays sensor data to the user. The GUI runs on Windows NT 4.0 platform.

     

Rover SW

[Above: Miro GUI]

     

Rover SW
[Above: Miro GUI]


Back to the first page   Back to the first page.     |     Next page: Reference information and image gallery. Reference information and image gallery


All rights for texts and materials on these pages are reserved. Do not use or copy without prior written permission of the author.
Last update: December 10th, 2003. (Matti Anttila, MRoSA2U Project Manager, matti.anttila(at symbol)ssf.fi)