Arduino-Raspberry Pi: Hobbyist Hardware and Radiation Total Dose Degradation
This presentation covers top-level total ionizing dose (TID) testing and evaluation of commercial CubeSat hardware modules from Arduino and RaspberryPi.
SEARCH · Engineering Papers
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
This presentation covers top-level total ionizing dose (TID) testing and evaluation of commercial CubeSat hardware modules from Arduino and RaspberryPi.
All devices attached to the NASA KSC network are subject to security vulnerability scanning and/or penetration testing. In today's changing environment, vulnerable and/or unprotected systems can easily be overlooked. Systems that are not properly managed can become a potential threat to the operational integrity of our systems and networks. This includes all NASA (internal and external) information systems within NASA KSC Internet Protocol (IP) address space, and NASA KSC facilities. The Office of the Chief Information Officer (OCIO) recommends that all NASA Centers and information systems be subject to penetration testing on a regular interval in accordance with the guidelines identified by the National Institute of Standards and Technology (NIST). (ITS-HBK-2810.04-02A) Protecting information and equipment at NASA is an area of increasing concern. In addition to the CPU's on the network; Supervisory, Control and Data Acquisition (SCADA) systems are especially vulnerable because these systems have lacked standards, use embedded controllers with little computational power and informal software, are connected to physical processes, have few operators, and are increasingly also being connected to corporate networks. The scope of work is comprised of several individual components which together build upon previous work by Drew Branch, NASA KSC Intern. The Pwn Plug is the selected COTS (Commercial-Off-The-Shelf) device chosen to test simplification of mandatory IT Security tasks. The device will be utilized to provide services to NASA KSC and enable an assessment of infrastructure soundness and regulatory compliance in an efficient, economical, and business responsive manner. The Pwn Plug is designed as a pen testing appliance which provides a hardware platform that can support commercial penetration testing efforts at significantly reduced costs. The expected outcomes are: 1) External Penetration Testing, 2) Social Engineering, 3) Procedural Documentation, 4) Recommended Remediation Action Plan, 5) System Retest & Remediation Attestation and 6) Final Reports, out briefing and Presentation. Due to physical and material constraints beyond intern and mentor control, the project was redefined as a working pen-test scenario. Limitations of lab availability and tools dictated an academic exercise. This report was developed within the scenario guidelines suggested by the project mentor. The guidelines were to be creative in developing a Pen Test program for a client.
The High-Rate Delay Tolerant Networking (HDTN) project at NASA has developed a performance optimized and open-source Delay Tolerant Networking (DTN) implementation. The primary goal is to create a scalable networking solution to increase the scientific data return rate of space missions. To reach this goal, HDTN must span multiple edge cases in space networking by including tools and configurations to accommodate a wide range of space systems. Typically, HDTN evaluations are conducted on a laboratory emulation test bed, made up of hardware accelerated x86 based systems capable of data rates over 10 Gbps. HDTN must have an effective implementation process on a wide range of systems to increase the sustainability of the design. One important implementation option is with low-level embedded systems which could be used on small robotic missions. This paper details the implementation process, benchmark testing, and performance results of HDTN in multiple configurations on Raspberry Pi 4 devices. By implementing HDTN on a Raspberry Pi 4, a process for building HDTN onto ARM processors was developed and utilized to conduct benchmark tests in multiple network configurations, achieving a data rate performance exceeding 600 Mbps. Based on these results, HDTN proved to run on small ARM based systems with slight modifications to the build procedure. These results were then extended to evaluating an implementation of the HDTN software parsed across several Raspberry Pi 4 nodes. To test this capability, HDTN was configured in a simplified cut-through setup and distributed among multiple Raspberry Pi 4 processors. This distributed architecture was benchmark tested in a similar fashion to the testing of a singular HDTN implementation. The results from the benchmark testing are used to examine how these implementation options and capabilities can expand the use cases for DTN, and particularly with small robotic missions.
Current technology and budget trends indicate a shift in satellite architectures from large, expensive single satellite missions, to small, low cost distributed spacecraft missions. At the center of this shift is the SmallSatCubesat architecture. The primary goal of the Pi-Sat project is to create a low cost, and easy to use Distributed Spacecraft Mission (DSM) test bed to facilitate the research and development of next-generation DSM technologies and concepts. This test bed also serves as a realistic software development platform for Small Satellite and Cubesat architectures. The Pi-Sat is based on the popular $35 Raspberry Pi single board computer featuring a 700Mhz ARM processor, 512MB of RAM, a flash memory card, and a wealth of IO options. The Raspberry Pi runs the Linux operating system and can easily run Code 582s Core Flight System flight software architecture. The low cost and high availability of the Raspberry Pi make it an ideal platform for a Distributed Spacecraft Mission and Cubesat software development. The Pi-Sat models currently include a Pi-Sat 1U Cube, a Pi-Sat Wireless Node, and a Pi-Sat Cubesat processor card.The Pi-Sat project takes advantage of many popular trends in the Maker community including low cost electronics, 3d printing, and rapid prototyping in order to provide a realistic platform for flight software testing, training, and technology development. The Pi-Sat has also provided fantastic hands on training opportunities for NASA summer interns and Pathways students.
In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospaceâ€"TM"s command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for userâ€"TM"s to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS 'App Store'. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.
In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for users to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS "App Store".. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.
Experimental evolution (EE) involves iteratively exposing a microbial community to specific stressors to study its response to changes in environment over time. EE work is commonly done manually in the laboratory, but, when there are many environmental variables to measure and adjust, it is highly labor intensive, prone to human error, and challenging to scale. Single-purpose automated continuous culturing chambers exist, but implement only limited stressor types. A more general-purpose design is desirable. The BeING Lab at Ames Research Center created the prototype Automated Adaptive Directed Evolution Chamber (AADEC) to address these problems, beginning with Escherichia coli tolerance of short-wave ultraviolet (UV-C) radiation and of temperature. In newer versions, AADEC monitors microbial activity and can adjust the UV-C and temperature levels automatically. An optical density measurement is used to determine how many cells are present in the growth medium—over time, this corresponds to how many survive and reproduce. Oxidation-reduction potential provides information on consumed metabolic energy, and pH and electrical conductivity on metabolic products. Dissolved oxygen content is used to determine aerobic vs anaerobic growth. A Raspberry Pi computer processes all this data to set the UV-C stressor level. AADEC’s auxiliary systems include peristaltic pumps to change media and agitation to counteract cell settling. These actuators can also act as additional stressors. With the Raspberry Pi monitoring sensors and adjusting actuators in real time, AADEC takes measurements and controls the environment much more accurately than can be done with a manual EE implementation. The third and latest AADEC iteration is the first to simplify design and usage with circuits on PCBs and the ability to pre-program experimental protocols. Still planned is expansion to a multi-well design for the study of varying cell cultures in parallel, which will enable researchers to retain and re-inoculate cultures exhibiting the desired trait most strongly while flushing out others. AADEC’s special capabilities make it a valuable tool for studying life under multiple stressors, enabling scientists to replicate changes in climate on microbes for study in a lab setting.
The software required to develop, integrate, and operate a spacecraft is substantial regardless of whether its a large or small satellite. Even getting started can be a monumental task. To solve this problem, NASAs Core Flight System (cFS), NASA's 42 spacecraft dynamics simulator, and Ball Aerospaces COSMOS ground system have been integrated together into a kit called OpenSatKit that provides a complete and open source software solution for starting a new satellite mission. Users can have a working system with flight software, dynamics simulation, and a ground command and control system up and running within hours.Every satellite mission requires three primary categories of software to function. The first is Flight Software (FSW) which provides the onboard control of the satellites and its payload(s). NASA's cFS provides a great platform for developing this software. Second, while developing a satellite on earth, it is necessary to simulate the satellites orbit, attitude, and actuators, to ensure that the systems that control these aspects will work correctly in the real environment. NASAs 42 simulator provides these functionalities. Finally, the ground has to be able to communicate with the satellite, monitor its performance and health, and display its data. Additionally, test scripts have to be written to verify the system on the ground. Ball Aerospace's COSMOS command and control system provides this functionality. Once the OpenSatKit is up and running, the next step is to customize the platform and get it running on the end target. Starting from a fully working system makes porting the cFS from Linux to a users platform much easier. An example Raspberry Pi target is included in the kit so users can gain experience working with a low cost hardware target. All users can benefit from OpenSatKit but the greatest impact and benefits will be to SmallSat missions with constrained budgets and small software teams. This paper describes OpenSatKits system design, the steps necessary to run the system to target the Raspberry Pi, and future plans. OpenSatKit is a free fully functional spacecraft software system that we hope will greatly benefit the SmallSat community.
Originally, I was brought into the Design and Analysis Branch in the Crew and Thermal Systems to work on administrative tasks like archiving and scheduling. However, I ended up splitting my time between secretarial tasks and a technical project. My technical project was originally meant to be a wireless sensor package for the 20ft Spacecraft Thermal Vacuum Chamber in the B7 High Bay. I would be using a miniature wifi development board and a temperature/humidity sensor along with custom 3D modeling to accomplish this. However, after some discussion with my technical mentor, the plan was changed to a mobile autonomous self-charging sensor platform. A mobile platform will allow the sensors to be moved around without depressurizing the chamber. Also, the self-charging aspect of the package allows for almost unlimited time in the chamber. If the on-board battery runs low, the robot can easily be driven to its charging dock and continue to transmit while charging. The driving base is based around a Raspberry Pi 3 board with a 12C PMW DC Motor controller and a PWM controller driving two small gear motors. The sensor transmitter itself is a RHT03 temperature and humidity sensor and Cozir CO2 sensor connected to an ESP8266 Huzzah board. The power distribution system utilizes a pair of 3.7v 3600mah lipo batteries wired to Powerboost 500 boards. Also, the self-charging mechanism utilizes two 12v-max inductive charging coils wired into the same Powerboost boards as the battery. The Raspberry pi is running Python 3.3 for the driving base and Javascript MJPEG library for transmitting live video from the onboard camera. The sensor package is running Arduino-based C++ and the program capturing the data is running PyqtGraph Python and HTML. The shell of the robot itself is a 3D printed case that will (work in progress) snap together. The photo to the left shows the two halves separated from each other. The black shell contains the power distribution boards and connectors while the white shell contains the driving base and data systems.
Microgravity exposure results in an adaptive central reinterpretation of information from multiple sensory sources to produce a sensorimotor state appropriate for motor actions in this unique environment, but this new adaptive state is no longer appropriate for the 1-g gravitational environment on Earth. During these gravitational transitions, astronauts experience deficits in both perceptual and motor functions including impaired postural control, disruption in spatial orientation, impaired control of locomotion that include alterations in muscle activation variability, modified lower limb kinematics, alterations in head-trunk coordination as well as reduced dynamic visual acuity. Post-flight changes in postural and locomotor control might have adverse consequences if a rapid egress was required following a long-duration mission, where support personnel may not be available to aid crewmembers. The act of emergency egress includes, but is not limited to standing, walking, climbing a ladder, jumping down, monitoring displays, actuating discrete controls, operating auxiliary equipment, and communicating with Mission Control and recovery teams while maintaining spatial orientation, mobility and postural stability in order to escape safely. The average time to recover impaired postural control and functional mobility to preflight levels of performance has been shown to be approximately two weeks after long-duration spaceflight. The postflight alterations are due in part to central reinterpretation of vestibular information caused by exposure to microgravity. In this study we will use a commonly used technique of transcutaneous electrical stimulation applied across the vestibular end organs (galvanic vestibular stimulation, GVS) to disrupt vestibular function as a simulation of post-flight disturbances. The goal of this project is an engineering human-in-the-loop evaluation of a device that can degrade performance of functional tasks (e.g. to maintain upright balance) similar to what astronauts experience during transitions to new gravitational environments. Stochastic electrical stimulation can be applied to the vestibular system through electrodes placed over the mastoid process behind the ears in the binaural configuration resulting in stimulation in the mediolateral (side-to-side) plane. An additional electrode can be placed over the bony landmark of the tip of the c7 spinous process for the double monaural configuration, which will cause stimulation in the anteroposterior (forward-backward) plane. A portable constant current bipolar stimulator with subject isolation was designed and built to deliver the stimulus. The unit is powered using a 3.7 V battery pack and designed to produce currents up to 5 mA. The stimulator, controlled by a Raspberry Pi 3 computer, offers several stimulus signal generation options including a standalone mode, which uses onboard signal files stored on the flash memory card. Stochastic stimulation signals will be generated in 0-30 Hz frequency bandwidth. Stimulation amplitude can be increased incrementally to a maximum amplitude of 5.0 mA (e.g., 0, 0.5, 1.0, 1.5, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5, 5.0 mA). In control trials, subjects will be experiencing vestibular stimulation with 0-mA current applied through the electrodes. The system will be evaluated at various levels of stimulation and in both the binaural and double monaural electrode configurations. One of the objectives is to identify stimulation levels producing effects most comparable to the post-flight disturbances. This is a pilot study that will set the stage for a larger, more comprehensive study that will investigate wider aspects of post-flight sensorimotor dysfunction and set sensorimotor standards for crew health.
Reliability is the critical challenge of wireless sensing in space systems operating in extreme environments. Energy efficiency is another concern for battery powered wireless sensors. Considering the physics of wireless communications, we propose an approach called Software-Defined Wireless Communications (SDC) that dynamically decide a reliable channel(s) avoiding unnecessary redundancy of channels, out of multiple distinct electromagnetic frequency bands such as radio and infrared frequencies.We validate the concept with Android and Raspberry Pi sensors and pseudo extreme experiments. SDC can be utilized in many areas beyond space applications.
Valves are used to regulate the flow of fluids through systems. This rotary valve's main purpose is to fill, pressurize, empty, and vent three smaller tanks with the supply of one larger tank. Many different designs are being taken into consideration, which are each at different stages of development. The furthest along uses three ball valves on a common shaft to open and close their respective ports as the shaft completes one full rotation or cycle. We were tasked with advancing this design to its first test as a plastic model for flow verification, as well as sizing and ordering the necessary O-rings and fasteners. A motor will also be sized to satisfy the torque requirements, and will then be programmed using a Raspberry Pi to rotate the shaft at the calculated speed and dwelling times needed to fill each tank equally. In addition, we have also been advancing designs that use a camshaft and poppets. These are earlier on in their development, currently being sized to replicate the expected flow patterns of the rotary ball valve. Expected outcomes of this valve include bi-directionality, successful sealing under pressure, and accurate cycling.
Experimental evolution (EE) exposes microbial communities to ecological stressors, simulating dynamics up to near-extinction events. Combined with comparative sequencing and other molecular tools, such data can inform the genetic and other biological mechanisms underlying extremophile adaptation, and other observed effects. Automating this type of experiment using biofluidics can mitigate many traditional obstacles, including delays in assay results and environment adjustment and the need for many replicates. A first-generation device for automating EE procedures, the Automated Adaptive Directed Evolution Chamber (AADEC), was developed at NASA Ames. UV-C radiation was the stressor, an LED-photodiode array measured optical density, magnetic agitation and peristaltic pump systems ensured nutrient availability, and Arduino microcontrollers provided control. Escherichia coli in LB kanamycin media was used for testing and performance verification. A manual laboratory procedure with timed exposure to UV-C was performed to typify tolerance acquisition. Approximately a 106 factor increase in survival ratio was recorded over multiple iterations. Currently, a second-generation device is being developed integrating more real-time sensors: redox potential (ORP), indicating available/consumed metabolic energy; dissolved oxygen (DO), indicating aerobic/anaerobic growth; pH, indicating metabolic products; and electrical conductivity (EC), another indicator of metabolic products. The EC sensor system was constructed and calibrated in-house and matched commercial sensors in the required range. A Raspberry Pi computer automated the electrical system, allowing real-time data acquisition. The fluidics card was made of CNC-milled polycarbonate for biocompatibility. Each sensor parameter can also be used as a selection pressure alone or in combination with others to create extreme microbial environments. As a proof of concept, this work demonstrated sensor operation in one pair of growth-sensor chambers. It can be expanded to a multi-chamber system to enable inter-culture comparisons and multi-population studies. The prior Arduino system will be ported to the RPi system. Future stressors to be added include thermal, reactive oxygen species, and varying nutrient availability.
The International Space Station (ISS) not only serves as a unique environment for humans, but also the microorganisms that join alongside. Many microbes present on the spacecraft arrive via humans, and as they interact with different surfaces they begin to inhabit those locations. Much like how human health has shown to be impacted by these extreme environments, microbial viability and response to stress also changes. Experimental evolution (EE) can aid in studying how microbes’ growth and activity changes within the ISS environments by applying controlled stressors to microbial cultures and monitoring their response over generations. EE studies are commonly done manually in laboratories, but, with multiple environmental variables to measure and adjust, it becomes highly labor-intensive, prone to human error, and challenging to scale. A multipurpose automated EE system named the AADEC has been developed to address these problems. This system integrates multiple sensors into a single fluidic chamber using UV-C flux, temperature, and media composition as stressors. AADEC contains five sensors: oxidation-reduction potential, electrical conductivity, pH, dissolved oxygen, and optical density. On their own, each is able to provide certain information on growth rate or metabolism; together, they show in detail how stressors affect life. AADEC studies can be conducted on Earth and repeated aboard the ISS to see how behavior changes when exposed to space mission stressors such as microgravity and radiation. AADEC’s auxiliary systems include peristaltic pumps for media exchange, magnetic rods for agitation, and a Raspberry Pi microprocessor to monitor, store, and adjust stressor levels real-time. This allows researchers to gather information within rapid generations, data and accuracy which is challenging to achieve through manual studies. With further miniaturization and automation, such as a more robust single-piece fluidics card, AADEC has the potential to be developed as a spacecraft payload. Support: NASA Ames CIF Award
Sustainable missions, beyond low Earth orbit, will require autonomous capabilities in order to achieve NASA’s Artemis program objectives. Correspondingly, the crew must have a means to efficiently interact with these autonomous systems; this can be facilitated via voice and speech communications. Voice-based controls enable the user to access autonomous systems hands-free/eyes-free, allowing the user to better focus on critical tasks. The goal of this project was to explore the knowledge and technology needed to successfully design effective voice interfaces for autonomous systems. The main objective was to understand how a crew member, through voice interaction, could most efficiently and intuitively communicate with a notional autonomous vehicle system manager. This project leveraged prior research conducted by the University of Michigan’s Bioastronautics and Life Support System (BLiSS) team as part of a NASA Moon to Mars eXploration Systems and Habitation (M2M X-Hab) 2020 Academic Innovation Challenge. The X-Hab 2020 work from the BliSS Team resulted in an intuitive graphical user interface/user experience that was built on an Internet of Things (IOT) platform. The Voice User Interface (VUI) design for the M2M X-Hab 2021 project leveraged this technology and incorporated a voice-based assistant and NASA’s Platform for Autonomous Systems (NPAS) software. This required technologies to convert voice to text, conduct semantic interpretations, and convert responses from the autonomous system to text and to speech; additionally, the background noise environment of spacecraft was assessed, and a relatable personality for the autonomous system to facilitate human-like conversations was created. This work’s success was largely due to the diverse team that included expertise in Space Systems Engineering, Human Computer Interaction, Aerospace Engineering, Computer Science, Biomedical Engineering, and Applied Physics. The differing perspectives fostered elaborate discussions, resulting in the conception of three main interactions: (1) User-System, (2) NPAS-System, and (3) Environment-System. The system developed, i.e. the VUI, had to be unique, efficient, and intuitive; thus, the team crafted a personality for the system to enable human-like conversation. User surveys sent to students and young professionals were used to help determine these personality traits by capturing perspectives and expectations of the “Artemis Generation Astronauts”. To further simulate human-like conversations, the system had to be able to quickly interpret user speech and be able to integrate with NASA’s NPAS system for quick and reliable information transfer. Results of this research include (1) a working prototype user interface, that is compatible with NASA’s NPAS system; (2) software that demonstrates the ability to interpret user requests and respond appropriately; (3) the capability to implement fully expanded conversations between user and system using intuitive communication in four request categories; and (4) software and hardware recommendations that optimize the system’s ability to operate, i.e. be heard, in a noisy environment. The technologies chosen for this project’s demonstrations included the following: Raspberry Pi, RASA, Mozilla Deep Speech, Coqui, RTX Voice and Adobe XD. This work has laid the foundation for the development of VUI’s used for autonomy, and is intended to provide guidance for future VUI development.
Missions to small bodies within our solar system are becoming more frequent. Generally, shape models of the target body are required to perform proximity operations as demonstrated by the OSIRIS-REx, Hayabusa2, and Rosetta missions. However, these missions required image downlinking to create high-resolution models on the ground. In some missions, especially small-sats, there may be data downlink data constraints, resulting in the inability to provide the large number of images needed for high-resolution shape models. A solution to this is the ability to generate shape models on-board during the approach to the target or initial proximity surveying. Current work implements a limb-based shape model routine that is able to be executed on a Raspberry Pi 1, which is similar to the processing capability to the flight computer on OSIRIS-REx, and that does not require low phase angle geometries. Initial shape model results generated from Bennu approach (Nov 2-3, 2018) show that the limb-based shape model agrees well with a 75-cm SPC shape model generated after Preliminary Survey; Results are: min difference -7.047m, max difference 17.347m, mean 1.122m, and RMS 3.219m. Further scenarios are presented herein.
The methodologies for studying marine microbiology typically consist of utilizing instrumentation within a laboratory. This typically requires extracting a sample from its place of origin prior to examination, which may be days after collection. Oftentimes, the solution is to bring the lab to the ocean, which may be costly and provide further limitations for a sterile and stable laboratory environment. Here we present a low-cost, submersible, digital holographic microscope (DHM) designed to image marine microorganisms (such as bacteria and plankton) in their natural underwater environment. Our instrument eliminates the need to transport samples and allows for instantaneous data collection of microbes in-situ. The DHM achieves sub-micron spatial resolution and is paired with artificial intelligence for the detection and tracking of specimens to reduce the overall collected data. This instrument also aims to reduce the cost of manufacturing and field expenses relative to marine microbiological research. “Off the shelf” components were selected in the design process of this instrument which allows us to achieve precise results without sacrificing data quality. The DHM itself costs under one thousand dollars and features a low-cost high-resolution camera, the Arducam MT9J001. Included in the design were five main subsystems: optical, mechanical, electrical, power, and machine learning. Our on board computer and artificial intelligence consist of a Raspberry Pi 4 (8 Gb) and Google Coral USB Tensorflow accelerator. Instrument testing has successfully proven our abilities of data acquisition for at least two hours in depths of at least forty meters below sea level. Additionally, our artificial intelligence system is currently capable of tracking up to ten areas of interest in a fraction of a second with over ninety percent confidence via the neural net driven by the tensor cores on the Google Coral. Furthermore, we have demonstrated the versatility of our instrument by mounting it on an ocean-going ROV, the BlueRov2 by BlueRobotics. Our tests on the BlueRov2 exemplified the cost-effective nature of a submersible and reusable instrument that can be implemented in moderate environments and on most vessels.