Actually, if you don't sell it for at least 1M$, you won't get any contract, it doesn't look serious enough. Terrestrial drones were being done during WWII, Russians were remote-controlling full-sized tanks in the 40s, these techs should be obvious by now.
I have been working for a defense project about instrumenting some armored vehicles with video cameras and monitors. The project was more than 10 years old when I arrived in it. I couldn't help but thinking "bring the prototype to any hackerspace and pay 20k of salary for two weeks of dev and you'll be done."
At that point you'll have one. Now try to make it it work through extreme weather - hot, cold, pouring rain, etc. Now make it reliable to shock so you aren't fixing thing every 50 miles or so. Ok, write the reference manuals so that 18yr old mechanics how to install, maintain, replace them. You've got some sharp mechanics there, but you have a few dumb ones too. The manual will involve breaking things down to a painful level. Setup logistics for contracts, replace/repair. Oh now setup a production line to make hundreds or thousands. And, by the way, that production line may or may get shut down after the first order. Or you may get another order for exactly the same thing two years later after the last one rolled off the line.
It shouldn't take 10 years, but it isn't a simple trip into a hackerspace either.
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.
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.
> 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.
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.
It seems like the truck used in this example costs around 300 usd. If I were a soldier, I think I would not wait for the government to commission a million dollar truck. I would get 3 of these for now.
That's a hobbyist RC car, meant for adults with money, not kids. I have a friend who has a similar model, and he spends time buying new parts and upgrading, like any other hobbyist. It has a gas motor and I suspect this one does as well-it goes as fast as their Humvee on the limiter. A cheap toy store model wouldn't last a week in those conditions and wouldn't hit the speed to make it effective.
I can't remember the exact quote, or even the source, but it was along the lines of "For engineers, the biggest [moral] issue with weapons development is that it is fun".
You can build some really neat things when you have a military R&D budget behind you. The downside is of course
that it actively or passively hurt people.
And then there's the whole calculus-of-death/unintended consequence thing, where in theory, a more accurate missile is better for everyone because it reduces collateral damage. But because it kills less innocents, there are fewer qualms about using it more often. This applies strongly to the current UAV trend - You can politically spin (or just bury in accounting) "Ooops, We lost a $xMM drone", versus actual pilots dying.
There's the old joke: a decent software engineer would never write a destroyLisbon() procedure - he would write a destroyCity() procedure and pass the city as an argument.
Yup. I am sure they pitch it as you can build something that saves lives. Little Bob can ride his bicycle safely because of your work. As opposed to you can build something that can kill the enemy in mass in seconds.
I have been working for a defense project about instrumenting some armored vehicles with video cameras and monitors. The project was more than 10 years old when I arrived in it. I couldn't help but thinking "bring the prototype to any hackerspace and pay 20k of salary for two weeks of dev and you'll be done."