Q&A: Seek(er) and NASA shall find

 
Roundup Reads: How was the concept of Seeker dreamed up?
Banker: The idea of external, free-flying robotic inspectors has been around since the early ’90s.  A proof of concept called AERCam Sprint [Autonomous Extravehicular Activity Robotic Camera Sprint] even flew aboard STS-87, but follow-on projects never made it to flight.

The concept of Seeker came about two years ago when Scott Askew, Seeker project manager, and Chris Radke, Seeker’s propulsion lead, built a proof-of-concept using commercial, off-the-shelf CubeSat components. This led to the team proposing an X-Project to the International Space Station Program in spring 2017. 

After a summer of iterating on the mission concept, the project received a green light to operate off the Cygnus station cargo resupply vehicle after it completes its primary mission—and just before it self-disposes into the atmosphere.

From left, Avionics Lead Keith Chambles and Software Engineer Charles Taylor perform final checkouts on Seeker's Guidance, Navigation and Control sensor package. Image Credit: NASA/James Blair
 
Roundup Reads: What will be Seeker’s main job in space?
Banker: Our main objectives for this mission are to demonstrate that we can operate around another spacecraft safely and demonstrate controllability and imaging performance. This will help build confidence in the design, which will enable us to take on more aggressive tasks in a future flight leading up to the first operation around a human spacecraft. Because of this, our concept of operations is pretty simple and should take about an hour to perform. 

The first thing we will do is power up inside of the NanoRacks deployer so that we can check out the system and zero our Guidance, Navigation and Control sensors. Once that’s done, NanoRacks will eject us at approximately 0.5 meters per second. As we float away from Cygnus, our cold-gas propulsion system will activate, allowing the flight computers to start firing thrusters to point Seeker at Cygnus. This allows our onboard sensors to determine our relative position and attitude, or pose. Once we get 30 meters from Cygnus, we’ll stop and take several high-resolution images of the craft. These images will demonstrate the vehicle’s core inspection capabilities. 

Next, we’ll demonstrate three degrees of freedom in translation by flying down and over, a maneuver called “the boomerang,” followed by flying toward and away from Cygnus. Seeker will then exercise its roll, pitch and yaw attitude maneuvers. We’ll also take on several stretch objectives, such as demonstrating Seeker’s ability to recognize and obey a keep-out zone, its response to loss of communication and some advanced attitude maneuvers. Once complete—or whenever we run out of battery or propellant—we’ll command the vehicle to fly away in a disposal trajectory.

Because we don’t have enough data bandwidth to tele-operate (fly by joystick) Seeker from the ground, we’ve pre-programmed these maneuvers. Seeker will perform a few maneuvers and then go into a holding position so that we can look at data on the ground. If everything looks good, we’ll command Seeker to perform the next set of maneuvers, and so on.

Our second piece of hardware, Kenobi, stays inside the NanoRacks deployer during the mission. Kenobi’s job is to act as a translator between Cygnus and Seeker and to store all of Seeker’s data. During the seven days following Seeker’s mission, Kenobi will periodically turn on and transfer all of the data we gather to Cygnus for transfer to the ground over high-speed ground data transmissions. 
 
Roundup Reads: As an initial X project, how does Seeker demonstrate that NASA’s Johnson Space Center is moving toward a more agile, quick-turnaround-type of development for space hardware?
Banker: When you think about it, we are essentially building an entire spacecraft (sans life support) in about a year. 

In order to make that kind of tight delivery schedule, the team had to be able to communicate quickly and efficiently. Having a team spread out across the center—sitting at their desks—wouldn’t cut it, so we implemented a “bunker” approach, where we get the entire team in one room right next to the hardware. In Building 16, we took over a room and divided it in half. On one side, we had about a dozen desks where you could plug a laptop into a computer dock. Since we didn’t have desk assignments, people could flow in and out as schedules allowed. We also had a small conference room for break-out meetings. 

On the other side of the room, we had all of our software-development stations, electronic workstations and assembly benches, as well as a small vacuum chamber and thermal chamber. This is where we did all of the development work and, eventually, the flight build. The beauty of this space is that since all of the subsystems are close to each other, integration occurs naturally, and problems can be addressed immediately.

Another aspect we focused on was decision velocity. We knew, early on, we’d be faced with a lot of decisions where we didn’t have the time or resources to get the data we’d like to have to make a choice. Either way it went, we knew we’d be accepting some risk due to the inherent unknowns. In these situations, Scott [Askew] and I focused on empowering the team to make the best decision they could given the information they had—and let them know that we had their backs no matter how it turned out. Oftentimes, decisions involved multiple technical disciplines, each with their own point of view. When that happened, we’d get all the stakeholders in a room and take as long as we needed to talk it out. 

The key is that whenever we made a decision, we knew there was a chance that a wrong decision could make it harder for us to succeed … but the one guaranteed way to fail was burn up all our schedule by not making a decision when it needed to be made. Tomorrow, we can fix any mistake we make today—but we can’t fix it if we don’t make the decision that gets us to tomorrow.
 
Roundup Reads: What do you think will be Seeker’s biggest impact once it shows what it can do in low-Earth orbit?
Banker: In addition to developing a robotic inspection capability that can be used throughout human space exploration, one of the things we’re trying to do for the CubeSat community is develop the “rules of the road” for operating small robotic spacecraft around human spacecraft. We here in Johnson’s Engineer Directorate are uniquely positioned to be the pioneers in this area, as we routinely work closely with the safety community to set the guidelines to ensure safe human spaceflight operations. This could open up new avenues for technology demonstration and scientific research, increasing the utilization of orbiting platforms such as space station or Gateway.


Structural Engineer Ross Patterson, at left, and Communications Engineer Paul Hamilton perform inspections on Seeker pin preparation for delivery to NanoRacks for integration. Image Credit: NASA/James Blair
 
Roundup Reads: Are there plans for Seeker, or a similar type of robot, to be used with Gateway and perhaps even beyond?
Banker: Although we’re still in the early stages of developing the technology, we definitely see something like Seeker providing a lot of capabilities to Gateway and, eventually, a Mars transit vehicle. Vehicles such as these are going to need to last for a long time on orbit. Just like your car needs routine inspection to catch issues early, so will these spacecraft.

We envision Seeker autonomously deploying and performing routine inspection of the spacecraft, then beaming all the gathered data back to Earth for engineers to evaluate.
 

We think of Seeker as a “cell phone” technology. Everyone got along just fine without a cell phone, but now we can’t imagine life without one. Similarly, human spaceflight has gotten along pretty well without this type of capability, but we think that once it’s out there and we show what we can do, people will be excited to see how it can help make their spacecraft safer. Fifteen years from now, we’ll wonder how we did human space travel without Seeker.