Sort of mini-fridge sized. They take over attitude control and propulsion for satellites that are low on fuel.

"Since the mission is designed to attach one and then leave to go to another satellite that needs servicing?"

Yes.

We use pretty standard BLDCs.

Thanks! There isn't a paper yet, but I'm working on one; I hope it will be presented at the upcoming iSAIRAS/iSpaRo conference in Cologne.

It's very likely that a spacecraft similar to MRV/RSGS could do a life extension mission on Hubble. But, unfortunately, Hubble is in a very different orbit than MRV/RSGS is, so we wouldn't be able to reach it.

"Does the satellite servicer need its targets to be constructed to some common standards, or is the new capability now leading to common standards?"

We can do life extension missions on client spacecraft that were not designed to be robotically compatible. That's actually SpaceLogistic's primary business case.

The question of standards in the spacecraft industry is a huge question. It's being worked... by a lot of people, cue the obligatory XKCD reference.

"Was it built with a method for itself accepting refueling?"

We are, in fact, refuelable.

"It seems to me this device would lead to a revision in satellite reliability design and life calculations."

We hope so! Spacecraft are expensive in large part because they have to be designed to be incredibly reliable. The example I use is cars. If you had to design a car that could go for half a million miles without ever having a part replaced, you could. It would just cost a billion dollars. But that's how we design spacecraft today. IF we can create a "mechanic safety net", we might be able to bring the cost down significantly.

It's almost impossibly hard to return things to earth from GEO. Robert Heinlein famously wrote that "a circular orbit is halfway to anywhere", which means that the most energetically difficult part of a mission to the Andromeda Galaxy is getting out of earth's gravity well.

To get back into earth's gravity well from a circular orbit requires similar amounts of fuel. Getting things back to earth from low earth orbit is doable, if you have a heat shield, because you only have to dump enough velocity to start hitting the atmosphere, and atmospheric drag does the rest of the work.

But that doesn't work at GEO, because you're so high (22,000 miles as opposed to ~1,000 miles for LEO). It's very hard to get enough delta-V (read as "change in velocity", which is basically the amount of fuel you need per unit mass) -- you'd need something with as much fuel as the upper stage of the rocket you were launched on, plus you'd need a heat shield. Alternatively you could use electric propulsion, which takes a lot less fuel, but would also take, literally, a couple of years, during which time you're a hazard to navigation to anything in a lower orbit. Plus, electric thrusters of the size you'd need to do this aren't cheap either.

So we basically never do that. If you need to dispose of a derelict satellite at that altitude, it turns out to be much easier to raise its orbit by a few thousand kilometers.

So, nobody will be recycling space debris that lives at GEO any time soon, unless someone figures out how to do it in situ.

I can only provide answers to technical or programmatic questions that have already been "approved for public release" by DARPA and NRL. We've done a number of publicly released presentations over the years, so there is a fair amount of that information in the public domain, but things like the exact algorithms we use for IK or controls, or whatever, hasn't been released yet. I also can't speak about anything that is Northup-Grumman's or SpaceLogistics' intellectual property or is business sensitive, so I can't say which client satellites we'll be servicing.

I'm very hopeful that I'll get a strong technical paper through public release by the end of the year, ant at that point I could provide more detailed technical answers to things a HN audience would be interested in.

Oh gosh.

I grew up in the middle of nowhere Virginia. Like many of you I was a nerd, and I had no outlet for that nerd-dom until I spent all summer working for money to buy a C64. I taught myself assembly, and was a high school intern at NASA Langley where I learned about parallel processing, was introduced to the idea that people would actually pay you money to program computers, and had a tour of their space robotics lab.

When I went to college the guy two doors down from me in the dorm decided he wanted to build a robot, and he recruited me because I knew how to code. We spent freshman year working on a six-legged frame walker which we dreamed would explore Mars someday (this was in the late 1980s, long before the first Mars rover). It didn't work for crap -- the late 1980s were a disaster for makers, we had to source everything from the hardware store or Radio Shack. It was also the most amazing thing I'd ever done, and from then on I was an aspiring space roboticist.

I managed to not fail out, but it was close.

I went to grad school at the University of Maryland's Space Systems Lab under Dave Akin ("Akin's Laws of Spacecraft Design"), where I learned control theory and a ton of hands-on skills and got to scuba dive supporting the development of Ranger, which could have been the first US satellite servicer except we could never find a launch for it. I graduated with a PhD in aerospace engineering in 2003, and got hired by NRL, where I worked on RSGS.

Yes, China demonstrated this capability a couple year ago with towing a geo sat to a different orbit. It only makes sense to go tit-for-tat on these capabilities for servicing and the unspoken offensive ability.

https://spacenews.com/chinas-orbital-maneuvers-blur-the-line...

I would think there are much less expensive and more rapid methods of "on-orbit disassembly" than a system like this?

> on-orbit disassembly of a hostile nation's satellite?

Too complicated for disassembly. But totally valid for modification.

Absolutely, although it's a different ball of wax if you're trying to do RPO of this complexity with an adversarial body.

It’s all custom flight code. The only software packages we use are basic matrix-vector libraries. Hopefully there will be a paper describing the dynamics/kinematics/controls algorithms soon.

The RPO and docking are autonomous specifically because it's hard to deal with the latency.

Note that the algorithm stack for almost any spacecraft cannot rely on modern compute. Single-core sub-1 GHz processors are the standard. Very few GPUs have ever been in space, in any capacity, and none that I know of in a mission-critical role.