Archer e-car as a platform

As we earlier announced Archer has decided to purchase and use the electric Nissan Leaf vehicle to use it as a basis and platform for development and testing automotive prototypes.

This will allow us not to stay still in a stream of software and hardware innovations, to keep monitoring the pulse of industry trends and needs.

Analysing our clients need, communicating through the conferences and meetups we collect and gather our understanding of the automotive software trends and concepts that help us work efficiently.

According to this knowledge and understanding we indicate the solutions and applications that will fit these trends and needs. Working on them we also want to try out as many new and sexy technologies – software and hardware that sometimes are not available for applying to the live projects we do.

Selecting the specific vehicle to become our prototyping platform, we defined the principle – we need a car that is smart, but not too much.

There is no big sense in having on board the Tesla that already can do and have all the tricks and hacks. What we needed is a car that does support the commonly used data transferring standards and protocols and that have the infrastructure savvy and modern enough for us to extend it and use for our experiments.

Having the vehicle to be electric also was an important criteria as first – it’s green and second – it gives the ability to play with battery life and it’s consumption. After analysis of the market options the Leaf seemed the best match for us.

It does support the ODB II protocol and has basic set of sensors, but not too wide (which opens for us a fields for adding our own sensor and it’s analysis logic). The price was also just about right for the experiment.

In terms of technology – the capabilities that car gives are rather wide.

The first and straightforward development approach that we will use is the reading of the data that we can collect from the vehicle subsystems. We will integrate with reading the data from connected OBD II device and process it.

The subset of the data is not super variative, but it is good for the start: we can work with the current vehicle speed and acceleration parameters, status of the battery, it’s low level parameters like voltage, temperature, etc (which together can give after certain processing an idea of current charge consumption dynamics and overall long term battery status). Of the data that is straightforward to collect – this would be it.

But even having only these values we can measure for example the distance available with current discharging dynamics and make the smart routing to various goals based on it.

The next step that we now are working on is extending the available sensors set to read the data that will allow us to analyze the driving quality and overall driver behaviour.

Accelerometer, GPS, speed and acceleration data, wheel turning angles and dynamics, face and eyes recognition attempts – all these readings can give us a good idea on how aggressively the driver manages the speeding, taking turns, changing the lanes, who is currently driving and weather he is attentive to the road or even getting asleep.

Currently we already have the app that based on rather simple algorithms can grant driver with the score for his failures and safe driving. Now we’ll integrate it with the data that gives vehicle and our sensors.

But the most exciting step on this road is the analysis of the received data snapshots. Using our expertise in machine learning and considering the subsets of the data collected through the time as a input data we can try indicating patterns and further runtime comparison of these patterns for the things like forecasting the potential incidents or recognizing the drives personality or him getting asleep during driving.

Source: Archer