Space robot development at Seattle Space Week

When people think of space robots, they often think of rovers that operate on the surface of the Moon or other planets. However, many space robots are designed to operate in zero gravity while orbiting a celestial body, usually while attached to a spacecraft. This presents significant challenges compared with designing industrial robots, such as orbital motion, limited onboard computing, delayed communication, radiation effects, narrow margins for error, and limited testing environments.

In September, we attended “Houston, We Have Robots,” a panel on physical AI, sensing, and autonomy in space at AI House in Seattle. It was part of AI in Manufacturing: Space Edition, which Seattle Hardware Week hosted with LumaLogica, AI House, and Space Northwest during Seattle Space Week.

The panel discussed the challenges of developing and operating robots for zero-gravity environments, which made the concerns and challenges of our research robot seem trivial. For example, we were concerned about dealing with additional latency from off-board compute on the local network, or from wireless devices, such as speakers for text-to-speech output, because these issues can make robot behavior and communication seem even more unnatural.

The panelists:

Aaron Borger of Orbital Robotics, which builds robotic arms and autonomy software for capturing and servicing spacecraft.
Isar Mostafanezhad, Ph.D., founder and CEO of Nalu Scientific, which designs chips and data acquisition electronics for precise measurement.
Ben Jordan, P.E., of Fresh Consulting, which designs and builds custom robots and other physical products.

The Houston, We Have Robots panel.

Many of the attendees were involved in space industry startups in the Seattle area, but some were also looking for ways to adapt the techniques of this more rigorously challenged industry to their industrial, consumer, and educational robotics projects. The physical AI industry moves at an extremely fast pace in comparison to the hardware side of robotics, and especially space robotics. But as a result of its slower pace, the space robotics industry has some very reliable, thoroughly tested, and innovative solutions for all robotics applications.

The Space Needle and Olympic Sculpture Park seen from the venue.

This article covers what we learned about specific challenges: controlling a robotic arm mounted to a spacecraft, simulating and testing zero gravity on Earth, processing data onboard, and protecting electronics from radiation. It ends with how some of these approaches apply to our own robot project.

Spacecraft-mounted robots §

One of the most common form factors for space robots is a robotic arm mounted to a spacecraft. Calculating basic robotic movement for this setup in a space environment is far more complex and resource intensive than doing the same for industrial robots on Earth. Grasping another object in space adds even more challenges.

Industrial robot arms are typically anchored to a fixed or mobile surface without the constraints of a zero-gravity environment. An arm mounted to a spacecraft in zero gravity isn’t, so every movement of the arm also moves the spacecraft and changes its trajectory. The resulting shift can cause the arm to miss its target or even cause a collision, requiring more complex motion calculations and additional spacecraft thruster firings to compensate.

This type of robotic arm is often used to grasp other objects, such as satellites, whose mass, mass distribution, and surface friction may be unknown to the robot. These factors affect whether an attempt to grasp the target succeeds without missing or slipping. Cameras, other sensors, and rapid calculations are required to successfully grasp the target. There is no time to rely on communication with Earth and AI models in a data center for real-time adjustments, because the data transmission alone can take several seconds for a round trip.

The extreme orbital speeds and the relative velocities of the spacecraft and its target satellite are other important considerations in this scenario. The spacecraft and its target satellite move at a high orbital speed, but in nearly the same orbit. During the final approach, their speed relative to each other is very small. The small reaction forces created by the arm’s movement are substantial compared to the relative speed involved.

To handle these challenges, space robotics developers rely on a combination of software simulation, zero-gravity testing, and onboard processing integrated directly with the robot’s sensors.

Zero-gravity simulation and testing §

There are multiple types of zero-gravity labs that imitate the weightlessness of space; however, they are expensive and require lots of preparation. To compensate, robotics developers use physics-based software simulations to generate a wide range of conditions for training and testing robotics systems for use in space environments.

Furthermore, most zero-gravity labs can only approximate weightlessness without providing other characteristics encountered in space, so software simulations are required even with extensive testing in Earth-based labs.

The types of zero-gravity test labs available on Earth include:

Parabolic flights: an aircraft flies arcs that provide about 20 to 25 seconds of free fall each, repeated many times per flight. They’re used for short experiments and astronaut training.
Drop towers: a tower or vacuum shaft drops or launches a payload. NASA Glenn’s Zero Gravity Research Facility uses a drop tower that provides about 5 seconds of weightlessness per run, and the ZARM tower in Bremen provides up to about 9 seconds.
Air-bearing floors: a test vehicle floats on thin air cushions over an extremely flat floor, often polished granite. With almost no friction, the vehicle moves across the floor much like objects in orbit. A slight push or a reaching arm sends the vehicle drifting. Movement is limited to two dimensions.
Robotic hardware-in-the-loop (HIL) simulators: a robot arm moves satellite mockups or test hardware along paths that a software model calculates based on how the objects would move in orbit. NASA Goddard’s Robotic Operations Center uses industrial robots and space-motion simulation software for this kind of testing.
Gravity offload rigs: cables, counterweights, or active systems carry the weight of an object so it can move as if weightless.
Neutral buoyancy pools: large water tanks, such as NASA’s Neutral Buoyancy Laboratory, simulate some effects of weightlessness. This setup is mainly for astronaut training, because water drag distorts object movement.
Suborbital rockets: rockets that reach space but fall back to Earth instead of entering orbit. After the engine shuts off, the payload is in free fall for a few minutes, which is real microgravity rather than an approximation, but each flight costs far more than lab testing.

Onboard processing §

Test and simulation results train a space robot for the conditions that engineers expect, but the robot must also recognize and handle unexpected conditions. It has to make those decisions immediately, without sending raw sensor data to a central computer or to Earth and waiting for a response.

The largest delay is communication with Earth. In Earth orbit, a round trip through relay satellites and ground stations can take seconds. From the Moon, the signal alone takes about 2.6 seconds round trip, and from Mars it takes several minutes or more. Those figures don’t include the time human operators need to react or the time spent processing data on Earth.

To avoid these delays, space robots often process data next to their sensors. Processing near the sensors shortens the analog signal paths, which keeps the signals cleaner, and it means less data has to move through the robot. It also reduces the load on the robot’s main onboard computer and on the spacecraft’s communications link with Earth.

Processing next to the sensors reduces raw data before it reaches the main computer, but this can also prevent the robot from collecting important training data. These practices improve this setup:

Confirm a reading with a second sensor before acting on it, so one faulty reading doesn’t cause a wrong decision.
Record detailed data from around unusual events instead of discarding it, so engineers can analyze the data later and use it to improve the robot’s AI models.

One of the biggest challenges to using onboard processing with space robots is radiation. Integrating delicate computer hardware directly into a space robot exposes it to radiation that it wouldn’t encounter on Earth.

Radiation exposure §

Radiation exposure is a major design concern for space robots. The effects increase the level of protection components require, and they decrease the amount of time the robot can safely operate in the environment.

Radiation exposure can cause the following problems for robotics components:

Corrupted memory and processor states when a single high-energy particle strikes a chip.
Short circuits that can potentially destroy components when a single high-energy particle strikes a chip.
Pixel damage to imaging sensors, and distorted images when high-energy particles strike or pass through a sensor.
Gradual physical degradation as exposure builds up over time.

Sources of radiation §

Common sources of radiation exposure include:

Charged particles trapped in Earth’s radiation belts.
Particle bursts from the Sun.
Cosmic rays from outside the solar system.

When operating in low Earth orbit, Earth’s magnetic field provides partial protection against some forms of radiation. Radiation exposure is much higher in geostationary orbit and in orbit around the Moon or Mars.

Protection against radiation §

These are some common methods used to protect robotic electronics from radiation in space:

Space-qualified parts: components that are tested and certified to survive radiation, vacuum, and launch. This includes radiation-hardened processors.
Radiation testing: engineers expose chips to particle beams and other radiation sources on Earth to identify their limits.
Redundancy: critical calculations run on three copies of the same hardware, and the system uses the most frequent answer.
Error-correcting memory: memory that detects and fixes corrupted data. Systems can also avoid using degraded memory after it is detected.
Latch-up protection: circuits that cut power when a particle strike causes a short circuit, before the short destroys the component.
Safe restarts: ensuring the robot is in a safe state if the system needs to restart while a task is running.
Shielding: material around the electronics blocks some radiation, but only a limited amount is used because it adds mass.

Radiation-hardened processors are the most protected space-qualified processors available, but they are significantly slower than commercial processors, which limits their ability to run more advanced AI models. For missions in low Earth orbit, it is common to combine some commercial parts with a limited set of radiation protections.

Implications for our robot §

Our AI-enabled robot project doesn’t face the same challenges as space robots, but some of the same approaches can help optimize our design.

One of the most obvious optimizations is to offload compute from the D-Robotics RDK S100P, our robot’s main onboard computer, by using sensors that include their own integrated processing. The RDK S100P follows this idea inside a single chip. Alongside its main processor and AI accelerator, it has a separate real-time processor, called a microcontroller unit (MCU), dedicated to motion control. As a result, servo timing doesn’t compete with the robot’s AI workloads.

The SLAMTEC Aurora S that we set up in phase 2 of the project is a closer example of the approach. The Aurora S has its own AI processor and runs its visual SLAM pipeline on the device, which frees a significant amount of resources on the RDK. This benefit is extremely important if the RDK is to run any local AI models.

Because radiation-hardened processors are much slower than commercial chips, space robots have to run efficient AI models on limited hardware. The same techniques can help any physical AI project with a tight budget or limited power.

If you work on robotics or physical AI, we’d like to hear what you’re building.