Search NASA⌕ Search

SEARCH · Search NASA

Results for “WiFi”

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.

Firmware Architecture of the ARMADAS Bolting Robot

The Automated Reconfigurable Mission Adaptive Digital Assembly Systems (ARMADAS) project, under development at NASA Ames Research Center, has demonstrated on-ground autonomous robotic assembly of extensive digital structures, and it is now moving forward towards in-space demonstration. The ARMADAS system comprises of the operation software, the operation user interface (opsUI), and a swarm of robots. The robotic system consists of a multitude of collaborative agents specifically designed to transport, place and bolt the building blocks, called voxels (volumetric pixels). This paper focuses on the bolting robot, referred to as Mobile Metamaterial Internal Co-Integrator (MMIC-I). MMIC-I is a battery-powered crawling robot. It navigates the structure through extension, contraction and gripping. Two distinct controller boards operate the robot's two symmetric modules, referred to as module A and B. Board A is the master board: it coordinates motion planning and motion primitives execution, hosts the WiFi client, performs periodic self-assessment and system idle check and triggers faults if anomalies are detected. Board B periodically sends a heartbeat to board A, through a wired communication channel that uses the Serial protocol. Additionally, board A's WiFi client receives heartbeat packet requests or motion/bolting commands from a dedicated server board, and acknowledges reception sending back a response heartbeat packet containing information about the overall robot status, e. g. electrical current and voltage values, target and actual angles, operating mode, fault status. Whenever a motion command is sent, the motion planning section of the firmware determines the current robot configuration, using Inertial Measurement Unit readings and the motors Pulse Width Modulation values. Afterwards, it calculates the list of primitives needed to reach the target state, and controls their execution in the proper order. MMIC-I can receive and execute motion and bolting commands only when it is in operational mode. MMIC-I has three operating modes: standby, operational and safed. Standby mode is automatically entered upon startup. While in standby mode, all motors are powered off, and the only accepted commands are the ones relative to a change of mode and heartbeat packet request. Fault detection causes the robot to automatically enter safed or standby mode. Whenever the detected fault occurs within a motion and requires immediate intervention, e. g. an over-current situation, the robot enters safed mode. Safed mode powers off all motors except for the locomotion module, thus preventing the robot from collapsing. Conversely, when the detected fault doesn't require immediate intervention (low battery warning, for instance), the robot enters standby mode after completing the ongoing motion. This paper provides a detailed discussion of MMIC-I's firmware architecture. It accurately describes the implementation approach for each module: sensor data reading, motor control and actuation, WiFi server-client communication, intra-boards Serial communication, operating modes and autonomous fault detection, motion planning, coordination and execution, etc. Moreover, in support of the software description, this paper includes a thorough characterization of MMIC-I's hardware and avionics.

In-space assembly↗

The Functional Breakdown Structure (FBS) and Its Relationship to Life Cycle Cost

The Functional Breakdown Structure (FBS) is a structured, modular breakdown of every function that must be addressed to perform a generic mission. It is also usable for any subset of the mission. Unlike a Work Breakdown Structure (WBS), the FBS is a function-oriented tree, not a product-oriented tree. The FBS details not products, but operations or activities that should be performed. The FBS is not tied to any particular architectural implementation because it is a listing of the needed functions, not the elements, of the architecture. The FBS for Space Transportation Systems provides a universal hierarchy of required functions, which include ground and space operations as well as infrastructure - it provides total visibility of the entire mission. By approaching the systems engineering problem from the functional view, instead of the element or hardware view, the SPST has created an exhaustive list of potential requirements which the architecture designers can use to evaluate the completeness of their designs. This is a new approach that will provide full accountability of all functions required to perform the planned mission. It serves as a giant check list to be sure that no functions are omitted, especially in the early architectural design phase. A significant characteristic of a FBS is that if architecture options are compared using this approach, then any missing or redundant elements of each option will be ' identified. Consequently, valid Life Cycle Costs (LCC) comparisons can be made. For example, one architecture option might not need a particular function while another option does. One option may have individual elements to perform each of three functions while another option needs only one element to perform the three functions. Once an architecture has been selected, the FBS will serve as a guide in development of the work breakdown structure, provide visibility of those technologies that need to be further developed to perform required functions, and help identify the personnel skills required to develop and operate the architecture. It also wifi allow the systems engineering activities to totally integrate each discipline to the maximum extent possible and optimize at the total system level, thus avoiding optimizing at the element level (stove-piping). In addition, it furnishes a framework that wifi help prevent over or under specifying requirements because all functions are identified and all elements are aligned to functions.

DeHoff, Bryan↗

Nanosensors-Cellphone Integration for Extended Chemical Sensing Network

This poster is to present the development of a cellphone sensor network for extended chemical sensing. The nanosensors using carbon nanotubes and other nanostructures are used with low power and high sensitivity for chemical detection. The sensing module has been miniaturized to a small size that can plug in or clip on to a smartphone. The chemical information detected by the nanosensors are acquired by a smartphone and transmitted via cellphone 3g or WiFi network to an internet server. The whole integrated sensing system from sensor to cellphone to a cloud will provide an extended chemical sensing network that can cover nation wide and even cover global wide for early warning of a hazardous event.

Li, Jing↗

Abstract - Belbas, Nicholas (EC2)

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.

Belbas, Nicholas↗

Deploying a Route Optimization EFB Application for Commercial Airline Operational Trials

The Traffic Aware Planner (TAP), developed for NASA Langley Research Center to support the Traffic Aware Strategic Aircrew Requests (TASAR) project, is a flight-efficiency software application developed for an Electronic Flight Bag (EFB). Tested in two flight trials and planned for operational testing by two commercial airlines, TAP is a real-time trajectory optimization application that leverages connectivity with onboard avionics and broadband Internet sources to compute and recommend route modifications to flight crews to improve fuel and time performance. The application utilizes a wide range of data, including Automatic Dependent Surveillance Broadcast (ADS-B) traffic, Flight Management System (FMS) guidance and intent, on-board sensors, published winds and weather, and Special Use Airspace (SUA) schedules. This paper discusses the challenges of developing and deploying TAP to various EFB platforms, our solutions to some of these challenges, and lessons learned, to assist commercial software developers and hardware manufacturers in their efforts to implement and extend TAP functionality in their environments. EFB applications (such as TAP) typically access avionics data via an ARINC 834 Simple Text Avionics Protocol (STAP) server hosted by an Aircraft Interface Device (AID) or other installed hardware. While the protocol is standardized, the data sources, content, and transmission rates can vary from aircraft to aircraft. Additionally, the method of communicating with the AID may vary depending on EFB hardware and/or the availability of onboard networking services, such as Ethernet, WIFI, Bluetooth, or other mechanisms. EFBs with portable and installed components can be implemented using a variety of operating systems, and cockpits are increasingly incorporating tablet-based technologies, further expanding the number of platforms the application may need to support. Supporting multiple EFB platforms, AIDs, avionics datasets, and user interfaces presents a challenge for software developers and the management of their code baselines. Maintaining multiple baselines to support all deployment targets can be extremely cumbersome and expensive. Certification also needs to be considered when developing the application. Regardless of whether the software is itself destined to be certified, data requirements in support of the application and user interface elements may introduce certification requirements for EFB manufacturers and the airlines. The example of TAP, the challenges faced, solutions implemented, and lessons learned will give EFB application and hardware developers insight into future potential requirements in deploying TAP or similar flight-deck EFB applications.

Roscoe, David A.↗

The TechEdSat-N Series: A Collaborative Technology Development Platform in the Nano-Satellite Form Factor

The TechEdSat-1 (TES-1) was the first U.S. CubeSat to be deployed from the ISS (International Space Station). This permitted the initiation of a flight series that has recently de-orbited the 6th nano-satellite with subsequent numbers 7-10 under development. The nano-satellites range from 1U (1 unit) to 6U (TechEdSat-8) but have the critical ISS Safety design features standardized in order to focus on the particular experiment objectives. Incremental experimental development has included unique communication subsystems such as command/control of the nanosatellite through email commands -as well as a recent record for Wifi transmission. Also, the thermophysics of controlled drag devices (Exo-Brake) has been developed which will prelude sample return and planetary exploration applications. The successful "rapid incremental experiment" approach has also been incorporated into collaborations with academia, permitting professors/student interns to be exposed to the rigors of space mission hardware design and execution. The TechEdSat-8, a linear 6U configuration, allows for 5 different groups to contribute an "experiment, sensor, or sub-system" through a well-defined common interface. Lastly, the flying laboratory concept is helpful in developing future interplanetary nano-satellite subsystems which will advance exploration goals by allowing rapid demonstration/validation first in LEO (Low Earth Orbit).

Small Payload Quick Return↗

Flight Readiness of Mochii S: Portable Spectroscopic Scanning Electron Microscope Facility on the International Space Station (ISS)

The ISS (International Space Station) currently lacks the capability to image and chemically analyze nano-to-micron scale particles from numerous engineering systems. To identify these particles, we must wait for a re-entry vehicle to return them from low earth orbit for ground-based SEM (Scanning Electron Microscope) / EDS (Energy Dispersive X-Ray Spectroscopy) analysis. This may take months, potentially delaying the affected system. Having an EDS-equipped SEM (Mochii S) aboard the ISS will accelerate response time thereby enhancing crew and vehicle safety by rapid and accurate identification of microscopic threats, especially in time-critical situations.The Mochii S payload will be stationed in the Japanese Experiment Module (JEM) powered by 120 VAC (Volts Alternating Current) inverter and connected to station Ethernet and WiFi (Fig. 1). To date the Mochii S payload has undergone testing for command and data handling, power quality, flight vibration, and radiation testing at Johnson Space Center (JSC). Mochii's high-RPM (Revolutions Per Minute) rotating vacuum pumps and high voltage systems have been reviewed to meet safety standards by JSC (Johnson Space Center) Engineering. Topology of the system in the JEM module has been baselined by ISS Safety and JAXA (Japan Space Exploration Agency). Digital controls to and from ISS over Joint Station LAN (Local Area Network) uplink have been simulated and the latencies and data rates have been found to be sufficient for successful operation of the payload from ground.Transporting sensitive electron optical instruments aboard a rocket that sustains 7G acceleration for 8 minutes and then operating it the unique microgravity (micro-g) environment is no trivial matter. To meet strict safety requirements and increase robustness for mission success, over 500 unique verifications must be completed before the payload is certified for spaceflight. Two of which will be discussed in detail are: vibroacoustic testing and magnetic susceptibility shielding and validation.

Mochii↗

Effectiveness of Redundant Communications Systems in Maintaining Operational Control of Small Unmanned Aircraft

NASA has been researching prototype technologies for an Unmanned Aircraft System (UAS) Traffic Management (UTM) system to facilitate enabling of safe and efficient civilian low-altitude airspace and UAS operations, in a series of Technical Capability Levels (TCL) activities that are increasingly complex. In TCL1, completed in 2015, visual line-of-sight operations such as agriculture, firefighting and infrastructure monitoring were addressed with a focus on geofencing and operations scheduling. Technologies and requirements needed for beyond visual line-of-sight (BVLOS) operations in sparsely populated areas were examined in TCL2 in 2016, and those for operations over moderately populated areas in TCL3 in 2017 and 2018. TCL4 will build on the earlier TCLs and focus on technologies and requirements for operations in higher-density urban areas for tasks such as news gathering, package delivery and for managing large-scale contingencies. This paper describes a communications test conducted in TCL3 and discusses insights gained from the test. In the test, operators were directed to equip UAS with redundant Command and Control (C2) communications systems, send a maneuver command to Unmanned Aircraft (UA) via the primary system, then verify execution of the sent command. This exercise was repeated with each redundant system. The test was designed to assess effectiveness of redundant C2 systems in maintaining operational control of UA. Several UAS were configured with varying arrangements to achieve redundancy, including two identical radio modems using the same frequency band, WiFi and Long-Term Evolution (LTE) cellular modems, etc. From the test, digital data such as time maneuver command sent, time maneuver verified, etc., were collected. Descriptions of methods to detect loss of C2 communications and contingency steps for such event were collected and assessed. The final paper will include a detailed analysis of the collected data leading to the following insights. First, effectiveness of redundant C2 systems depends on several factors, such as operational environment and communications service availability. For example, use of two identical point-to-point radio to connect operator and UA on the same frequency band can be effective in mitigating radio malfunction when operating in an environment where possibility of Radio Frequency (RF) interference is low, such as over open plains. However, the same arrangement may not be effective where high level of RF transmissions in broad spectrum ranges can be expected, such as over or near urban areas. For redundant systems that consist of external communications services, such as cellular and satellite communications network, redundancy is maintained only in the areas where more than one services are available. Therefore, UAS operators should have the means to plan for and monitor the performance of external communications services they are relying on to control UA. Second, communications performance needs, such as the minimum data transfer rate and the maximum tolerable latency, should be assessed to reflect the potential hazard that can come from loss of UA control. For example, UA operations over desolate area pose less hazard to people than operations over densely populated area and performance need for the former would be less than the latter.

Jung, Jaewoo↗

Recent Advances in High Altitude Pseudosatellites (HAPS) and Potential Roles in Future Earth Observing Systems

In August 2001 the NASA Environmental Research Aircraft and Sensor Technology (ERAST) Program flew the Helios aircraft to an altitude of nearly 100,000ft, demonstrating a new type of remote sensing platform. Nearly 20 years later the earth science community has unmet observational requirements to loiter over regions of interest for days or weeks as well as to follow airmasses to study chemistry and dynamics in concert with spaceborne observations. Recent advances in materials science and engineering have enabled improved battery power density, solar panel efficiency, and light yet strong structural materials required to effectively operate high-altitude (50-70k ft altitude) Pseudo-Satellites (HAPS) for 30+ days. The rapid commercialization of small unmanned aircraft has also contributed to the maturation of HAPS by making avionics, GPS, and other sub-systems smaller and less expensive. HAPS payloads provide high-resolution data that complement geostationary and polar orbiting satellites, while also enabling in-situ sampling of atmospheric chemistry and dynamics. Recent commercial interest in HAPS for 4G/5G and WIFI has funded development of a new generation of aircraft available to the science community. Here I report on a project under the NASA Airborne Science Program to test and demonstrate earth observations from a prototype aircraft being developed under a NASA Small Business Innovative Research Phase II. This aircraft will demonstrate the ability for a solar electric aircraft to deliver a 2u cubesat-based passive optical imaging satellite to 70,000ft for 30 or more days. Discussion will include the anticipated maturation timeline for HAPS, development and operational challenges, and examples of mission concepts that might contribute to future earth observing systems.

Helios aircraft↗

The Gandalf Staff: A Mobile Tool for Lunar Exploration (2nd year of development)

The Gandalf Staff is a mobile tool designed to be a flexible device supporting crewed and uncrewed operations on the lunar surface. The core of the device is a 24v battery with communications and data storage systems. Initial optional components supporting crewed Extra-Vehicular Activity (EVA) include a LiDAR and 360˚ camera. These provide 3D mapping of the traverse for documentation, and to aid future planning. The mapping also creates outreach opportunities for the public to “stand beside” the astronaut in Virtual Reality (VR). The staff provides external lighting for field site illumination in the south polar region low sun angle environment. Navigation instruments for crew position determination with Lunar Search and Rescue (LunaSAR) are also included. The staff itself can be used as a walking aid or as a splint for Incapacitated Crew Rescue (ICR). As a stand-alone device, the staff operates as a long duration untended science platform collecting environmental data and sending it to a lunar base station. The stand-alone mode requires connection to an auxiliary power source (e.g. solar array) and energy storage system (e.g. battery), so it could become an electrical recharging station. To make rapid progress in the 1st year, and also to demonstrate innovative project management techniques, NASA guided a private industry partner, T STAR, in leading Capstone Engineering student teams at Texas A&M University (TAMU) for proof-of-concept development and testing. These teams developed the power system and demonstrated successful integration of LiDAR, WiFi communications, and external lighting subsystems. Another industry team at Jacobs Technology prototyped a tripod to hold the staff upright. For the 2nd year (FY’22), NASA will again collaborate with partners to prototype enhanced power and lighting concepts. Year 2 will also add new capability for LunaSAR and geophysical science instrumentation using a heat probe. The heat probe is based upon Apollo heritage but modified to measure subsurface volatile ice regimes at the Artemis landing site. Components of the Gandalf Staff can be developed, tested, and deployed independently, or on the integrated staff, rovers, or utility trailers. The project supports crew safety, lunar sample curation, mission science, and public outreach goals of NASA. PLAIN TEST SUMMARY: Gandalf Staff is a 24v battery powered mobile tool for the lunar surface supporting crewed geologic field site exploration, or as a stand-alone science platform. As a tool assisting astronauts conducting field geology, the Gandalf Staff provides external lighting to illuminate shadowed regions on the surface. It also documents the process of collecting rocks and dust samples using a LiDAR (laser range instrument) and cameras. The staff provides a beacon for emergency location of astronauts and augments communications when the astronauts are blocked by large boulders. As a standalone science platform, the Gandalf Staff provides a power system for instruments and sensors to measure the lunar environment over long periods of time. The staff gathers data and sends the results to a lunar base station for analysis.

External Lighting↗

Object and Gas Source Detection with Robotic Platforms in Perceptually-Degraded Environments

In exploration-oriented robotic missions for disaster relief in unknown subterranean environments, it is of prime importance for a human supervisor to rapidly gain situational awareness of salient objects within the environment. In this paper we present an automated object detection pipeline that is adaptable to heterogeneous robots with arbitrary sensor configurations. It has been deployed in time-critical scenarios with multiple collaborative robots in a variety of demanding underground environments. For visually observable objects, detections are made in both the visible and thermal spectra using a state-of-the-art machine learning framework for object detection and classification. Our pipeline can be rapidly adapted to a specific task by using a small, structured dataset to fine-tune a pre-trained convolutional neural network (CNN). Relative localization is separated from the CNN for speed of operation. A robust architecture for localization is used with outlier rejection and a hierarchy of fall-back distance measurement methods. Point-source objects such as gas and WiFi hotspots can also be detected, by tracking signal strength over time and presenting an intuitive visualization on a map. Observations of each object types are presented to the operator in ranked confidence order for final evaluation.

Agha-mohammadi, Ali-akbar↗

Artemis I Is the First NASA Mission to Use Wi-Fi® in Lunar Orbit

During the countdown procedure for the Artemis I launch, the flight control team at NASA’s Johnson Space Center in Houston activated a set of cameras looking back at the vehicle from the wing-tips of the solar arrays. Throughout the flight, the team used photos from these cameras to survey and assess the condition of the vehicle, monitor for micrometeorite damage, and maintain situational awareness. The ground control team was even able to watch live video as the solar array wings unfolded. The cameras continued to store imagery to internal memory as well as send photos over Wi-Fi® even as the vehicle lost communication with Earth as it flew behind the moon. Artemis I is the first NASA mission to use WiFi in lunar orbit.

Wi-Fi↗

SOLL-E: A Module Transport and Placement Robot for Autonomous Assembly of Discrete Lattice Structures

This paper presents the design and development of a transport and placement robot that demonstrates autonomous assembly of structural building blocks. The robots are intended to serve as a critical component of automated structural assembly and maintenance systems. The Scaling Omni-directional Lattice Locomoting Explorer (SOLL-E) uses a 5-DoF bipedal inchworm locomotion architecture with locking foot and cargo grippers. The locomotion system employs large magnet gap diameter BLDC motors with moderate timing belt gearing for primary joints, and DC planetary gearmotors for turning. Foot and cargo grippers are identical, with servo-actuated locking mechanisms. Three modular controller boards are used to control these actuators in real-time, with command and telemetry data transferred between the server and each controller board via WiFi. Functionality and performance were evaluated in a ground demonstration.

robotics↗

Lunar Surface Network Relay Terminal: A Lunar Communications Platform

This paper will discuss the development of a Lunar Surface Relay that will serve as a central terminal for lunar surface wireless communications (e.g., 3GPP, Wi-Fi) for surface assets to transmit and receive data back-and-forth with Earth through lunar orbital relays or direct with Earth. Four variations of a wireless surface terminal were designed with varying concepts of operation to assess mass, power, cost drivers, and trade-offs. The designs entailed one stationary platform and three mobile which provided interesting trade-offs. The terminals are powered for operation with either a radioisotope/battery power system or solar array/battery power system.

WiFi↗