Search NASA⌕ Search

SEARCH · Search NASA

Results for “script”

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.

At least 541 records · Page 30
All sourcesNASA NTRSDOE OSTI
NASA NTRS2009

Method and associated apparatus for capturing, servicing, and de-orbiting earth satellites using robotics

This invention is a method and supporting apparatus for autonomously capturing, servicing and de-orbiting a free-flying spacecraft, such as a satellite, using robotics. The capture of the spacecraft includes the steps of optically seeking and ranging the satellite using LIDAR; and matching tumble rates, rendezvousing and berthing with the satellite. Servicing of the spacecraft may be done using supervised autonomy, which is allowing a robot to execute a sequence of instructions without intervention from a remote human-occupied location. These instructions may be packaged at the remote station in a script and uplinked to the robot for execution upon remote command giving authority to proceed. Alternately, the instructions may be generated by Artificial Intelligence (AI) logic onboard the robot. In either case, the remote operator maintains the ability to abort an instruction or script at any time, as well as the ability to intervene using manual override to teleoperate the robot.In one embodiment, a vehicle used for carrying out the method of this invention comprises an ejection module, which includes the robot, and a de-orbit module. Once servicing is completed by the robot, the ejection module separates from the de-orbit module, leaving the de-orbit module attached to the satellite for de-orbiting the same at a future time. Upon separation, the ejection module can either de-orbit itself or rendezvous with another satellite for servicing. The ability to de-orbit a spacecraft further allows the opportunity to direct the landing of the spent satellite in a safe location away from population centers, such as the ocean.

Cepollina, Frank J.↗
NASA NTRS2007

Automatic Command Sequence Generation

Automatic Sequence Generator (Autogen) Version 3.0 software automatically generates command sequences for the Mars Reconnaissance Orbiter (MRO) and several other JPL spacecraft operated by the multi-mission support team. Autogen uses standard JPL sequencing tools like APGEN, ASP, SEQGEN, and the DOM database to automate the generation of uplink command products, Spacecraft Command Message Format (SCMF) files, and the corresponding ground command products, DSN Keywords Files (DKF). Autogen supports all the major multi-mission mission phases including the cruise, aerobraking, mapping/science, and relay mission phases. Autogen is a Perl script, which functions within the mission operations UNIX environment. It consists of two parts: a set of model files and the autogen Perl script. Autogen encodes the behaviors of the system into a model and encodes algorithms for context sensitive customizations of the modeled behaviors. The model includes knowledge of different mission phases and how the resultant command products must differ for these phases. The executable software portion of Autogen, automates the setup and use of APGEN for constructing a spacecraft activity sequence file (SASF). The setup includes file retrieval through the DOM (Distributed Object Manager), an object database used to store project files. This step retrieves all the needed input files for generating the command products. Depending on the mission phase, Autogen also uses the ASP (Automated Sequence Processor) and SEQGEN to generate the command product sent to the spacecraft. Autogen also provides the means for customizing sequences through the use of configuration files. By automating the majority of the sequencing generation process, Autogen eliminates many sequence generation errors commonly introduced by manually constructing spacecraft command sequences. Through the layering of commands into the sequence by a series of scheduling algorithms, users are able to rapidly and reliably construct the desired uplink command products. With the aid of Autogen, sequences may be produced in a matter of hours instead of weeks, with a significant reduction in the number of people on the sequence team. As a result, the uplink product generation process is significantly streamlined and mission risk is significantly reduced. Autogen is used for operations of MRO, Mars Global Surveyor (MGS), Mars Exploration Rover (MER), Mars Odyssey, and will be used for operations of Phoenix. Autogen Version 3.0 is the operational version of Autogen including the MRO adaptation for the cruise mission phase, and was also used for development of the aerobraking and mapping mission phases for MRO.

Fisher, Forest↗
NASA NTRS2010

Integrating Radar Image Data with Google Maps

A public Web site has been developed as a method for displaying the multitude of radar imagery collected by NASA s Airborne Synthetic Aperture Radar (AIRSAR) instrument during its 16-year mission. Utilizing NASA s internal AIRSAR site, the new Web site features more sophisticated visualization tools that enable the general public to have access to these images. The site was originally maintained at NASA on six computers: one that held the Oracle database, two that took care of the software for the interactive map, and three that were for the Web site itself. Several tasks were involved in moving this complicated setup to just one computer. First, the AIRSAR database was migrated from Oracle to MySQL. Then the back-end of the AIRSAR Web site was updated in order to access the MySQL database. To do this, a few of the scripts needed to be modified; specifically three Perl scripts that query that database. The database connections were then updated from Oracle to MySQL, numerous syntax errors were corrected, and a query was implemented that replaced one of the stored Oracle procedures. Lastly, the interactive map was designed, implemented, and tested so that users could easily browse and access the radar imagery through the Google Maps interface.

Chapman, Bruce D.↗
NASA NTRS2009

Formal Methods for Automated Diagnosis of Autosub 6000

This is a progress report on applying formal methods in the context of building an automated diagnosis and recovery system for Autosub 6000, an Autonomous Underwater Vehicle (AUV). The diagnosis task involves building abstract models of the control system of the AUV. The diagnosis engine is based on Livingstone 2, a model-based diagnoser originally built for aerospace applications. Large parts of the diagnosis model can be built without concrete knowledge about each mission, but actual mission scripts and configuration parameters that carry important information for diagnosis are changed for every mission. Thus we use formal methods for generating the mission control part of the diagnosis model automatically from the mission script and perform a number of invariant checks to validate the configuration. After the diagnosis model is augmented with the generated mission control component model, it needs to be validated using verification techniques.

Ernits, Juhan↗
NASA NTRS2010

Applied Meteorology Unit (AMU) Quarterly Report - Fourth Quarter FY-10

Three AMU tasks were completed in this Quarter, each resulting in a forecast tool now being used in operations and a final report documenting how the work was done. AMU personnel completed the following tasks (1) Phase II of the Peak Wind Tool for General Forecasting task by delivering an improved wind forecasting tool to operations and providing training on its use; (2) a graphical user interface (GUI) she updated with new scripts to complete the ADAS Update and Maintainability task, and delivered the scripts to the Spaceflight Meteorology Group on Johnson Space Center, Texas and National Weather Service in Melbourne, Fla.; and (3) the Verify MesoNAM Performance task after we created and delivered a GUI that forecasters will use to determine the performance of the operational MesoNAM weather model forecast.

Bauman, William↗
NASA NTRS2010

ADAS Update and Maintainability

Since 2000, both the National Weather Service Melbourne (NWS MLB) and the Spaceflight Meteorology Group (SMG) have used a local data integration system (LOIS) as part of their forecast and warning operations. The original LOIS was developed by the Applied Meteorology Unit (AMU) in 1998 (Manobianco and Case 1998) and has undergone subsequent improvements. Each has benefited from three-dimensional (3-D) analyses that are delivered to forecasters every 15 minutes across the peninsula of Florida. The intent is to generate products that enhance short-range weather forecasts issued in support of NWS MLB and SMG operational requirements within East Central Florida. The current LDIS uses the Advanced Regional Prediction System (ARPS) Data Analysis System (AD AS) package as its core, which integrates a wide variety of national, regional, and local observational data sets. It assimilates all available real-time data within its domain and is run at a finer spatial and temporal resolution than current national or regional-scale analysis packages. As such, it provides local forecasters with a more comprehensive understanding of evolving fine-scale weather features. Over the years, the LDIS has become problematic to maintain since it depends on AMU-developed shell scripts that were written for an earlier version of the ADAS software. The goals of this task were to update the NWS MLB/SMG LDIS with the latest version of ADAS, incorporate new sources of observational data, and upgrade and modify the AMU-developed shell scripts written to govern the system. In addition, the previously developed ADAS graphical user interface (GUI) was updated. Operationally, these upgrades will result in more accurate depictions of the current local environment to help with short-range weather forecasting applications, while also offering an improved initialization for local versions of the Weather Research and Forecasting (WRF) model used by both groups.

Watson, Leela R.↗
NASA NTRS2005

FastScript3D - A Companion to Java 3D

FastScript3D is a computer program, written in the Java 3D(TM) programming language, that establishes an alternative language that helps users who lack expertise in Java 3D to use Java 3D for constructing three-dimensional (3D)-appearing graphics. The FastScript3D language provides a set of simple, intuitive, one-line text-string commands for creating, controlling, and animating 3D models. The first word in a string is the name of a command; the rest of the string contains the data arguments for the command. The commands can also be used as an aid to learning Java 3D. Developers can extend the language by adding custom text-string commands. The commands can define new 3D objects or load representations of 3D objects from files in formats compatible with such other software systems as X3D. The text strings can be easily integrated into other languages. FastScript3D facilitates communication between scripting languages [which enable programming of hyper-text markup language (HTML) documents to interact with users] and Java 3D. The FastScript3D language can be extended and customized on both the scripting side and the Java 3D side.

Koenig, Patti↗
NASA NTRS2008

Use of Spacecraft Command Language for Advanced Command and Control Applications

The purpose of this work is to evaluate the use of SCL in building and monitoring command and control applications in order to determine its fitness for space operations. Approximately 24,325 lines of PCG2 code was converted to SCL yielding a 90% reduction in the number of lines of code as many of the functions and scripts utilized in SCL could be ported and reused. Automated standalone testing, simulating the actual production environment, was performed in order to generalize and gauge the relative time it takes for SCL to update and write a given display. The use of SCL rules, functions, and scripts allowed the creation of several test cases permitting the detection of the amount of time it takes update a given set of measurements given the change in a globally existing CUI or CUI. It took the SCL system an average 926.09 ticks to update the entire display of 323 measurements.

Mims, Tikiela L.↗
NASA NTRS2011

Robonaut 2 - Initial Activities On-Board the ISS

Robonaut 2, or R2, arrived on the International Space Station in February 2011 and is currently undergoing testing in preparation for it to become, initially, an Intra-Vehicular Activity (IVA) tool and then evolve into a system that can perform Extra-Vehicular Activities (EVA). After the completion of a series of system level checks to ensure that the robot traveled well on-board the Space Shuttle Atlantis, ground control personnel will remotely control the robot to perform free space tasks that will help characterize the differences between earth and zero-g control. For approximately one year, the fixed base R2 will perform a variety of experiments using a reconfigurable task board that was launched with the robot. While working side-by-side with human astronauts, Robonaut 2 will actuate switches, use standard tools, and manipulate Space Station interfaces, soft goods and cables. The results of these experiments will demonstrate the wide range of tasks a dexterous humanoid can perform in space and they will help refine the methodologies used to control dexterous robots both in space and here on earth. After the trial period that will evaluate R2 while on a fixed stanchion in the US Laboratory module, NASA plans to launch climbing legs that when attached to the current on-orbit R2 upper body will give the robot the ability to traverse through the Space Station and start assisting crew with general IVA maintenance activities. Multiple control modes will be evaluated in this extra-ordinary ISS test environment to prepare the robot for use during EVAs. Ground Controllers will remotely supervise the robot as it executes semi-autonomous scripts for climbing through the Space Station and interacting with IVA interfaces. IVA crew will locally supervise the robot using the same scripts and also teleoperate the robot to simulate scenarios with the robot working alone or as an assistant during space walks.

Diftler, M. A.↗
NASA NTRS2011

MicroShell Minimalist Shell for Xilinx Microprocessors

MicroShell is a lightweight shell environment for engineers and software developers working with embedded microprocessors in Xilinx FPGAs. (MicroShell has also been successfully ported to run on ARM Cortex-M1 microprocessors in Actel ProASIC3 FPGAs, but without project-integration support.) Micro Shell decreases the time spent performing initial tests of field-programmable gate array (FPGA) designs, simplifies running customizable one-time-only experiments, and provides a familiar-feeling command-line interface. The program comes with a collection of useful functions and enables the designer to add an unlimited number of custom commands, which are callable from the command-line. The commands are parameterizable (using the C-based command-line parameter idiom), so the designer can use one function to exercise hardware with different values. Also, since many hardware peripherals instantiated in FPGAs have reasonably simple register-mapped I/O interfaces, the engineer can edit and view hardware parameter settings at any time without stopping the processor. MicroShell comes with a set of support scripts that interface seamlessly with Xilinx's EDK tool. Adding an instance of MicroShell to a project is as simple as marking a check box in a library configuration dialog box and specifying a software project directory. The support scripts then examine the hardware design, build design-specific functions, conditionally include processor-specific functions, and complete the compilation process. For code-size constrained designs, most of the stock functionality can be excluded from the compiled library. When all of the configurable options are removed from the binary, MicroShell has an unoptimized memory footprint of about 4.8 kB and a size-optimized footprint of about 2.3 kB. Since MicroShell allows unfettered access to all processor-accessible memory locations, it is possible to perform live patching on a running system. This can be useful, for instance, if a bug is discovered in a routine but the system cannot be rebooted: Shell allows a skilled operator to directly edit the binary executable in memory. With some forethought, MicroShell code can be located in a different memory location from custom code, permitting the custom functionality to be overwritten at any time without stopping the controlling shell.

Werne, Thomas A.↗
NASA NTRS2012

Time-Domain Terahertz Computed Axial Tomography NDE System

NASA has identified the need for advanced non-destructive evaluation (NDE) methods to characterize aging and durability in aircraft materials to improve the safety of the nation's airline fleet. 3D THz tomography can play a major role in detection and characterization of flaws and degradation in aircraft materials, including Kevlar-based composites and Kevlar and Zylon fabric covers for soft-shell fan containment where aging and durability issues are critical. A prototype computed tomography (CT) time-domain (TD) THz imaging system has been used to generate 3D images of several test objects including a TUFI tile (a thermal protection system tile used on the Space Shuttle and possibly the Orion or similar capsules). This TUFI tile had simulated impact damage that was located and the depth of damage determined. The CT motion control gan try was designed and constructed, and then integrated with a T-Ray 4000 control unit and motion controller to create a complete CT TD-THz imaging system prototype. A data collection software script was developed that takes multiple z-axis slices in sequence and saves the data for batch processing. The data collection software was integrated with the ability to batch process the slice data with the CT TD-THz image reconstruction software. The time required to take a single CT slice was decreased from six minutes to approximately one minute by replacing the 320 ps, 100-Hz waveform acquisition system with an 80 ps, 1,000-Hz waveform acquisition system. The TD-THZ computed tomography system was built from pre-existing commercial off-the-shelf subsystems. A CT motion control gantry was constructed from COTS components that can handle larger samples. The motion control gantry allows inspection of sample sizes of up to approximately one cubic foot (.0.03 cubic meters). The system reduced to practice a CT-TDTHz system incorporating a COTS 80- ps/l-kHz waveform scanner. The incorporation of this scanner in the system allows acquisition of 3D slice data with better signal-to-noise using a COTS scanner rather than the gchirped h scanner. The system also reduced to practice a prototype for commercial CT systems for insulating materials where safety concerns cannot accommodate x-ray. A software script was written to automate the COTS software to collect and process TD-THz CT data.

Zimdars, David↗
NASA NTRS2013

Sample Analysis at Mars Instrument Simulator

The Sample Analysis at Mars Instrument Simulator (SAMSIM) is a numerical model dedicated to plan and validate operations of the Sample Analysis at Mars (SAM) instrument on the surface of Mars. The SAM instrument suite, currently operating on the Mars Science Laboratory (MSL), is an analytical laboratory designed to investigate the chemical and isotopic composition of the atmosphere and volatiles extracted from solid samples. SAMSIM was developed using Matlab and Simulink libraries of MathWorks Inc. to provide MSL mission planners with accurate predictions of the instrument electrical, thermal, mechanical, and fluid responses to scripted commands. This tool is a first example of a multi-purpose, full-scale numerical modeling of a flight instrument with the purpose of supplementing or even eliminating entirely the need for a hardware engineer model during instrument development and operation. SAMSIM simulates the complex interactions that occur between the instrument Command and Data Handling unit (C&DH) and all subsystems during the execution of experiment sequences. A typical SAM experiment takes many hours to complete and involves hundreds of components. During the simulation, the electrical, mechanical, thermal, and gas dynamics states of each hardware component are accurately modeled and propagated within the simulation environment at faster than real time. This allows the simulation, in just a few minutes, of experiment sequences that takes many hours to execute on the real instrument. The SAMSIM model is divided into five distinct but interacting modules: software, mechanical, thermal, gas flow, and electrical modules. The software module simulates the instrument C&DH by executing a customized version of the instrument flight software in a Matlab environment. The inputs and outputs to this synthetic C&DH are mapped to virtual sensors and command lines that mimic in their structure and connectivity the layout of the instrument harnesses. This module executes, and thus validates, complex command scripts prior to their up-linking to the SAM instrument. As an output, this module generates synthetic data and message logs at a rate that is similar to the actual instrument.

Benna, Mehdi↗
NASA NTRS2013

MPST Software: grl_suppdoc

Due to the nature of the GRAIL mission, the GRAIL Mission Planning and Sequence Team (MPST) is required to generate ground and uplink products faster than ever done before. The existing correct_transmitter_min_dur tool that provides a similar function to grl_suppdoc lacks the ability to operate accurately or quickly enough to support the rapid turnaround required of the GRAIL MPST. The GRAIL MPST was required to build this new tool to facilitate the ground and uplink generation processes to meet a tight sequence development timeline. The grl_suppdoc tool enables the GRAIL MPST to generate automatically Deep Space Network (DSN) transmitter suppressions based on short uplinks that are found in the ground/modeled Predicted Events File (PEF). The grl_suppdoc script automatically generates applicable DSN uplink suppressions in the form of a Spacecraft Activity Sequence File (SASF) to protect the GRAIL project from short DSN uplink windows, which can be cause for operator error at the DSN antennas. Currently, no software exists that provides this functionality at the efficiency required for GRAIL sequence team operations. Compared to a manual process, this script reduces human error and saves considerable man-hours by automating and streamlining the mission planning and sequencing task for the GRAIL mission.

Call, Jared A.↗
NASA NTRS2014

SCCS System SW Development

The original project to be completed, GenSim, was a Generic Simulator for Application Control Language scripts. This would mock the systems on which the scripts were meant to be run on so that you could run tests without access to the machine. Soon after the project was started, a different project took priority. Unit testing the Application Services Framework code became the focus of the team because of approaching deadlines. Communication was very important to ensure that code wasn't being duplicated and to keep the team up to date with what mock files are available to them. Because of this, daily meetings were conducted until the testing was complete.

computer programming↗
NASA NTRS2014

Unit Testing and Remote Display Development

The Kennedy Space Center is currently undergoing an extremely interesting transitional phase. The final Space Shuttle mission, STS-135, was completed in July of 2011. NASA is now approaching a new era of space exploration. The development of the Orion Multi- Purpose Crew Vehicle (MPCV) and the Space Launch System (SLS) launch vehicle that will launch the Orion are currently in progress. An important part of this transition involves replacing the Launch Processing System (LPS) which was previously used to process and launch Space Shuttles and their associated hardware. NASA is creating the Spaceport Command and Control System (SCCS) to replace the LPS. The SCCS will be much simpler to maintain and improve during the lifetime of the spaceflight program that it will support. The Launch Control System (LCS) is a portion of the SCCS that will be responsible for launching the rockets and spacecraft. The Integrated Launch Operations Applications (ILOA) group of SCCS is responsible for creating displays and scripts, both remote and local, that will be used to monitor and control hardware and systems needed to launch a spacecraft. It is crucial that the software contained within be thoroughly tested to ensure that it functions as intended. Unit tests must be written in Application Control Language (ACL), the scripting language used by LCS. These unit tests must ensure complete code coverage to safely guarantee there are no bugs or any kind of issue with the software.

LCS↗
NASA NTRS2015

Cloud-Based Numerical Weather Prediction for Near Real-Time Forecasting and Disaster Response

The use of cloud computing resources continues to grow within the public and private sector components of the weather enterprise as users become more familiar with cloud‐computing concepts, and competition among service providers continues to reduce costs and other barriers to entry. Cloud resources can also provide capabilities similar to high‐performance computing environments, supporting multi‐node systems required for near real‐time, regional weather predictions. Referred to as "Infrastructure as a Service", or IaaS, the use of cloud-based computing hardware in an on‐demand payment system allows for rapid deployment of a modeling system in environments lacking access to a large, supercomputing infrastructure. Use of IaaS capabilities to support regional weather prediction may be of particular interest to developing countries that have not yet established large supercomputing resources, but would otherwise benefit from a regional weather forecasting capability. Recently, collaborators from NASA Marshall Space Flight Center and Ames Research Center have developed a scripted, on‐demand capability for launching the NOAA/NWS Science and Training Resource Center (STRC) Environmental Modeling System (EMS), which includes pre‐compiled binaries of the latest version of the Weather Research and Forecasting (WRF) model. The WRF‐EMS provides scripting for downloading appropriate initial and boundary conditions from global models, along with higher‐resolution vegetation, land surface, and sea surface temperature data sets provided by the NASA Short‐term Prediction Research and Transition (SPoRT) Center. This presentation will provide an overview of the modeling system capabilities and benchmarks performed on the Amazon Elastic Compute Cloud (EC2) environment. In addition, the presentation will discuss future opportunities to deploy the system in support of weather prediction in developing countries supported by NASA's SERVIR Project, which provides capacity building activities in environmental monitoring and prediction across a growing number of regional hubs throughout the world. Capacity‐building applications that extend numerical weather prediction to developing countries are intended to provide near real‐time applications to benefit public health, safety, and economic interests, but may have a greater impact during disaster events by providing a source for local predictions of weather‐related hazards, or impacts that local weather events may have during the recovery phase.

Molthan, Andrew↗
NASA NTRS2015

Summary of Aqua, Aura, and Terra High Interest Events

Single-obs tracking Sparsely tracked objects are an unfortunate reality of CARA operations Terra vs. 32081: new track with bad data was included in OD solution for secondary object and risk became high CARA and JSpOC discussed tracking and OSAs threw out the bad data. Event no longer presented high risk based on new OD Improvement: CARA now sends JSpOC a flag indicating when a single obs is included, so OSAs can evaluate if manual update to OD is required. Missing ASW OCMsAura vs. 87178, TCA: 317 at 08:04 UTC. Post-maneuver risk (conjunction was identified in OO results)CARA confirmed with JSpOC that ASW OCMs should have been received in addition to OO OCMsJSpOC corrected the manual error in their script that prevented the data from being delivered to CARAJSpOC QAd their other scripts to ensure this error did not exist in other places.

Conjunction↗
NASA NTRS2015

Software Development: 3D Animations and Creating User Interfaces for Realistic Simulations

My fall 2015 semester was spent at the Lyndon B. Johnson Space Center working in the Integrated Graphics, Operations, and Analysis Laboratory (IGOAL). My first project was to create a video animation that could tell the story of OMICS. OMICS is a term being used in the field of biomedical science to describe the collective technologies that study biological systems, such as what makes up a cell and how it functions with other systems. In the IGOAL I used a large 23 inch Wacom monitor to draw storyboards, graphics, and line art animations. I used Blender as the 3D environment to sculpt, shape, cut or modify the several scenes and models for the video. A challenge creating this video was to take a term used in biomedical science and describe it in such a way that an 8th grade student can understand. I used a line art style because it would visually set the tone for what we thought was an educational style. In order to get a handle on the perspective and overall feel for the animation without overloading my workspace, I split up the 2 minute animation into several scenes. I used Blender's python scripting capabilities which allowed for the addition of plugins to add or modify tools. The scripts can also directly interact with the objects to create naturalistic patterns or movements. After collecting the rendered scenes, I used Blender's built-in video editing workspace to output the animation. My second project was to write software that emulates a physical system's interface. The interface was to simulate a boat, ROV, and winch system. Simulations are a time and cost effective way to test complicated data and provide training for operators without having to use expensive hardware. We created the virtual controls with 3-D Blender models and 2-D graphics, and then add functionality in C# using the Unity game engine. The Unity engine provides several essential behaviors of a simulator, such as the start and update functions. A framework for Unity, which was developed in the lab, provided a way to place the different widgets on the virtual console dock and have them resize correctly based on the window dimensions.. My task in this project was to create the controls and visualizations for the data coming in from the simulator for the boat portion of the project. I wrote a class for each control window to handle the functionality of that widget. I implemented 11 widgets that make up the ship portion of the simulator. The members of the lab were each masters of their craft and I'm glad I had the opportunity to learn from them. I learned to plan strategically so I could finish this project on time. I allotted time for storyboarding, development, and refinement. In regards to animating I learned to use modifiers like lattice, boolean and build deformers. I also learned how to animate with drivers, how to use the dope sheet, and how to use the graph editor. In coding I learned to limit the chances for bugs by privatizing functions that should be exclusive to their class. I learned how to use the GIT repository to commit, stash and pull the latest build. I learned a bit of everything because I had the chance to see the entire application development process from the artwork, to the implementation.

Gordillo, Orlando Enrique↗