Hacker News Reader

Comment by RomP | Hacker News Reader

Some of the things you're listing are must-haves (secure channel), but most are not. If increasing reliability and versatility makes the drone last 10 times longer and costs 10 times more -- it's not worth it in the long run: it's goal to trigger the first IED it can find, anyway. Even if it's not, it still would be cheaper and easier to buy 10 drones or make them modular enough so anybody with some X-Box experience can snap a new one together in the field. Manuals? -- nah, see the X-Box thing above. Besides, who reads RC cars' manuals? Replace/repair? -- a dumpster full of modular parts is lightyears ahead of any repair technician in the field. Production lines? -- there already exist production lines for RC cars, aren't they?

To put it in the familiar context: what you're describing (and what DoD is used to) is a mainfraime. These guys just made a PC.

View on HN

I'm no military historian, but there are terrible failure stories for products pushed out before they're ready to the frontlines too. Beauacracy is a waste, but some of those steps seen as wasteful in the DoD procurement process are "scar tissue" from where things went wrong either in the battlefield or, as often, protection against incapable, or worse, fraudulent contractors.

You're right, my post wasn't a list of requirements, just an illustration of some of the things one might end up having to care about when packaging up a military product used in dangerous situations. There's a balance to be made, it should be made on a case by case basis.

some of those steps seen as wasteful in the DoD procurement process are "scar tissue" from where things went wrong either in the battlefield

This is precisely part of the mechanism that causes every military to be well prepared for the previous war but unprepared for the current one.

I propose greater emphasis actual feedback mechanisms based on experience in the field. These can be made to work on timescales of months or weeks. When bureaucracy comes into things, iteration timescales can stretch to years and change can become generational.

The path you mention exists, but not every program is fast tracked - nor should they all be. If you go too fast and mess up, soldiers can die. If you go too slow and mess up, same result.

I get frustrated too at too-slow, too-big companies running projects with billion dollar price tags resulting in no workable product, but I'm not as sure that the solutions are simple. I am sure that without constant oversight from within and without it could be much worse.

http://en.wikipedia.org/wiki/OODA_loop

> If increasing reliability and versatility makes the drone last 10 times longer and costs 10 times more -- it's not worth it in the long run: it's goal to trigger the first IED it can find, anyway.

Google's approach to building server farms was likewise to buy hardware that was ultra-cheap because it had failed to meet manufacturing specs. Google expected a certain percentage of hard disks, etc., to fail, and simply swapped them out when they did. That resulted in a significantly lower TCO. (So says Steven Levy in in his recent book In the Plex.)

While this is a legit perspective, there is a meaningful difference in that Google can throw out their failed hardware without any real risk of having it return to haunt them, but broken toy trucks means either handing materiel to the enemy or having extra useless weight to carry around.

You might be able to tweak specifics to account for this, but you also might not.

The solution is to have force redundancy and to make each individual element completely disposable (and detonatable).

(and detonatable)

No way terrorist types could misuse that one.

No, I mean if the gear can't be recovered you tell it to self-destruct.

Having lessened reliability is ok until the 2 that fail are the 2 you had in your truck as you're driving down a hostile road. Or if they won't work in the rain, that's ok until you have to go on patrol in the rain. Or if they won't work in harsh desert conditions... oh, wait.

It's similar to saying that having expendable bullets and grenades is OK until you use the last one while still on patrol. Solution: preparing for it by taking more. Knowing that they're designed to fail/be repaired easily changes the approach. The argument I'm trying to make is that it would be cheaper/lighter/more_versatile to get many expandable droids than to get one robust and universal.

Also, highly-adapted droid != highly-adaptable droid. There is no need for an amphibious droid in Afghanistan, just like one doesn't use the same apparel in all climate zones. As long as interface/principles are the same (like a PC), various versions of it can be used in (almost) any environment without extensive re-training.

While I see where that makes sense, the phrase "The perfect is the enemy of the good" comes to mind. The soldier in the field would probably rather have something like this instead of nothing at all or worse, wait (and die) while something "perfect" is developed.

On the bright side, at least they weren't forbidden from using there own solution.

Actually I was very surprised to discover that security was not taken into consideration in the main protocol used by drones operators. There has been stories about Iraq US drones sending or receiving some data unencrypted.

I am not allowed to comment about the specific project I have worked on, but I can tell you that a trip to the hackerspace would have resulted in a better product in that respect too.

I wish I were free to comment on this one too.

Reply on news.ycombinator.com