Autonomous Cars

Autonomous cars are a combination of highly advanced sensors and an operating system designed to handle a large level of data input, the ability to fully process it, and execute the correct actions to be taken. The combination of these technologies is broken into five categories of autonomy as defined by the NHTSA. These run from L0, where the driver has complete control over the car, up to L4, a fully self driving car that requires no driver input.

When manufacturers developed cruise control, a system that monitors and automatically adjusts the throttle position, they had achieved a level of L1 autonomy. With the introduction of Lane Keeping technology, utilizing radar systems to detect lane markings and applying a counter-steering force when crossed, the simultaneous use of both of these technologies raises the level to L2 autonomy.

A number of manufacturers are currently working on implementing L3 autonomous cars, which involves the car maintaining all safety-critical functions requiring limited driver intervention. This requires a system to control and adjust the throttle and the steering shaft based on analyzing the environment while utilizing a location and mapping service to arrive at a destination.

Overlapping sensors are required to capture all the environment data. Sensors need to detect environment changes up to 250 or more meters away and with finer detail at fewer than 80 meters.  Different technologies are being assessed and each manufacturer is using a combination of very accurate LiDAR systems, multiple ultrasound radars, lasers, and cameras.  Each sensor system has a specific range of tasks that they excel at, from processing camera images to detect traffic signs to LiDAR systems generating a 3D environment.

All this data requires a powerful computer to process it. NVIDIA has announced their Tegra K1 processor will be used in Audi’s autonomous car, a 192-core GPU similar to processors used in super computers. Each manufacturer is also utilizing different operating systems customized for autonomous driving (see chart below).

Autonomous cars are predicted to reduce 90% of traffic accidents, improve fuel efficiency, reduce pollution, and provide mobility to non-drivers. Enterprises that currently provide transportation and related services must be prepared to pivot, i.e. taxies services, freight trucks, and delivery services. Other enterprises must be prepared to take advantage of utilizing fully automated transportation services and the technology that comprises them.

Future infrastructure must be carefully planned out to prevent it becoming obsolete and incompatible with new traffic systems. Car designs will be changing as drivers no longer are required to maintain vigilance on road, allowing the creation of mobile office spaces. Consumer hardware and software should begin investigating designs now to position themselves to become a technology leader within the developing space.

Manufacture Model Software Provider OS
Mercedes-Benz S 500 Nokia Xubuntu
Toyota Prius Google Ubuntu
Renault Next Two Google Android
Nissan Leaf Microsoft Windows Embedded Automotive
Company Role Contact
BMW Project Manager Dr. Werner Huber
Google Google Fellow Sebastian Thrun
Audi Project Manager Dr. Bjorn Giesler
General Motors Innovation Program Manager Jeremy Salinger

BattleHack Boston

battlehack-logo

This past weekend involved PayPal’s BattleHack being run from IsoBar upstairs in South Station in Boston! Having not even heard of BattleHack previously, I was in for a surprise with how this hackathon was to be managed.

The event was a 24 hour hackathon running from 1pm Saturday till 1pm Sunday with the aim of building an application that would benefit the community, and to be in the running for the prizes it also needed to integrate PayPal.

Some things really made this hackathon stand out:

food

 

The Food

I feel obliged to post this first as it was excellent! A constant stream of new items would appear throughout the hackathon – breakfast, lunch, and dinner. Beers and waffles. Crazy caffeinated items at around 2am.

supporters

Development Support

An awesome aspect of this hackathon was the involvement of both PayPal and any of the sponsors. There was always someone there from the company to help you if you ran into issues integrating their code into your application. Rather then pulling your hair out reading an API for the first time, these guys vastly simplified the process. I’d love to see more hackathons taking this approach in future.

massages

Non HACK STUFF

How to describe this.. everything else falls into this giant category – from having massages (!) to an area with inflatable chairs to napping to Justin Woo and his amazing ability to keep people in the game! Justin was constantly wandering the floor and coming up with things to keep people awake and energized.

techsupportOur Hack

Given all this support, myself and Rahul hacked our way around Android and Ruby to provide an app we called Empowered Locals. The idea was to provide an application that someone walking around their local neighborhood could create an issue and try and raise some funds from the community to fix it.

With the two of us, I have to admit we got a lot of coding done! There were times we were flying high and times where there may be marks left from banging heads against tables – having a test fail constantly for a good half hour or more before realizing we were not passing the data correctly at all…

PayPal integration was very nice since they provided a sample application to base it off. While the plan at the time was to simple move the money into a separate PayPal account, I see now we could have created an agreement with the donors so that when someone finally steps forward to announce the issue has been fixed, then the money is transferred. Certainly more reading up on the PayPal use cases is required!

trophy

The Winners

It was great to see how polished some of the applications were after only 24 hours of coding! I’ll be very interested in seeing if any of the applications continue on to be fully fledged apps that go into use.

The winners were:

1. BUtiful Bois – Two BU students who wrote a mobile application that provides security measures while walking home at night. This included alerting friends if not home within 30 minutes, providing the latest information from local police. Sadly our demo was right after these guys so I was not paying as much attention!

2. Cannery – A group who melded hardware and software together for an important community project. They used android and several shields to graph out data sets in Boston. These would include temperature, noise level etc.

3. Battlestars – A very organized group that developed an app for used with charity runs, whereby donors got alerted as the person runs the course passing set milestones.

end

In summary this was a blast and hope more people sign up to attend this series!

 

The Joke that is UAT

clown shoes

 

One of the final stages of development tends to be UAT – User Acceptance Testing, where end users are presented with the final product and asked to test and sign off on the product.

In a recent session it struck me how lubricious it was to combine acceptance testing with system testing. Expecting an end user to instantly identify not just UX problems, but formula problems in a very fast half hour meeting. Without being intimately familiar with the underlying data how could they spot all issues – spotting 5.0% when it should be 7.4%.

System testing is taken care of by Unit Tests and ATDD in the hopes that any issues with the underlying logic will be exposed and corrected. These should be based on the requirements that the team received, and these should have been signed off by the business sponsor.

tinkerbell

Course what we tend to find is that users submit requests that are more similar to wish lists than well defined requirements. Now as developers work on these requirements, we start creating unit tests based on our interpretation of the requirements. If there is disagreement on the team about the interpretation, then we seek the business user to confirm.

Yet if there is no disagreement on the interpretation then the formulas get implemented and the first time the user gets a chance to spot the issue is during UAT. Now we have a bug in the system that got full sign off from everyone and will remain in the system until someone notices the difference.

Computer Bug

So now the question is how could we have seen this coming and better prepared to prevent last minute changes or introducing bugs…

 

The old encapsulation diet is back in fashion

Stack of hats

A major coding principle deals with encapsulation – the basic idea is you want two services to chat with the minimum number of dependencies, this is known as loose coupling.

A way to think of this is at a restaurant – the waitress takes your order and she needs to know order number and the customers, she hands off the order to the cook who prepares the meal. The cook does not need to know anything about the customers (ok, so many allergies, special requests… :)). This information, the customers, is encapsulated by the waitress!

Each level of the networking protocol stack encapsulate the data of the layers above it. We can look at the four layer network stack:

UDP_encapsulation

 

This provides a huge benefit in terms of design, allowing each layer to be programmed separately. When a message is received by a layer it is broken up into two sections – the header and the payload.

The payload contains all the data for the layers above our layer, but the header is constructed by the corresponding layer on the sender’s machine. The header lays out the information that is used by the layer to take whatever action is required. For instance the IP layer contains the destination IP address, or the transport layer stipulating the port.

We do not need to know about the logic in the layers above and below – if data is coming from above, we simply add it all into the payload section. This loose coupling means network stack can be constructed by separately developed layers, and upgraded independently of everything else.

Think about when you have your laptop – if you have a network cable plugged in, then the physical layer uses the correct 802.3 network protocol, while if it is using a wireless card then it will implement the 802.11x protocol. The layers above do not need to know how the data is being transmitted, as such when another method becomes available then only the physical layer needs to be upgraded.

802.11 network stack

 

So, the stack is all about encapsulation!