[idealstingray]

As a robotics engineer, I'm surprised how controversial "hardware can't remote" is turning out to be. Sure, some things can be done fully in simulation or by mailing everyone on the perception team a bunch of sensors. However, existing/popular simulators aren't that good at simulating things like odometry error, and if you're trying to do any object manipulation they're not great at anything beyond "before I run this on the robot, please make sure I'm not going to destroy things" (my understanding is that accurately simulating manipulation is hard because of the various frictional forces involved). And, of course, giving several employees a large, expensive KUKA arm to keep in their house or apartment is impractical on many levels. If people are running code remotely on a physical robot that's in the office, at least one person has to be in the office to keep an eye on it (for safety, and freeing the robot if it gets stuck). This is also not even getting into remote embedded, electrical, or mechanical work -- everything I've listed would affect a garden-variety software developer. So, yeah, I'll endorse "hardware can't remote", and will admit to some frustration with non-hardware-adjacent software engineers, who have a tendency to make over-broad generalizations about the feasibility of remote work.

[detaro]

Always the problem with absolutes. It highly depends on the project and what you look at. I wouldn't sign "hardware can never be remote", but I also think "hardware always can be done remotely" is very wrong. And that leaves out the massive space of hybrid models.

I.e. I do know of embedded projects where the hardware designer works out of his living room and the software developers are spread across Europe. Does that count? Or doesn't it because the PCB fab and assembly service obviously works out of a factory? It certainly is remote as far as the developers are concerned - and it wouldn't work as well if the device in question didn't easily fit on a desk (although you can do a lot with only remote access to hardware too in later stages).

Somehow embedded developers often tend to (understandably) bemoan that the overall "software community" doesn't understand their work, while at the same time falling into the same trap regarding the breadth of what embedded development is today vs their individual experience.

[FlyingSnake]

Touché. People on HN are sometimes really flippant about the lesser discussed segments of software industry.

We had to run the hardware lab with strict quotas in the middle of the raging pandemic, because the critical equipment can't be moved. I had to personally go to office several times to use the jigs to use special test devices, I can't even imagine our remote developers in Poland/Ukraine traveling to Berlin just to work on the experimental devices.

Also a lot of people are overlooking the compliance issue. Several of the projects under TISAX need a sealed working environment where access is restricted even for the same company people. Good luck porting that compliance to a home office.

[hinkley]

We had enough problems with "hardware can't remote" with server equipment that they made systems to control them. Those systems are useful even if you're in the same building and just don't want to go hang out in the cold, loud server room while you figure out the problem, and everyone wonders if you're even working today (since they can't see you).

Or you might not even have access to that room.

We just haven't had much motivation to do this for a more general class of hardware, and there probably haven't been enough non-pandemic motivators to build such things, and it would be pretty macabre to build a system just in case there's another pandemic, or to buy the thing if it existed.

Time sharing hardware with someone on the other side of the planet, for instance, might introduce too much delay for a Big Red Button. Apparently it's about .25 seconds if you're in the room. You can do a lot more damage in another 200 ms, and packet loss could make that delay bigger.

[detaro]

Testing is one field where you already might see fairly automated unsupervised/remote setups that are not that difficult to use for remote development too, although surprisingly often testing is still done manually.

[AstralStorm]

We had some experience with this, and the device under test or even testing harness can fail, so you need a local operator to fix things anyway.

It is more feasible to ensure no such failures the simpler the device is, e.g. with a good hardware watchdog setup. We did it with a rather complex stack.

[detaro]

Of course, you also need someone and somewhere to set it up in the first place after all, but it makes a big difference between "you need the entire team in one place" vs "you need a place that has a test engineer or one member of the team available/on-call". (To continue the parallel from /u/hinkleys comment, lights-out management is useful even though the server still can't swap a broken disk itself)

Seeing that now with Covid at customer sites: only 1-2 people from a larger group in the office, who if needed can go poke devices, while the majority works remotely (which often includes contractors that otherwise would be in hotels etc). Generally not optimal, since many don't have the amount of automation one would prefer, but workable and with room for improvement.

[flyinglizard]

My team deployed lots of stuff on Kuka robots from across the world using a VPN with remote pendant software and few PTZ cameras around the robotic cell. It can be done.

The thing though is you still need physical space for integration but a lot of the developed can be fully remote.

[LeifCarrotson]

I've developed a lot of stuff for Fanucs with a similar setup, minus the cameras. A relatively small amount of the work is actually getting in the cell with the pendant and teaching the position registers. A large amount is structuring your programs, writing interprocess communication, setting up inter-machine communication, fault handling, zone exclusions, process monitoring, manual overrides, dry cycle controls, etc. etc. etc.

First, write the programs that set flags, work with IO, branch and jump, fault and recover, and so on. Stick in comments as appropriate that read eg. "Now move from PR1:Home to PR17:Infeed Magazine 2, approaching with the offsets from PR101".

We typically implement some sort of 'dry cycle' mode, where we don't actually check for part presence/energize vacuum generators/spool out wire/spray paint, so you can check for intermittent mechanical problems, loose wires or fasteners, etc. When starting development in this way, it's a sort of anhydrous or dessicated cycle, without any motion whatsoever!

When the robots finally arrive or when you actually go into the shop, only then should you need to move stuff. A benefit is also that you should have a much better idea of precisely where and in what sequence you need to move it, not just the RFQ's description of "the robot does some stuff and assembles the part".