Hacker News Reader

Comment by randomdata | Hacker News Reader

> these kinds of applications.

As in research projects, which this project expressly states that it is? What are those reasons? It seems like being able to test theories as quickly and cheaply as possible is the top priority. If Python, a general purpose OS, and a CAN-USB adapter is sufficient to conduct the research and satisfies those attributes, it seems like the perfectly logical way forward.

I understand why you would want to move to such systems you describe once your research has concluded and you are now building something for production, but that is not the intent of this project, at least at this stage. It specifically says so.

View on HN

> As in research projects, which this project expressly states that it is?

This is from comma.ai, who famously tested on public roads with a reporter in the car and very little prior testing ("the first time it worked was this morning").[1]

[1] http://www.bloomberg.com/features/2015-george-hotz-self-driv...

Why wouldn't you do the research on a platform that could actually be deployed? Build the core using the proper tools and techniques. Any bug in a system like this could be life threatening at worst. Wouldn't you want to use the research phase to help eliminate such bugs?

Unless you're not planning on ever releasing then a platform like this makes sense for strictly research, but Comma AI did plan on releasing their product until they got shut down.

Research implies that you don't know the outcome and are going to be throwing away everything that doesn't pan out. Without knowing the outcome, how can you really be sure of what you need? You might think you need a CPU-based system but learn that GPUs are necessary, for instance. If you can start with cheap off-the-shelf components, at least you don't have much to loose when it is time to throw it away. If you're spinning your own boards, or heavily tied to expensive development kits, that becomes much harder to swallow. Especially for a startup with limited resources.

> Wouldn't you want to use the research phase to help eliminate such bugs?

I wouldn't think so. Spending your time fixing bugs in something you realize could have been done better another way, which ends up getting thrown out, seems like a waste of time. The words research and development are often paired together because it is a two step process, where development comes after you have learned what can be done.

As an example of some requirements, any recursion is banned unless accompanied by a termination proof that keeps track of stack size. No calls to malloc() or free() are allowed, and so any library you might use that allocates memory is banned.

It's far easier to get the code working in something like Python, and then rewrite it in safety-critical C later. And the kinds of people who can write self-driving cars in Python are using very different skills than the kinds who can write safety-critical C, so it might not even be the same person.

Exactly; the delta from Python to C is smaller than the delta from C to "safety-critical real-time C". Might as well prototype and simulate in a higher-level language that's obviously not the final one, rather than writing in a language someone might mistake for production and trying to incrementally evolve it into a full safety-critical version.

Hmm. Clearly this code is miles away from MISRA compliance (although compliance doesn't mean that the software is any good)

Even so, sorry to say, the code is miles away from any decent software standard. It is almost exactly what you might call CRAP (classes really a procedure) and mixes responsibilities all over the shop. Little attempt is made to abstract behaviour, and there are differing units, and random multipliers all over the place. Using c++ and python, both of which are OO many classes of error could be avoided if any actual OO features were used, even if MISRA was not a target, sadly the code doesn't do that.

This has all the hallmarks of software that doesnt know if it's doing m/s or mph.

> once your research has concluded and you are now building something for production

I think the rub is that this code appears to be intended for "production" (or at least use on public roads), given the fact that it's published by a company that has tested its products on open roads?

It explicitly states: "THIS IS ALPHA QUALITY SOFTWARE FOR RESEARCH PURPOSES ONLY. THIS IS NOT A PRODUCT. YOU ARE RESPONSIBLE FOR COMPLYING WITH LOCAL LAWS AND REGULATIONS. NO WARRANTY EXPRESSED OR IMPLIED."

And yet comma ai were definitely testing their products on public roads, products which were presumably running this code.

This would certainly explain why they folded so quickly once the NHTSA started asking questions.

...Which is why it says "YOU ARE RESPONSIBLE FOR COMPLYING WITH LOCAL LAWS AND REGULATIONS".

Ah yes, laws are definitely the determinate for safety. This is why texting and driving is illegal everywhere.

Note: other comments in this thread indicate my assumption that comma ai was testing vehicles running this code was a bit hasty.

Does anything not have that warning (or similar) on it?

Reply on news.ycombinator.com