MARS COLONIZATION SENSOR SYSTEM FOR SOIL ANALYSIS

MARS­COLONIZATION SENSOR SYSTEM FOR SOIL 

ANALYSIS 

   

John Maruska, Judah Schad (Students) and Kurt Kosbar (Adviser) 

Telemetry Learning Center  Department of Electrical and Computer Engineering  Missouri University of Science and Technology          ABSTRACT    This paper discusses a modular open source electronic soil analysis system embedded in a  remote vehicle designed for use on a colonization­effort Mars rover. The embedded system  consists of a soil extraction drill sheath, a temperature and moisture array sensor sheath, a sample  return bay specialized for Raman­Fluorescence spectrometry, and an Ethernet bridge radio for  communication, all controlled through several microcontroller boards. A Windows­based  graphical engagement application provides real time control. A Linux­based scripting application  provides post­processing, graphing, and statistical analysis. All software and electrical hardware  has been made open­source for the public to build upon.      INTRODUCTION    The Mars Rover Design Team (MRDT) Colonization Soil Analysis System, referred to as  “RoveWare,” is intended to conduct planetary field science on a remote vehicle alongside  colonization­effort astronauts. This paper focuses on the chosen design and implementation  methodology of the MRDT Telecon science system modules. RoveWare is designed with the  primary goal of completion of the Mars Society’s University Rover Challenge (URC) “Science  Cache Task” as detailed in section 5b of the URC Requirements and Guidelines [1]. The  requirements within the scope of this system are as follows:    1. Collect and return a subsurface sample, to be stored and sealed in a cache container  onboard the rover for later removal and analysis.  2. Onboard equipment should test soil moisture at least 10cm below the surface  3. An additional science capability of the team’s choice    The 2016 MRDT rover, Zenith, more than sufficiently meets these requirements. Collection and  storage of a subsurface sample is achieved through the use of a set of soil extraction hardware: a  drill, sheath, and carousel, specifically designed to store up to six separate samples for this task  (Figure 1). A separate sheath that contains a pair of soil moisture sensors, a pair of temperature  sensors, as well as a borescope, completes the criteria for both rules 2 and 3. In addition, the 

system includes a portable Raman­Fluorescence spectrometer, directly attached to the rover and  accessible from the sample bay carousel, for additional data that may more accurately indicate a  likelihood to support microbial life [2].       Figure 1: Zenith collecting soil samples    A robust communications system connects three individual commercial microcontroller boards  dedicated to a task or set of tasks. One board controls the drill and connected sheath components,  another board is dedicated wholly to spectrometer readings, and the final board encompasses the  remaining science equipment housed with the sample bay carousel. A remote base station runs a  graphical control interface and scripting application in order to control the rover and analyze the  sensor readings respectively. All software, schematics, custom printed circuit boards layouts  (PCBs), and gerber files used for the utilized booster packs have been made fully open­source  and available for the public to utilize and build upon in the spirit of MRDT’s core philosophy,  “Today, Tomorrow, Forever.”      SYSTEM HARDWARE    The sensor system implemented on Zenith is comprised of three distinct sets of equipment: the  communications hardware, the soil extraction equipment, and the controlling electronic devices.  The communications function primarily through a radio­link back to the base station, and operate  over a set of several uniquely architected boards using a custom networking framework. Soil  extraction is achieved through the use of two separate “sheaths” that contain either the drill and  supplementary sensors, or a devoted array of sensors. The electronic devices for the rover are  designed with modularity in mind, leading the team to utilize a “booster pack” design philosophy 

already widely implemented by many manufacturers of microcontroller development boards.  Booster packs are custom PCBs built with bottom loaded header pins and without any  microcontrollers themselves. Booster packs are designed for specific purposes such as planetary  science telemetry systems. The booster pack form factor is chosen to fit a specific model of any  commercially­available microcontroller development boards without any additional soldering.  There exists a number of both commercially available and custom designed booster packs from  third parties under the Creative Commons Attribution license that are also often compatible with  RoveWare designs, and may be used to quickly attach commercial assets to development boards  concurrently running RoveWare code. This booster pack compatibility layer approach was  chosen in order to integrate with the open source community and facilitate speed and ease in  research, development, learning, and education.     The Zenith science sensor system utilizes four separate RoveWare packages, each with open  source schematic, board, and software repositories, all shared with the world freely on GitHub  under the MRDT organizational umbrella [3]. The custom package referred to as “DrillBoard”  both controls the drill motor and aggregates telemetry from the sensor arrays in the two separate  sheaths. The custom package referred to as “SpectrometerCCDBoard” is dedicated solely to  running the CCD linear image sensor used in the spectrometer. The custom package referred to  as “MediaBoard” is dedicated to running commercially available streaming video and image  capture devices. Finally, the custom package referred to as “ScienceBoard” receives all science  commands from the remote base station, controls several local sample bay motorized devices,  and parses and communicates aggregate commands across the other boards (Figure 2). Each of  these packages has its own attached booster pack complete with all required circuitry and  standard connection headers in a top loaded PCB which attaches to a microcontroller board with  the required logic implemented.    Figure 2: Hardware Interface Structure     

SOIL EXTRACTION EQUIPMENT    The rover is equipped with a soil extraction sheath referred to as “DrillSheath” (Figure 3). This  sheath comes equipped with three sensors: two 1­Wire digital temperature sensors, and a custom  soil moisture sensor created to fit in the tight confines of the sheath. The 1­Wire protocol is a  device communications bus system designed to provide low­speed data, signaling, and power  over a single wire. This allows real­time data collection during the drilling process immediately  upon displacement of the soil. This sheath holds the displaced soil to be later released into a  sample return bay, mounted to a carousel that will allow up to six separate samples to be  collected and stored.       Figure 3: DrillSheath    A continuous wave laser and a linear image sensor attach to the sample return bay. These devices  allow performance of Raman­Fluorescence spectroscopy on a given sample using the equipped  portable spectrometer. The rover is additionally equipped with a separate extruding sheath  referred to as “SensorSheath” (Figure 4) containing an array of 1­Wire digital temperature  sensors, voltage differential soil moisture sensors, and a waterproof CMOS camera endoscope.  The 8.5MM diameter CMOS camera endoscope, referred to as “Borescope,” is capable of  snapshot image or video capture up to 1280x720 resolution at 2.2 million pixels. Power and  communication to the Borescope is delivered by the USB 2.0 port of the MediaBoard, and  operated by a modified embedded Linux OS derivative. The flexible inspection camera features  an array of 6 LED low LUX illuminance lights in order to operate 8cm deep in the subsurface  soil. SensorSheath gives a more accurate telemetry stream than DrillSheath, particularly for the  characteristics of the subsurface soil that has not been displaced, and fulfills the requirements for  the second rule detailed previously. This equipment suite allows the MRDT to achieve far more  than the data and analysis required by the URC and more accurately determine the presence of  signs of life from a soil sample.   

  Figure 4: SensorSheath (Borescope not visible)    COMMUNICATIONS HARDWARE    Zenith currently maintains a single radio link from base station to remote rover through a pair of  rugged, 900 MHz, 800 mW, wireless Multiple­Input­Multiple­Output (MIMO) radios  specifically designed for outdoor point­to­point (PtP) and point­to­multipoint (PtMP) bridging.  These 10/100 transparent ethernet bridges support a 10 MHz Bandwidth,  Time­Division­Multiple­Access (TDMA), and feature a speed of 150+ Mbps with a range  performance of 50+ km. Both radios receive a 12V supply through Power­over­Ethernet (PoE).  Two Yagi antennas of 15 dBi (Figure 5), one horizontally polarized and one vertically polarized  respectively, are mounted at the base station radio feeding an 8 channel Ethernet switch allowing  for up to 16 independently networked Apps. Two skew­planar cloverleaf antennas (Figure 6) of  5 dBi mount to the remote rover MIMO radio access point, one 3­lobe right hand circular  polarized (RHCP) and one 5­lobe left hand circular polarized respectively. This radio feeds a  consumer 16 channel Ethernet switch, allowing for up to 16 independently networked Devices.       Figure 5: Vertical and Horizontal Dual Yagi Antenna.       Figure 6: 5­lobe and 3­lobe Skew Planar Cloverleaf Antennas.  

COMMUNICATIONS MODEL    The communications layer is the centerpiece of the RoveWare initiative and powers the  telemetry and control across the science modules of Zenith by providing a lightweight distributed  networking protocol for the communication of Embedded Device Systems (Devices) and User  Interface Applications (Apps). Both PC­based Apps and remote devices communicate  interchangeably in a subscriber based IP model that allow any number of Apps to pass both  telemetry and control messages to any number of Devices across a local area network.     Figure 7: Full System Communication Diagram    DRILL BOARD     The DrillBoard booster pack controls the drill and the multitude of sensors run by the rover. A  total of seven sensors connect to DrillBoard: four 1­Wire digital temperature sensors and three  moisture sensors. The custom SensorSheath contains two large­package commercial temperature  sensors and two large­package commercial moisture sensors. Two IC temperature sensors are  embedded within the DrillSheath. Due to the size constraints that commercially available sensors  cannot meet, the third moisture sensor is a custom design consisting of two exposed wires and  basic circuitry also contained in DrillSheath. DrillBoard takes a reading from each sensor and  this data is sent back to ScienceBoard serially at a baud rate of 9600. The readings are sent  through a 2.4GHz wireless serial bridge, equipped to the booster pack for each board (Figure 8).   

  Figure 8: DrillBoard with booster packs (2.4 GHz transceiver not equipped).    SPECTROMETER­CCD BOARD    A second sensor board, referred to as “SpectrometerCCDBoard,” consists of a custom­designed  booster pack containing a BJT current mirror and hex inverter circuit driving the CCD image  sensor itself. The booster pack sits upon a commercially­available 80 MHz, 32­bit  microcontroller development board dedicated entirely to capturing the CCD linear image sensor  data from the custom­made Raman­Fluorescence spectrometer [2]. This board constantly reads  the sensor, generating an output array of 3948 four­byte unsigned integer pixel elements that  represent a single image read. This set of data is sent back to ScienceBoard serially at a baud rate  of 115200. ScienceBoard then transmits the data to the base station (see Communications  section), where it will be used to generate a corresponding waveform. Using this waveform, the  science team can analyze the soil and determine the presence of biomaterial in a soil sample or  potential radiation damage [4].    SCIENCE BOARD    ScienceBoard performs as a staging point for the SpectrometerCCDBoard and DrillBoard  telemetry and control messages so that remote communication need only be sent through a single  board. ScienceBoard also handles the collection of soil samples by controlling and/or interfacing  with the following devices:    ● Laser, for use with the custom Raman spectrometer  ● Servo, to control the sample bay carousel  ● Servo, to control the funnel lid that accesses the soil samples  ● 2.4 GHz wireless transceiver, to communicate with DrillBoard    This board enables the team operating the rover to control the actuation of the physical  components of the Raman spectrometer, to gather and store several soil samples safely and  securely, and to operate the drill. This is accomplished all through communicating to a single  physical device on the rover itself. 

SYSTEM SOFTWARE    The communications layer software component, referred to as “RoveComm,” is a minimal,  best­effort, message­passing transport to applications and upper­layer protocols based on User  Datagram Protocol (UDP), and is uniquely suited for the remote IP robot use case. RoveComm  does not establish end­to­end connections between communicating end systems and  consequently does not incur connection establishment and teardown overheads, or failures from  associated end system state. As opposed to the standard Hypertext Transfer Protocol (HTTP)  over Transmission Control Protocol (TCP), the simple RoveComm over UDP provides no  guarantees for delivery and no protection from duplication, while still retaining a logic layer of  message parsing, device identification, and telemetry subscription. RoveComm remains  compatible with all the extensible desirable aspects of the common IP addressable networks  found in the web products and systems in the market today. RoveComm is a generalized  distributed component and acts as extensible device agnostic library protocol that must rely upon  and utilize common interface definitions for access to any specific commercial microcontroller  or operating system. For each target commercial microcontroller chosen, RoveWare developers  first implement and validate a Hardware Access Layer (HAL) to be ported for that specific target  into driver files “RoveBoard” and “RoveEthernet” included with each booster pack design.     Each embedded microcontroller booster pack board runs a real­time single­threaded program  that contains the specific business logic for a given device, referred to as a device “Loop”, and  written at a very high level object oriented abstraction in a single file by MRDT’s “Loop  Developers.” A Loop developer is able to complete various complicated functional requirements  with simple and declarative idioms across various target hardware by utilizing the generalized  components written by MRDT’s RoveWare developers such as RoveComm. ScienceBoard  utilizes the RoveComm component for the network communication Loop. The ScienceBoard  Loop developer does not need to know the internals of the RoveComm component or the  hardware access layer specific to the ScienceBoard’s underlying target microcontroller. Similar  components exist for the functional requirements inherent in DrillBoard,  SpectrometerCCDBoard, and MediaBoard. By utilizing device agnostic components such as  RoveComm, powered by hardware access layers such as RoveBoard and RoveEthernet, the  MRDT device Loops are syntactically identical in nature and cross­compatible across  development shields. RoveWare developers derive much of the RoveWare code base from other  relevant and compatible open source software assets found in the open source communities. It  should be noted that all software assets of RoveWare components that make it to production  begin with validation or re­implementation. Despite being modeled on the modularity and  accessibility of the Open Source Hardware hobby paradigm, RoveWare is intended to be an  engineering­grade platform with the robust scientific methods specific to planetary science  research and application.     BASE STATION    The Windows PC referred to as “BaseStation” runs a graphical control software called the Rover  Engagement Display (RED) [5], written in C#. RED allows the operating team to make use of  the various functionalities of the system, including operating the drill and laser, moving the 

carousel, and enabling or disabling readings of the sensors. RED takes rover sensor output  telemetry and compiles it into two separate CSV files, one for temperature and moisture sensors,  and one for the spectrometer output, to be used with “ScienceStation” Python scripts at a later  time. In the case of the temperature and moisture sensors, the CSV holds three columns of data:  the first column indicates the date­time of the reading in the ISO 8601 international standard  format and following the RFC­3339 protocol [6], the second column indicates the output of the  sensor as a floating point number, and the third column indicates which sensor the reading  corresponds to in the form of a string.    SCIENCE STATION    The Linux PC, referred to as “ScienceStation,” runs a suite of scripts collectively called  “RoveSci,” written in Python utilizing various numeric, scientific, and plotting libraries. After all  the data is collected and stored in the CSV file created by the base station, RoveSci scripts will  generate graphs based on the data inside that file. The script is written using Python 3.4.4, as  well as the supplementary library Matplotlib, specifically its module PyPlot. A different script  will be used for the two different use­cases; one script handles the file containing the readings for  temperature and humidity (Figure 4), and another script handles the file containing the readings  for the spectrometer linear image sensor (Figure 3). In both cases the PyPlot module of the  Matplotlib library generates the figures and plots. In the case of the temperature and humidity  sensors, two figures are generated, one for humidity and one for temperature, each containing  four plots, one for each sensor that gathers that type of reading. The readings contained in the  CSV are plotted against their corresponding date­time, and plotted onto these figures  accordingly.  Due to the contrasting nature of the spectrometer readings and development­time  constraints, a separate script was used. This file generates a single plot and a single file that  displays one spectrometer reading, waiting for user input to step through all readings.       CONCLUSION    The RoveWare Soil Analysis System is designed to provide a competitive modular and  open­sourced system to perform a gauntlet of scientific analyses on collected soil samples with  the remote vehicle. Despite being modeled on the modularity and accessibility of the open source  hardware hobby community paradigm, RoveWare is intended to be an engineering­grade  platform with robust scientific methods specific to planetary science research and application.  RoveWare proved itself by enabling the operating team at URC 2016 to achieve a perfect score  in its targeted “Science Cache Task.” Samples of soil were successfully collected, stored, and  returned to ScienceStation for further analysis, with enough data collected and analyzed to  complete the task well above expectations for the task.     RoveWare as a whole performed better than originally hoped at the design stage, with the only  issue occurring within the sensor system as a result of integration at the 2.4 bridge on DrillBoard.  The 1­Wire sensors used take a significant time to read, and as a result the drill control software  starves the 1­Wire sensors in the event drill and sensor reads occur simultaneously. This issue 

aside, the system still accomplished its task and achieved a perfect score, proving its worth and  ensuring that development on this system continue in the future.     Today, MRDT is already hard at work making plans to improve on the atomic booster­pack  design, expand the successful Python scripts, and continue developing RoveWare year over year.  With its modular and open­source design, RoveWare is intended to be an extensible and  sustainable development framework given freely to the world and for the specific use case of the  next generation colonization soil analysis robot that will one day work alongside human  explorers in the field for years to come, in accordance with the mission statement “Today,  Tomorrow, Forever.”      ACKNOWLEDGEMENT    Recognition should be given to the MRDT Science Devices squad: Matthew Healy, Shannon  Klaus, and Rebecca Marcolina, as well as the many other members of the Mars Rover Design  Team that assisted throughout the course of development.       REFERENCES    [1] The Mars Society, “Requirements & Guidelines,” [Online].  http://urc.marssociety.org/home/requirements­guidelines.  [2] Marshall, Frank E.; Brinker, Katelyn R.; Chiaventone, Owen; Pride, Michael A.; Walker,  Zachary; and Rojo, Michelle; “A Simple and Cost Effective Raman­Fluorescence  Spectrometer,” International Telemetry Conference, Oct, 2015  [3] Missouri S&T Mars Rover Design Team Official GitHub [Online].  https://github.com/MST­MRDT/.  [4] Groote, J.et. al, “Radiation damage in NaCl. IV. Raman scattering”, _​Physical Review, B:  Condensed Matter_​, Volume 50:14, Oct, 1994  [5] Reed, Joshua, and Kosbar, Kurt, “An Object­Oriented Interface For Telemetry and  Control of a Mars Rover”, International Telemetry Conference, Oct 2015  [6] IETF, “RFC 3339”, [Online]. https://tools.ietf.org/html/rfc3339.