Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software triggering”

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.

219 records · Page 13

High-Speed Ring Bus

The high-speed ring bus at the Jet Propulsion Laboratory (JPL) allows for future growth trends in spacecraft seen with future scientific missions. This innovation constitutes an enhancement of the 1393 bus as documented in the Institute of Electrical and Electronics Engineers (IEEE) 1393-1999 standard for a spaceborne fiber-optic data bus. It allows for high-bandwidth and time synchronization of all nodes on the ring. The JPL ring bus allows for interconnection of active units with autonomous operation and increased fault handling at high bandwidths. It minimizes the flight software interface with an intelligent physical layer design that has few states to manage as well as simplified testability. The design will soon be documented in the AS-1393 standard (Serial Hi-Rel Ring Network for Aerospace Applications). The framework is designed for "Class A" spacecraft operation and provides redundant data paths. It is based on "fault containment regions" and "redundant functional regions (RFR)" and has a method for allocating cables that completely supports the redundancy in spacecraft design, allowing for a complete RFR to fail. This design reduces the mass of the bus by incorporating both the Control Unit and the Data Unit in the same hardware. The standard uses ATM (asynchronous transfer mode) packets, standardized by ITU-T, ANSI, ETSI, and the ATM Forum. The IEEE-1393 standard uses the UNI form of the packet and provides no protection for the data portion of the cell. The JPL design adds optional formatting to this data portion. This design extends fault protection beyond that of the interconnect. This includes adding protection to the data portion that is contained within the Bus Interface Units (BIUs) and by adding to the signal interface between the Data Host and the JPL 1393 Ring Bus. Data transfer on the ring bus does not involve a master or initiator. Following bus protocol, any BIU may transmit data on the ring whenever it has data received from its host. There is no centralized arbitration or bus granting. The JPL design provides for autonomous synchronization of the nodes on the ring bus. An address-synchronous latency adjust buffer (LAB) has been designed that cannot get out of synchronization and needs no external input. Also, a priority-driven cable selection behavior has been programmed into each unit on the ring bus. This makes the bus able to connect itself up, according to a maximum redundancy priority system, without the need for computer intervention at startup. Switching around a failed or switched-off unit is also autonomous. The JPL bus provides a map of all the active units for the host computer to read and use for fault management. With regard to timing, this enhanced bus recognizes coordinated timing on a spacecraft as critical and addresses this with a single source of absolute and relative time, which is broadcast to all units on the bus with synchronization maintained to the tens of nanoseconds. Each BIU consists of up to five programmable triggers, which may be programmed for synchronization of events within the spacecraft of instrument. All JPL-formatted data transmitted on the ring bus are automatically time-stamped.

Wysocky, Terry↗

Cooperative Three-Robot System for Traversing Steep Slopes

Teamed Robots for Exploration and Science in Steep Areas (TRESSA) is a system of three autonomous mobile robots that cooperate with each other to enable scientific exploration of steep terrain (slope angles up to 90 ). Originally intended for use in exploring steep slopes on Mars that are not accessible to lone wheeled robots (Mars Exploration Rovers), TRESSA and systems like TRESSA could also be used on Earth for performing rescues on steep slopes and for exploring steep slopes that are too remote or too dangerous to be explored by humans. TRESSA is modeled on safe human climbing of steep slopes, two key features of which are teamwork and safety tethers. Two of the autonomous robots, denoted Anchorbots, remain at the top of a slope; the third robot, denoted the Cliffbot, traverses the slope. The Cliffbot drives over the cliff edge supported by tethers, which are payed out from the Anchorbots (see figure). The Anchorbots autonomously control the tension in the tethers to counter the gravitational force on the Cliffbot. The tethers are payed out and reeled in as needed, keeping the body of the Cliffbot oriented approximately parallel to the local terrain surface and preventing wheel slip by controlling the speed of descent or ascent, thereby enabling the Cliffbot to drive freely up, down, or across the slope. Due to the interactive nature of the three-robot system, the robots must be very tightly coupled. To provide for this tight coupling, the TRESSA software architecture is built on a combination of (1) the multi-robot layered behavior-coordination architecture reported in "An Architecture for Controlling Multiple Robots" (NPO-30345), NASA Tech Briefs, Vol. 28, No. 10 (October 2004), page 65, and (2) the real-time control architecture reported in "Robot Electronics Architecture" (NPO-41784), NASA Tech Briefs, Vol. 32, No. 1 (January 2008), page 28. The combination architecture makes it possible to keep the three robots synchronized and coordinated, to use data from all three robots for decision- making at each step, and to control the physical connections among the robots. In addition, TRESSA (as in prior systems that have utilized this architecture) , incorporates a capability for deterministic response to unanticipated situations from yet another architecture reported in Control Architecture for Robotic Agent Command and Sensing (NPO-43635), NASA Tech Briefs, Vol. 32, No. 10 (October 2008), page 40. Tether tension control is a major consideration in the design and operation of TRESSA. Tension is measured by force sensors connected to each tether at the Cliffbot. The direction of the tension (both azimuth and elevation) is also measured. The tension controller combines a controller to counter gravitational force and an optional velocity controller that anticipates the motion of the Cliffbot. The gravity controller estimates the slope angle from the inclination of the tethers. This angle and the weight of the Cliffbot determine the total tension needed to counteract the weight of the Cliffbot. The total needed tension is broken into components for each Anchorbot. The difference between this needed tension and the tension measured at the Cliffbot constitutes an error signal that is provided to the gravity controller. The velocity controller computes the tether speed needed to produce the desired motion of the Cliffbot. Another major consideration in the design and operation of TRESSA is detection of faults. Each robot in the TRESSA system monitors its own performance and the performance of its teammates in order to detect any system faults and prevent unsafe conditions. At startup, communication links are tested and if any robot is not communicating, the system refuses to execute any motion commands. Prior to motion, the Anchorbots attempt to set tensions in the tethers at optimal levels for counteracting the weight of the Cliffbot; if either Anchorbot fails to reach its optimal tension level within a specified time, it sends message to the other robots and the commanded motion is not executed. If any mechanical error (e.g., stalling of a motor) is detected, the affected robot sends a message triggering stoppage of the current motion. Lastly, messages are passed among the robots at each time step (10 Hz) to share sensor information during operations. If messages from any robot cease for more than an allowable time interval, the other robots detect the communication loss and initiate stoppage.

Stroupe, Ashley↗

Optical follow-up of gravitational wave triggers with DECam during the first two LIGO/VIRGO observing runs

Gravitational wave (GW) events detectable by LIGO and Virgo have several possible progenitors, including black hole mergers, neutron star mergers, black hole–neutron star mergers, supernovae, and cosmic string cusps. A subset of GW events is expected to produce electromagnetic (EM) emission that, once detected, will provide complementary information about their astrophysical context. To that end, the LIGO–Virgo Collaboration (LVC) sends GW candidate alerts to the astronomical community so that searches for their EM counterparts can be pursued. The DESGW group, consisting of members of the Dark Energy Survey (DES), the LVC, and other members of the astronomical community, uses the Dark Energy Camera (DECam) to perform a search and discovery program for optical signatures of LVC GW events. DESGW aims to use a sample of GW events as standard sirens for cosmology. Due to the short decay timescale of the expected EM counterparts and the need to quickly eliminate survey areas with no counterpart candidates, it is critical to complete the initial analysis of each night’s images as quickly as possible. We discuss our search area determination, imaging pipeline, and candidate selection processes. We review results from the DESGW program during the first two LIGO–Virgo observing campaigns and introduce other science applications that our pipeline enables.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗