Core Flight System
The core Flight System is a flight software product line developed by the Flight Software Systems Branch at NASA GSFC. It replaces per-mission software with a layered framework plus a set of pluggable applications, and it has flown on spacecraft from a 6U CubeSat to Class A observatories [1][2]. Where the Mars Exploration Rover software is one team’s 93 modules and 300,000 source lines built for one vehicle [6], cFS is built so that a component can be reused with no source change at all, using compile-time configuration parameters for every point of variation [7].
What it is
Section titled “What it is”| Layer | Contents | Interface |
|---|---|---|
| 1 | Real-time operating system and board support package | OS Abstraction Layer and Platform Support Package APIs |
| 2 | core Flight Executive (cFE) | cFE API |
| 3 | Applications and shared libraries | cFE API |
| Tools | Ground system, build system, unit test framework, timing analyzer |
The cFE provides five services that the heritage analysis found common to most flight software projects: a Software Bus, Time Services, Event Services, Table Services and Executive Services [3]. The Software Bus is a publish and subscribe inter-application messaging system built on CCSDS packet formats, supporting single and multi-processor configurations. Table Services manage binary files of application-defined parameters that the ground can load and dump at runtime [3]. Event Services carry time-stamped parameterized text messages in four severity classes, filterable per message and per class [1]. Executive Services supply the runtime environment, and because cFE resources are tracked per application, an individual application can be started, stopped or loaded while the vehicle is flying. The framework is developed and maintained to the NASA Class B software process, and the open source release includes all Class B artifacts alongside the source.
The community applications carried by most missions are Checksum, Data Storage, File Manager, Housekeeping, Limit Checker, Memory Dwell, Memory Manager, Scheduler, Stored Command, Health and Safety, CFDP file transfer and a Software Bus network application [3]. Which application object files load at startup is decided by a script file read from a file system in EEPROM, so the load list is data rather than a link map [3].
The eight architecture goals stated for the framework are reducing time to deploy high quality flight software, reducing schedule and cost uncertainty, facilitating formalized reuse, enabling collaboration across organizations, simplifying on-orbit software maintenance over mission lifetimes exceeding ten years, scaling from small instruments to Hubble-class observatories, providing a platform for prototyping, and creating common standards and tools across the center [3]. Features are deprecated only on major versions, with tooling that warns applications using a deprecated feature.
Ported operating systems in the 6.4.2 baseline were POSIX Linux for development, RTEMS, VxWorks, VxWorks SMP and FreeRTOS, each with its own platform support package [1]. The reference distribution ships PROM boot flight software and board support package beneath that layer, and the framework itself has no boot responsibility [3].
Three trades made early fixed the shape of the layering: a custom publish and subscribe software bus over CCSDS packets rather than CCSDS AMS or a COTS message service such as NDDS, a vendor file system used uniformly for code, tables and the data recorder, and support for both dynamic and static application linking so a CubeSat with 800 KB of flash and 2 MB of RAM could still fit the framework [7]. The sizing target explains why the layering stayed thin enough to reach a 6U CubeSat at one end and Hubble-class observatories at the other.
What it cost, measured on GPM
Section titled “What it cost, measured on GPM”The Global Precipitation Measurement observatory, launched 27 February 2014, is a NASA Class B mission with articulating solar arrays, a gimbaled high gain antenna and nearly fully redundant hardware under flight software control [1]. It flies a RAD750 under VxWorks with 4 MB of EEPROM in two duplicate 2 MB banks and 24 MB of SRAM.
| Component | Logical lines of code, non-table | Configuration parameters | EEPROM bytes |
|---|---|---|---|
| cFE | 12,930 | 139 across five services | 341,561 |
| CFDP | 8,559 | 33 | 85,812 |
| Checksum | 2,873 | 15 | 35,242 |
| Data Storage | 2,429 | 27 | 40,523 |
| File Manager | 1,853 | 22 | 16,272 |
| Health and Safety | 1,531 | 45 | 15,071 |
| Housekeeping | 575 | 8 | 8,059 |
| Limit Checker | 2,074 | 13 | 31,026 |
| Memory Dwell | 1,035 | 8 | 8,617 |
| Memory Manager | 1,958 | 25 | 15,840 |
| Scheduler | 1,164 | 19 | 35,809 |
| Stored Command, 124 command sequences | 2,314 | 26 | 104,960 |
Source: [1], Table 3.
EEPROM is the most constrained resource on GPM and the cFS occupies about 35 percent of one 2 MB bank; the cFE image and application table images in that column are uncompressed while the application code images are compressed [1]. By lines of code the cFS accounts for 42 percent of the GPM flight software, excluding the VxWorks operating system.
The development cost avoided was estimated with SEER-SEM tuned for NASA missions: building the complete cFS suite from scratch for a Class B mission of GPM’s complexity is 49 person years [1]. Adopting it still costs tuning configuration parameters and adjusting task priorities, put at about 2 person years for a mission of that complexity and class [1].
GPM’s RAD750 and 24 MB of SRAM are generous next to a CubeSat processor, and the port to Dellingr, a 6U CubeSat deployed from the ISS in November 2017, shows what cFS costs when that margin is gone: its Gomspace Nanomind A712d carries a 40 MHz ARM7 and 2 MB of SRAM, not enough to hold the cFE and its applications in RAM at once, so the framework had to execute out of flash, only selected mission applications could be loaded dynamically to RAM, and CFDP file transfer and Housekeeping were dropped entirely to make room [8]. The port required a new OS abstraction layer for FreeRTOS 8.x, after which most of cFS ran unchanged, with the vendor firmware supplying the file systems underneath it, and the engineer who did the port judged cFS a poor fit for that processor, succeeding only because he already knew the framework well [8].
Flight record
Section titled “Flight record”| Mission | Launch | Processor | RTOS | Role of cFS |
|---|---|---|---|---|
| Lunar Reconnaissance Orbiter | 2009 | RAD750 | VxWorks | cFE co-developed; cFE API unchanged since |
| Radiation Belt Storm Probes, JHU APL | 2012 | cFE | ||
| Morpheus, JSC | 2013 test flights | cFS | ||
| GPM | 2014 | RAD750 | VxWorks | cFS co-developed |
| LADEE, Ames | 2014 | cFS | ||
| Magnetospheric Multiscale | 2015 | custom Coldfire command and data handling | RTEMS | cFS |
| Dellingr 6U CubeSat | 2017 | cFS |
Sources: [1] and [2]. As of 2016 the cFE application programming interface had not changed since the Lunar Reconnaissance Orbiter launch in 2009. Missions then in development ranged from NASA JSC Orion backup flight computer to Dellingr, spanning NASA software classes A through D [2]. The framework exists because the earlier Goddard practice of clone-and-own reuse, copying components from previous missions by functional similarity, left the scope of changes uncontrolled, forced a full verification and validation effort on each new mission and kept no single maintained lineage per component [2].
The open source release of February 2015 covered twelve commonly used applications and completed the stack [1]. A NASA-wide configuration control board drawn from Ames, Glenn, Goddard, Johnson, Langley, Marshall and JHU APL then took ownership, and is responsible for keeping all baseline products at NPR 7150.2B Class B [2].
Whether the code obeys the architecture
Section titled “Whether the code obeys the architecture”An independent static architecture analysis by the Fraunhofer Center for Experimental Software Engineering, using the SAVE tool on the cFS source, checked the design rules that the reuse claim rests on [5]. Two held: cFE applications depend on the cFE core and not the reverse, and no two applications interact directly rather than through the Software Bus. Two deviations were found: a cyclic dependency from the operating system layer back to the core, avoidable by moving one header, and two applications, Memory Manager and File Manager, that reached past the cFE API to include an OS abstraction header directly. Of the six applications examined, Housekeeping, Memory Dwell, Memory Manager, Checksum, File Manager and Limit Checker, all six use Executive Services to initialize, Event Services to report, and the Software Bus to send and receive; only some use Table, File and Time Services directly, but none of the three can be dropped from a build because the first three services depend on them. The analysis was static only, and the authors listed dynamic dependency extraction, message ordering and timing measurement of software bus bottlenecks as work not yet done.
Adoption on a rover
Section titled “Adoption on a rover”Resource Prospector, the canceled lunar volatiles mission managed at Ames with the rover built at NASA JSC, ran its rover flight software on cFS. The team’s stated reason was reuse: cFE, the Operating System Abstraction Layer and cFE-compliant applications supplied the core spacecraft functions while rover-specific applications were developed against them. The architecture was exercised on the RP15 rover testbed, taken from concept to a rover driving in the Johnson lunar rock yard within one year and operated by a team distributed across Ames, Johnson and Kennedy; the 2015 build 1 delivered hardware interfaces, basic mobility, waypoint driving, odometry and inertial measurement unit localization, basic error checking and camera services [4]. The RP15 vehicle that flight software ran was a 300 kg, four wheel, offset steered and actively suspended rover with a solar-pointing all-wheel steering mode, sized to a 3 to 4 km traverse requirement and carrying a low-computation laser hazard detector; that mobility design is the direct ancestor of VIPER’s [10].
What adoption costs
Section titled “What adoption costs”Three costs recur in the published accounts. The framework does not supply flight command ingest or telemetry output applications; the open source release carries only UDP-based laboratory versions, and every mission has had to write its own transport-specific versions, which new users report as the hardest part of deployment [8]. The framework is stated to provide Class B artifacts in full and only a subset of what a Class A mission needs [3]. There is no reusable device plug-in design pattern, so hardware interface applications are written from scratch each time [1]. And the coupling runs both ways: as the number of supported platforms grows, applications become harder to keep portable, and as the number of applications grows, supporting a platform becomes harder [3].
A structured comparison of six CubeSat flight software frameworks against seven selection criteria, run for the VCUB1 6U CubeSat mission, picked cFS as the design baseline chiefly on flight heritage and the configuration control board behind it: of the six, only cFS and one other had actually flown, and cFS’s OpenSatKit was judged the most turnkey of the software development kits compared [9].
References
- McComas, D., Wilmot, J. and Cudmore, A. (2016). The Core Flight System (cFS) Community: Providing Low Cost Solutions for Small Spacecraft
. Annual AIAA/USU Conference on Small Satellites. Source
BibTeX
@inproceedings{mccomas2016core, title = {The Core Flight System (cFS) Community: Providing Low Cost Solutions for Small Spacecraft}, author = {McComas, David and Wilmot, Jonathan and Cudmore, Alan}, booktitle = {Annual AIAA/USU Conference on Small Satellites}, year = {2016}, url = {https://ntrs.nasa.gov/citations/20160010300}, abstract = {In February 2015 the NASA Goddard Space Flight Center (GSFC) completed the open source release of the entire Core Flight Software (cFS) suite. After the open source release a multi-NASA center Configuration Control Board (CCB) was established that has managed multiple cFS product releases. The cFS was developed and is being maintained in compliance with the NASA Class B software development process requirements and the open source release includes all Class B artifacts. The cFS is currently running on three operational science spacecraft and is being used on multiple spacecraft and instrument development efforts. While the cFS itself is a viable flight software (FSW) solution, we have discovered that the cFS community is a continuous source of innovation and growth that provides products and tools that serve the entire FSW lifecycle and future mission needs. This paper summarizes the current state of the cFS community, the key FSW technologies being pursued, the development/verification tools and opportunities for the small satellite community to become engaged. The cFS is a proven high quality and cost-effective solution for small satellites with constrained budgets.} } - McComas, D. (2018). Increasing flight software reuse with OpenSatKit
. IEEE Aerospace Conference. Source
BibTeX
@inproceedings{mccomas2018core, title = {Increasing flight software reuse with OpenSatKit}, author = {McComas, David}, booktitle = {IEEE Aerospace Conference}, pages = {1--8}, publisher = {IEEE}, year = {2018}, doi = {10.1109/aero.2018.8396631}, abstract = {In January 2015 the National Aeronautics and Space Administration (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. The cFS 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 with minimal FSW development experience, such as universities, that are building CubeSats. This paper describes the OpenSatKit[2]that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. OpenSatKit 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. It includes eight cFS applications, several kit-specific applications, and built in demos that illustrate 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. 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 plans for the future.} } - NASA. (2020). Core Flight System (cFS) Training
. NASA, NASA/TM-20205000691 Rev 1. Source
BibTeX
@techreport{nasa2020core, title = {Core Flight System (cFS) Training}, author = {{NASA}}, number = {NASA/TM-20205000691 Rev 1}, institution = {NASA}, year = {2020}, url = {https://ntrs.nasa.gov/citations/20205011588} } - Andrews, D., Colaprete, A., Quinn, J., Bluethmann, W. and Trimble, J. (2015). Resource Prospector (RP) - Early Prototyping and Development
. AIAA SPACE Conference and Exposition, 20150018395. Source
BibTeX
@inproceedings{andrews2015resource, title = {Resource Prospector (RP) - Early Prototyping and Development}, author = {Andrews, Dan and Colaprete, Anthony and Quinn, Jacqueline and Bluethmann, William and Trimble, Jay}, booktitle = {AIAA SPACE Conference and Exposition}, number = {20150018395}, publisher = {American Institute of Aeronautics and Astronautics}, institution = {NASA}, address = {Pasadena, California}, year = {2015}, doi = {10.2514/6.2015-4460}, abstract = {The Resource Prospector (RP) is an In-Situ Resource Utilization (ISRU) technology demonstration mission under study by the NASA Human Exploration and Operations Mission Directorate's (HEOMD) Advanced Exploration Systems (AES) Division. The mission, currently planned to launch in 2020, will demonstrate extraction of oxygen from lunar regolith to validate ISRU capability. The mission will address key Strategic Knowledge Gaps (SKGs) for robotic and human exploration to the Moon, Near Earth Asteroids (NEAs), and ultimately Mars, as well as meet the strategic goals of the Global Exploration Roadmap (GER), offered by the International Space Exploration Coordination Group (ISECG). In this roadmap, the use of local resources is specifically addressed relating to human exploration. RP will provide knowledge to inform the selection of future mission destinations, support the development of exploration systems, and reduce the risk associated with human exploration. Expanding human presence beyond low-Earth orbit to asteroids and Mars will require the maximum possible use of local materials, so-called in-situ resources. The moon presents a unique destination to conduct robotic investigations that advance ISRU capabilities, as well as providing significant exploration and science value. Lunar regolith contains useful resources such as oxygen, water, silicon, and light metals, like aluminum and titanium. Oxygen can be separated from the regolith for life support (breathable air), or used to create rocket propellant (oxidizer). Regolith can be used to protect against radiation exposure, be processed into solar cells, or used to manufacture construction materials such as bricks and glass. RP will characterize the constituents and distribution of water and other volatiles at the poles of the Moon, enabling innovative uses of local resources, in addition to validating ISRU capabilities. This capability, as well as a deeper understanding of regolith, will be valuable in the exploration of near-Earth asteroids (NEAs) and Mars. In order to reduce risk and explore system designs, the RP project is attempting two-fold approaches to development as it looks towards flight. We continue to explore flight planning, requirements, and interfaces definition by using Engineering Test Units (ETUs), looking towards lunar deployment, while also using fiscal year 2015 to develop, build and test an earth-terrestrial prototype rover and payload system. This terrestrial prototype, called "RP15", is built to both inform the system design, and to be a partnership advocacy tool for this unique mission. RP15 must be affordable within the resource and time constraints of fiscal year 2015, while working to the following Needs, Goals, and Objectives provided by HEOMD/AES: 1. Demonstrate rover mobility in a 1g environment 2. The Surface Segment (prototype rover + payload system) shall represent the flight system concept with as much fidelity as affordable (limited by cost and schedule) - Surface Segment shall be the approximate size/dimension/footprint -Surface Segment shall package all the expected devices (instruments, systems, etc.), even if some facets are mocked-up due to time/cost constraints -Overall Surface Segment fidelity negotiable to make achievable 3. Priority should be given to illustrating mission functionality over support functionality, which exists solely to support mission functionality This paper will provide an overview of RP project developments, including the design and build, capturing the development and initial integrated testing of RP15 in relevant environments.} } - Ganesan, D., Lindvall, M. and McComas, D. (2009). Analyzing the Core Flight Software (CFS) with SAVE
. Flight Software Workshop (FSW-08). Source
BibTeX
@inproceedings{ganesan2009analyzing, title = {Analyzing the Core Flight Software (CFS) with SAVE}, author = {Ganesan, Dharmalingam and Lindvall, Mikael and McComas, David}, booktitle = {Flight Software Workshop (FSW-08)}, organization = {Fraunhofer Center for Experimental Software Engineering and NASA Goddard Space Flight Center}, year = {2009}, url = {https://ntrs.nasa.gov/citations/20090004613}, abstract = {This viewgraph presentation describes the SAVE tool and it's application to Core Flight Software (CFS). The contents include: 1) Fraunhofer-a short intro; 2) Context of this Collaboration; 3) CFS-Core Flight Software?; 4) The SAVE Tool; 5) Applying SAVE to CFS -A few example analyses; and 6) Goals.} } - Reeves, G. E. (2005). An Overview of the Mars Exploration Rovers Flight Software
. IEEE International Conference on Systems, Man and Cybernetics. Source
BibTeX
@inproceedings{reeves2005overview, title = {An Overview of the Mars Exploration Rovers Flight Software}, author = {Reeves, Glenn E.}, booktitle = {IEEE International Conference on Systems, Man and Cybernetics}, volume = {1}, pages = {1-7}, address = {Waikoloa, Hawaii}, year = {2005}, doi = {10.1109/icsmc.2005.1571113}, abstract = {The Mars exploration rovers (MER) flight software (FSW) is possibly the most complex software implementation to be deployed on another planet. The requirements dictated a software system that addressed four distinct mission phases (cruise, landing, egress, and surface) and the mission demanded a system with significant autonomy. The structure of the MER flight software reflects its object-oriented beginnings and the overall function reflects the requirements of the MER mission and spacecraft. This paper provides an overview of the function and structure of the MER flight software. The MER mission and spacecraft are briefly discussed to provide context for the flight software decomposition and the discussion of the software execution model.} } - Mccomas, D. (2019). The Core Flight System (cFS) Experiences in Opening an Architecture
. Goddard Space Flight Center, 20180007319. Source
BibTeX
@techreport{mccomas2019core, title = {The Core Flight System (cFS) Experiences in Opening an Architecture}, author = {Mccomas, David}, number = {20180007319}, institution = {Goddard Space Flight Center}, year = {2019}, url = {https://ntrs.nasa.gov/citations/20180007319}, abstract = {This presentation presents a software architecture model that contains three perspectives: User, Business, and System. This model is used to evaluate the evolution of the cFS from a NASA/Goddard in-house product line to an open source open architecture used by a world wide community. } } - Cudmore, A. (2017). Porting the Core Flight System to the Dellingr CubeSat
. Flight Software Workshop (FSW-). Source
BibTeX
@inproceedings{cudmore2017porting, title = {Porting the {Core Flight System} to the {Dellingr} {CubeSat}}, author = {Cudmore, Alan}, booktitle = {Flight Software Workshop (FSW-)}, organization = {NASA Technical Reports Server}, year = {2017}, url = {https://ntrs.nasa.gov/citations/20170011566}, abstract = {Dellingr is a 6U Cubesat developed by NASA Goddard Space Flight Center. It was delivered to the International Space Station in August 2017, and is scheduled to be deployed in November 2017. Compared to a typical NASA satellite, the Dellingr Cubesat had an extremely low budget and short schedule. Although the Dellingr Cubesat has minimal hardware resources, the cFS was ultimately chosen for the flight software. Using the cFS on the Dellingr Cubesat presented a few challenges, but also offered opportunities to help speed up development and verify the ACS flight software. This presentation will cover the lessons learned in porting the cFS to the Dellingr Cubesat, including working with the limited hardware resources, porting the cFS to FreeRTOS, and overcoming limitations related to data storage and file transfer. This presentation will also cover how hardware abstraction was used to run the flight software on multiple platforms and interface with the 42 dynamic simulator.} } - José Franzim Miranda, D., Ferreira, M., Kucinskis, F. and McComas, D. (2019). A Comparative Survey on Flight Software Frameworks for ‘New Space’ Nanosatellite Missions
. Journal of Aerospace Technology and Management. Source
BibTeX
@article{miranda2019comparative, title = {A Comparative Survey on Flight Software Frameworks for ‘New Space’ Nanosatellite Missions}, author = {José Franzim Miranda, Danilo and Ferreira, Maurício and Kucinskis, Fabricio and McComas, David}, journal = {Journal of Aerospace Technology and Management}, publisher = {FapUNIFESP (SciELO)}, year = {2019}, doi = {10.5028/jatm.v11.1081}, abstract = {Nanosatellite missions are becoming increasingly popular nowadays, especially because of their reduced cost. Therefore, many organizations are entering the space sector due to the paradigm shift caused by nanosatellites. Despite the reduced size of these spacecrafts, their Flight Software (FSW) complexity is not proportional to the satellite volume, thus creating a great barrier for the entrance of new players on the nanosatellite market. On the other side, there are some available frameworks that can provide mature FSW design approaches, implying in considerable reduction in software project timeframe and cost. This paper presents a comparative survey between six relevant flight software frameworks, compared according to commonly required ‘New Space’ criteria, and finally points out the most suitable one to the VCUB1 reference nanosatellite mission.} } - Fong, T., Bluethmann, W., Allan, M., Askew, S., Cannon, H., Deans, M., Fraser-Chanpong, N. and Markee, M. (2015). Development of the Resource Prospector Planetary Rover
. Moon - : A New Era of Coordinated Human and Robotic Exploration. Source
BibTeX
@inproceedings{fong2015development, title = {Development of the Resource Prospector Planetary Rover}, author = {Fong, Terrence and Bluethmann, William and Allan, Mark and Askew, Scott and Cannon, Howard and Deans, Matthew and Fraser-Chanpong, Nathan and Markee, Mason}, booktitle = {Moon - : A New Era of Coordinated Human and Robotic Exploration}, year = {2015}, url = {https://ntrs.nasa.gov/citations/20190000455}, abstract = {The Resource Prospector (RP) is an In-‐Situ Resource Utilization (ISRU) lunar rover mission under study by NASA. RP is planned to launch in 2020 to prospect for subsurface volatiles and to extract oxygen from lunar regolith. The mission will address several of NASA's "Strategic Knowledge Gaps" for lunar exploration. The mission will also address the Global Exploration Roadmap's strategic goal of using local resources for human exploration. The distribution of lunar subsurface volatiles drives the mission requirement for mobility. The spatial distribution is hypothesized to be governed by impact cratering with the top 0.5 m being patchy at scales of 100 m. The mixing time scale increases with depth (less frequent larger impacts). Consequently, increased mobility reduces the depth requirement for sampling. The target RP traverse will extend 1 km radially from the landing site to sample craters of varying sizes. Sampling craters with different ages will reveal possible volatile emplacement history. In 1 Ga, approximately 60-70 craters of 10 m diameter form per km2. Thus, the rover will need to sample at least ten of these craters, which may require a total traverse path length of 2-‐3 km. During 2014-2015, we developed an initial prototype rover for RP. The current design is a solar powered, four-wheeled vehicle, with hub motor drive, offset four wheel steering, and active suspension. Active suspension provides capabilities including changing vehicle ride height, traversing comparatively large obstacles, and controlling load on the wheels. All-wheel steering enables the vehicle to point arbitrarily while roving, e.g., to keep the solar array pointed at the sun while in motion. The offset steering combined with active suspension improves driving in soft soil. The rover's on-board software utilizes NASA's Core Flight Software, which is a reusable flight software environment. During 2015, we completed the initial rover software build, which provides low-level hardware interfaces, basic mobility control, waypoint driving, odometry, basic error checking, and camera services. Development of the prototype rover has enabled maturation of many of the subsystems to TRL 5. During the next year, we will conduct integrated testing of concepts of operation, navigation, and remote driving tools. In addition, we will perform environmental tests including radiation (avionics), thermal and thermal/vacuum (mechanisms), and gravity offload (mobility).} }