Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “MacOSX”

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.

LIvermore SEM image Tools

Scanning Electron Microscopy (SEM) images provide a variety of structural and morphological information for the characterization of the nanomaterials. This code offers automatic recognition and quantitative analysis of SEM images in a high-throughput manner using computer vision and machine learning techniques. The main function of this application is to extract particle size and morphology information of overlapping nanoparticles and core-shell nanostructures in a user friendly interface. The code is written in C++ with QT environment, and has been tested on MacOSX.

KIM, HYOJIN↗

HONE Sensor Wireshark Shim

The Hone sensors are packet-process correlation engines that log the relationships between applications and the communications they are responsible for. Hone sensors are available for a variety of platforms including Linux, Windows, and MacOSX

Fink, Glenn↗

Adoption of Test Driven Development and Continuous Integration for the Development of the Trick Simulation Toolkit

This paper describes the adoption of a Test Driven Development approach and a Continuous Integration System in the development of the Trick Simulation Toolkit, a generic simulation development environment for creating high fidelity training and engineering simulations at the NASA/Johnson Space Center and many other NASA facilities. It describes what was learned and the significant benefits seen, such as fast, thorough, and clear test feedback every time code is checked-in to the code repository. It also describes a system that encourages development of code that is much more flexible, maintainable, and reliable. The Trick Simulation Toolkit development environment provides a common architecture for user-defined simulations. Trick builds executable simulations using user-supplied simulation-definition files (S_define) and user supplied "model code". For each Trick-based simulation, Trick automatically provides job scheduling, checkpoint / restore, data-recording, interactive variable manipulation (variable server), and an input-processor. Also included are tools for plotting recorded data and various other supporting tools and libraries. Trick is written in C/C++ and Java and supports both Linux and MacOSX. Prior to adopting this new development approach, Trick testing consisted primarily of running a few large simulations, with the hope that their complexity and scale would exercise most of Trick's code and expose any recently introduced bugs. Unsurprising, this approach yielded inconsistent results. It was obvious that a more systematic, thorough approach was required. After seeing examples of some Java-based projects that used the JUnit test framework, similar test frameworks for C and C++ were sought. Several were found, all clearly inspired by JUnit. Googletest, a freely available Open source testing framework, was selected as the most appropriate and capable. The new approach was implemented while rewriting the Trick memory management component, to eliminate a fundamental design flaw. The benefits became obvious almost immediately, not just in the correctness of the individual functions and classes but also in the correctness and flexibility being added to the overall design. Creating code to be testable, and testing as it was created resulted not only in better working code, but also in better-organized, flexible, and readable (i.e., articulate) code. This was, in essence the Test-driven development (TDD) methodology created by Kent Beck. Seeing the benefits of Test Driven Development, other Trick components were refactored to make them more testable and tests were designed and implemented for them.

Penn, John M.↗

Dynamics and Control of a Disordered System in Space

In this paper, we present some ideas regarding the modeling, dynamics and control aspects of granular spacecraft. Granular spacecraft are complex multibody systems composed of a spatially disordered distribution of a large number of elements, for instance a cloud of N grains in orbit, with N greater than 10(exp 3). These grains can be large (Cubesat-size) or small (mm-size), and can be active, i.e., a fully equipped vehicle capable sensing their own position and attitude, and enabled with propulsion means, or entirely passive. The ultimate objective would be to study the behavior of the single grains and of large ensembles of grains in orbit and to identify ways to guide and control the shape of a cloud composed of these grains so that it can perform a useful function in space, for instance, as an element of an optical imaging system for astrophysical applications. This concept, in which the aperture does not need to be continuous and monolithic, would increase the aperture size several times compared to large NASA observatories such as ATLAST, allowing for a true Terrestrial Planet Imager that would be able to resolve exo-planet details and do meaningful spectroscopy on distant world. In the paper, we address the modeling and autonomous operation of a distributed assembly (the cloud) of large numbers of highly miniaturized space-borne elements (the grains). A multi-scale, multi-physics model is proposed of the dynamics of the cloud in orbit, as well as a control law for cloud shape maintenance, and preliminary simulation studies yield an estimate of the computational effort, indicating a scale factor of approximately N(exp 1.4) as a function of the number of grains. A granular spacecraft can be defined as a collection of a large number of space-borne elements (in the 1000s) designed and controlled such that a desirable collective behavior emerges, either from the interactions among neighboring grains, and/or between the grains and the environment. In this paper, each grain is considered to be a highly miniaturized spacecraft which has limited size and mass, hence it has limited actuation, limited propulsive capability, limited power, limited sensing, limited communication, limited computational resources, limited range of motion, limited lifetime, and may be expendable. The modeling and dynamics of clouds of vehicles is more challenging than with conventional vehicles because we are faced with a probabilistic vehicle composed of a large number of physically disconnected vehicles. First, different scales of motion occur simultaneously in a cloud: translations and rotations of the cloud as a whole (macro-dynamics), relative rotation and translation of one cloud member with respect to another (meso-dynamics), and individual cloud member dynamics (micro-dynamics). Second, the control design needs to be tolerant of the system complexity, of the system architecture (centralized vs. decentralized large scale system control) as well as robust to un-modeled dynamics and noise sources. Figure 1, top left, shows the kinematic parameters of a 1000 element cloud in orbit. The motion of the system is described with respect to a local vertical-local horizontal (LV-LH) orbiting reference frame (x,y,z)=F(sub ORF) of origin O(sub ORF) which rotates with mean motion omega and orbital semi-major axis R(sub 0). The orbital geometry at the initial time is defined in terms of its six orbital elements, and the orbital dynamics equation for point O(sub ORF) is propagated forward in time under the influence of the gravitational field of the primary and other external perturbations, described below. The origin of this frame coincides with the initial position of the center of mass of the system, and the coordinate axes are z along the local vertical, x toward the flight direction, and y in the orbit normal direction. The assumptions we used to model the dynamics are as follows: 1) The inertial frame is fixed at Earth's center. 2) The orbiting Frame ORF follows Keplerian orbit. 3) the cloud system dynamics is referred to ORF. 4) the attitude of each grain uses the principal body frame as body fixed frame. 5) the atmosphere is assumed to be rigidly rotating with the Earth. Regarding the grains forming the cloud: 1) each grain is modeled as a rigid body; 2) a simple attitude estimator provides attitude estimates, 3) a simple guidance logic commands the position and attitude of each grain, 4) a simple local feedback controller based on PD control of local states is used to stabilize the attitude of the vehicle. Regarding the cloud: 1) the cloud as a whole is modeled as an equivalent rigid body in orbit, and 2) an associated graph establishes agent connectivity and enables coupling between modes of motion at the micro and macro scales; 3) a simple guidance and estimation logic is modeled to estimate and command the attitude of this equivalent rigid body; 4) a cloud shape maintenance controller is based on the dynamics of a stable virtual truss in the orbiting frame. Regarding the environmental perturbations acting on the cloud: 1) a non-spherical gravity field including JO (Earth's spherical field) zonal component, J2 (Earth's oblateness) and J3 zonal components is implemented; 2) atmospheric drag is modeled with an exponential model; 3) solar pressure is modeled assuming the Sun is inertially fixed; and 4) the Earth's magnetic field is model using an equivalent dipole model. The equations of motion are written in a referential system with respect to the origin of the orbiting frame and the state is propagated forward in time using an incremental predictor-corrector scheme. A representative cloud with varying number of grains is simulated to identify the limitations in computation time as the number of grains grows. We derive a control law to track a desired surface in the ORF (equivalently to maintain a reference cloud shape) by defining an error from a desired surface shape, and designing a control law that is exponentially stable and reduces the tracking error to zero. Figure 1 (top right) shows a comparison of various requirements for simulation of single spacecraft vs. granular spacecraft, indicating the high degree of complexity that needs to be taken into consideration. The ORF components of control force required by one of the grains is, for this particular case, in the micro-Newton range. However, no attempt has been made yet to reconfigure (or re-orient) the cloud configuration internally, for which forces in the milli-Newton level are expected, depending on the time required to do the reconfiguration. Figure 1, bottom, shows the computation time as a function of the number of grains, indicating an order N(exp 1.43) scaling on a 8 Gb, 1067 MHz RAM MacOSX computer with a 3.06 GHz Intel Core 2 Duo processor. With this metric, the same simulation for a system of N=1000 grains would take 5.4 hours, and 146 hours (i.e., 6 days) for a system with N=10,000 grains. Therefore, efficient ways to simulate this complex system, where not only the time scales of natural system dynamics, but also the sampling times of the Guidance, Navigation, and Control are included, remain to be explored. Additional details on the cloud modeling, dynamics, and control will be described in the paper.

simulation↗

The Trick Simulation Toolkit: A NASA/Opensource Framework for Running Time Based Physics Models

The Trick Simulation Toolkit is a simulation development environment used to create high fidelity training and engineering simulations at the NASA Johnson Space Center and many other NASA facilities. Its purpose is to generate a simulation executable from a collection of user-supplied models and a simulation definition file. For each Trick-based simulation, Trick automatically provides job scheduling, numerical integration, the ability to write and restore human readable checkpoints, data recording, interactive variable manipulation, a run-time interpreter, and many other commonly needed capabilities. This allows simulation developers to concentrate on their domain expertise and the algorithms and equations of their models. Also included in Trick are tools for plotting recorded data and various other supporting utilities and libraries. Trick is written in C/C++ and Java and supports both Linux and MacOSX computer operating systems. This paper describes Trick's design and use at NASA Johnson Space Center.

Penn, John M.↗

Integrated, Kerberized Login on MacOS X

Context for this information. MacOS X login process and available hooks. Authorization Services configuration. Authorization Services plug-in s. Kerberos plug-in s. Other bugs and recommendations. Authorization Services Called by loginwindow, screen saver and fast user switching. It calls Directory Services, Login Hook, and Login Items (System Preferences).

MacOSX↗