Data logging and driver information display - Android App offer

Hi, I’ve been a lurker here for a while, first time posting. I’m Rowan Griffin from the JLR Driven team.
Also, essay alert!

Since the start of the season we’ve been working on a new electronics system and driver information display for our cars using an Arduino on the vehicle for sensors and motor control with a Bluetooth link to an Android phone for the driver display.

We started this project hoping that we could share the Android app with any other teams that would be interested, enabling a useful driver information display and data logging from a relatively simple and cheap Arduino and Bluetooth setup on any car. This is primarily a speculative post to see if there is interest in this - We know many teams have very well set up data logging etc, but we're also aware it's an area some teams struggle with and this app may help!

The app itself uses the phone’s GPS to track laps and give approximate lap times, as well as a map display to the driver showing a trail that the car has followed. Other views show available sensor data to the driver. The data displayed is dependent on what is being provided by the Arduino, but provisions for:
> Throttle position
> Voltage
> Current
> Temperature (intended as motor temp)
> Motor RPM
> Vehicle speed (calculated on the Arduino from wheel RPM & diameter)

These variables are logged in a .CSV file every 250ms on the Android device, as well as GPS position and the UTC timestamp.

The app should work on any Android phone running Lollipop or higher (5.1+) but we’ve only tested it on limited handsets so far (LG G3 and Nexus 5). The software isn't quite finalised yet, but there's a link to a development version below if anyone fancies taking a peek. We are (hopefully!) going to be running this on at least one of our cars for the second half of this season if anyone wants to take a look at a race.

Screenshots:

Map View:
image

6 Variable View:
image

4 Variable View:
image

Lap Breakdown View: (Will show a list of laps - hard to simulate stuck at a desk ;) )
image

6 Variable view with a load of nonsense randomised data being fed through it:
image

We have no user manual as such yet, but the buttons do the following (left-to-right):
Connect to Bluetooth device (must be named in settings)
Disconnect Bluetooth
Settings Menu
Cycle views
Activate Launch Mode (this only works if you have defined an observer first by tapping on the map view)
Start Logging
Pause Logging

For our lap timings, it's required to set an 'observer' point somewhere inside the race track. To do this go to the map view and tap on the map, it will drop a pin, tap it again to confirm observer and a box appears asking if the race is clockwise or anti-clockwise.
Launch Mode is for when the car is on the start line, it waits for 20% throttle, at which point it will trigger Race Start, lap timing and averaging.

Mandatory Disclaimer: This software is not in any way associated with Jaguar Land Rover and is provided ‘as is’ without warranty, implied or otherwise. There is no guarantee of support or updates.

Download Link:Driven Bluetooth v1.5.

Having said that, we will aim to be as helpful as possible with any issues and questions etc people have. We also have a few more ideas for features to add to the app and are open to feedback! Please submit any bugs or crashes you find in this thread with as much detail as you can, including your device type, the version of Android you are running and what you were doing when the app crashed.

____________________________________
To support this from the vehicle side:

An Arduino Uno and HC-05 or HC-06 Serial Bluetooth module will be suitable for most applications and from Hobby Components cost less than £15. The Bluetooth aspect may sound scary, but using the HC-05/06 module it is quite literally plug and play. There are also hundreds of examples on google.

Hobbycomonents Uno: http://hobbycomponents.com/boards/522-hobby-components-arduino-compatible-uno-r3-and-usb-cable

Bluetooth Module: http://hobbycomponents.com/wireless/432-hc-05-master-slave-bluetooth-module?search_query=bluetooth&results=10

There are cheaper options available if you fancy ordering from China, but them actually working can be hit and miss!

The idea behind this is to keep the vehicle electronics as low cost and simple as possible. With loads of online resources, the Arduino is one of the most accessible microcontrollers to program, and a very good platform for learning with. I know they are quite common in Greenpower cars!

Communication with the Android app is one-way which means that there is no possibility of sending commands to the Arduino as regulation prevents us from using a battery powered device as a control system. Communication is achieved using 5-byte data packets and a comprehensive ruleset for maximum efficiency. As a result of this any values below 127 are sent with two decimal places (i.e. 123.45) but values over 127 are sent as integers (i.e. 130). Each data packet includes an 'id' to tell the app which variable it is sending. We will provide a C code function for the Arduino (or a library if we have time!) that handles the low-level packet building - sending data to the Android is done through one simple function call.

We may be jumping the gun a little posting this before we've run it on a car, but the idea of sharing this has driven a lot of the design decisions - responses to this, or lack thereof will influence the design in the future!


«13

Comments

  • Hi, thanks for this it looks like just what we need to get going with data logging. As a complete newbie to this sort of thing, can you recommend any sensors that would work with the board?
    Thanks
  • This looks really interesting!!! Please keep the development going on this... We dabbled in Arduino concepts last year with RLR1 but got sidetracked into building RLR2. This could be a great off season project for many teams!

    Thanks,

    Ben
  • We will keep you updated :) This will be running on F-eV at Bedford if people want to take a peek, although our hardware is very much 'beta' at the moment!
    As far as software goes we've fixed various bugs that caused crashes when you tried to cycle through the views really fast, and changed to graphs that use less processing power to generate along with other bits and bobs. No change in functionality though.

    Download: Driven Bluetooth v1.6

    Long term plan is to pop it on the Play Store, that's probably a while off though.

    The code for the Arduino to send a packet out is here. Paste that function into the end of your code (after the final '}', not within the loop) and call it with sendData([id],[int or float value]);.

    Regarding sensors for the Arduino, voltage and current will be the most common I imagine. The Mega has 10 inputs that can read an analogue voltage between 0 and 5v (any higher and you damage the chip very quickly - be careful). These can be used for most of the sensors required.

    Voltage is an easy one. A couple of resistors arranged as a potential divider to reduce the battery voltage to a range of 0-5v. Remembering that you can realistically see about 28v (14v per battery) we went on the safe side and decided to reduce 30V to about 5V with 82k and 16k resistors. A nice looking tutorial is here for more information.

    To protect the arduino I would place a high value resistor (10k or so) between the output from the potential divider and the arduino pin. This doesn't effect the reading as the arduino has a 20Mohm input impedance, so virtually no current is flowing, therefore virtually no voltage is dropped across the resistor, but if something goes wrong and a higher voltage appears on the output of the potential divider this will provide some protection to the microcontroller. This goes for any input to the arduino.

    Current is more tricky, to a large degree due to the nature of our brushed motors the current is constantly changing while we want an averaged value. There are two main approaches - having a low value shunt resistor in line with the motor or using an hall effect current sensor. I'm not recommending the linked ones, they are purely for example, I haven't checked the specifications at all!

    If you have a google around there are lots of pre built sensors for the arduino (including sensor kits on amazon that have lots of sensors for playing around with). We're using TMP36 Temperture Sensors and non latching hall effect sensors along with magnets on the motor shaft and wheels for motor and wheel speed.

    Pretty much everything I've tried to do with an arduino has been done before and there's some form of tutorial for online :)

  • Thanks Griff_JLR ...... very interesting. I noticed that the link to "The code for the Arduino to send a packet out" doesn't seem to work for me. Team USA is also working a similar effort and we utilize the hall effect type current sensor. It seems to work well for us.
  • True, that link is dead, sorry! It's here: https://www.dropbox.com/s/qzhzgecfajopjay/BluetoothSendFunction.txt?dl=0

    That hall effect sensor looks very similar to ours, except ours has a reference voltage output too. Theoretically this should give us better noise immunity, in reality it's just proving a pain!
  • Looks really good! Just started working with the TPS team (second attempt this season) going to be trying this out for our datalogging. Anyone got any further advice to that above - or any software examples to help bootstrap ;-) ?
  • Hi Ferrisb, I've been quiet on this but we're still developing it. I hope you get on well with it! let me know how it goes.

    As far as sample code goes, I've got some decently commented code I can share from a project we hope to announce soon, but it's far from complete and I haven't got around to the documentation yet, so depending on how fluent you are in C it may or may not be so helpful! It's written for an Arduino Nano, I think the pin outs are the same between a nano and an Uno but I haven't double checked that!

    Arduino Nano incomplete code Here.
  • Many thanks indeed - starting to look at it this week. I program in Python and Java so hopefully I can work it out, I have an UNO so lets see how it goes! Will no doubt be coming back for some advice as we go, but thanks for sharing!
  • How are people powering their data logging Arduino's? Presume the simplest is straight off one of the 12 V batteries. Has anyone had any issues with the motor transients killing them or are they quite resilient?

    There is a lot of good stuff on the Rotary racer website about transient protection:
    http://www.greenpower.beamweb.co.uk/groups/electronics/VoltageTransients/index.html
  • If taking a line from the 12V battery make sure it has a chunky diode in line with it, otherwise the 24V may find a return path back through it.

    Our early experiments on the lab car took a 12v line to a standard car USB charger - at one point we flipped the isolator switch (on that car positioned between GND and the batteries) and the motor kept spinning.

    We were confused! Turns out the motor was running on 12V (from the upper battery) and finding a return path through the arduino's power supply, which got rather hot!
  • Sorry for the double post...

    I realised last night that the arduino code I linked to in an earlier post didn't even compile! Sorry. Hopefully anyone who attempted to use it managed to get past my typos.

    I have since added significantly to it - it is approaching a completed program, and has more explanation in the comments. I've updated the code at the link, so same link, but for ease, it's here.
  • Great work Griff - really looking forward to implementing your system on RLR 2. Your layout and notation on the code is really good and very helpful to non-programmers such as myself.
    If there was an variable not being used in your program such as fan RPM for example, would the Arduino throw a wobbly?
    Thanks again, Ben
  • Thanks Ben, encouraging to hear! We're trying to make it as approachable as possible.

    If a variable is defined but not used it's simply ignored. You can leave it in place, comment it out or delete it for neatness.
    One thing to note though is that if you delete a pin assignmnet (i.e. 'const int THROTTLE_IN_PIN') then any references to this later in the code such as setting the pinMode in the setup() loop will also need to be deleted before the code will compile.

    In most compilers, when they compile code (Verify code in Arduino terms) they will optimise it and any variables which are declared but not used are completely ignored in order to reduce the program size. I think (and hope) the compiler used by the Arduino does this, but I'm not 100% sure.

    Thanks,

    Rowan.
  • edited March 2016
    I just wanted to note that I've added an auto configure feature for the HC-05 Bluetooth Module into the code.

    Upon startup the Arduino checks if the bluetooth module is in AT (programming) mode, and if it is sets it up with the name, password and baud rate defined in the code then resets the module into normal mode.

    To use this, (assuming the code is already flashed) power up the Arduino, unplug the Bluetooth module, press and hold the little button on the Bluetooth module while you plug it back in. The light on the HC-05 module should now be flashing very slowly. Press the reset button on the Arduino. If all is successful the bottom LED on the Arduino should flash three times and the LED on the HC-05 module should start flashing at normal speed. If you search for Bluetooth devices on your phone it should pick up the device with your new name set.

    (If an error occurs during the setup the LED on the Arduino will pulse rapidly and you will need to reset the Arduino.)

    If you swap out a Bluetooth device but make the name the same as the old one you will still need to re-pair on the phone.

    The code is also here flashable by itself to an Arduino nano using pins 10 and 11 as TX and RX for the Bluetooth module.

    I really hope this will work well - it has in my testing - but if anybody tests it I'd be grateful for feedback!

  • edited June 2016
    Been a while (work...) since I looked at this but revisiting properly this week to try and give some basic data for our car running at the weekend. So, I have the 1.6 app on an Android handset but finding the following issue:

    1. [REMOVED] - I had not realised that maps had not been enabled on the device (its my sons!). This is required before the app can use GMaps location...

    2. The bluetooth connection connects for a couple of seconds then drops, in a continuous loop.

    Any advice much appreciated !

    Cheers, David.
  • Hi David,

    The app has progressed a little, and moved to the play store! I had meant to post that here... oops.

    Try the latest version from here: https://play.google.com/store/apps/details?id=com.ben.drivenbluetooth

    If you have issues with that let me know and I'll give my head a scratch :)

    Rowan.
  • edited June 2016
    Thanks Rowan - love the new look :-) !

    All appears good but I still get the bluetooth connected / could not connect loop. Do I need to do anything in the code? The light on the HC-05 is blinking fairly fast.

    The phone has paired with it BTW.
  • edited June 2016
    The blinking light indicates that it's awaiting a connection.

    In the eChook app, have you gone into settings and entered the name of the HC-05 in the 'Bluetooth Device Name' field? (This step is still a little clunky - eventually you will be able to select from a list of paired devices)

    If you have, check if there are multiple devices with that same name paired with the phone?

    Rowan.
  • OK - so a bit of research done. I can connect to it via my mac (LED blinks slowly) so all looks good. Moving back to the phone I kill the app (first removing the bluetooth device name). Remove the device from bluetooth devices, restart bluetooth on the phone and re-pair. All good, LED blinking slowly and reports connected. Start the app and all is OK still. Enter the device name (tried both in caps and lc) and enable bluetooth. At this point the LED on the unit starts to flash quickly again and we go back to the looping.

    Is there any log data or similar I can get to to see what is happening?

    Many thanks again, David.
  • edited June 2016
    Hi David,

    I've realised what it is. The app constantly monitors the data connection, and if for any reason it stops receiving data, resets the bluetooth connection as an attempt to fix the problem.

    I imagine you have it powered up, but no data being fed to the HC-05? If you feed it some data (simply flashing the code from here will work: https://codebender.cc/sketch:171686 ) the connection should maintain without an issue.

    The baud rate for the Arduino and HC-05 will have to be matching - that code sets the Arduino to 115200, default for the HC-05 is 9600. You can either set this manually, or use the auto set up in the above code - set the HC-05 name and baud rate in the code and follow these steps:

    1. Connect bot Rx and Tx between the Arduino and the HC-05 module

    2. Press the small button next to the ‘EN’ pin on the bluetooth module while unpowered, power the module, then release the button. Bluetooth Module LED should now be blinking slowly. Two seconds on, two seconds off. If this is not the case, plug it in again with the button held until this is achieved.

    3. Press the reset button on the Arduino. Upon powering up the ‘L’ LED on the arduino should blink quickly 3 times and the LED on the Bluetooth module should resume to flashing quickly, signifying it is waiting for a connection. The module will now appear on a phone under the name specified. The passkey will be ‘1234’. Pair as you would any bluetooth device, then in the eChook app settings, enter the bluetooth device name to connect to.

    3a. If configuration has failed the ‘L’ LED on the Arduino will continue blinking and the Bluetooth module LED will keep blinking slowly. Attempt to run through the process again.

    For reference, the Bluetooth device name in the app is case sensitive.

    Fingers Crossed :)

    Rowan.
  • Ah - sounds likely, I have nothing connected yet - just testing connectivity.

    Can I just check the pin-outs I am using, not been able to update the BT device name despite checking many combinations... (could not see pin-out in the code comments - apols if I missed it - could be useful to add?)

    STATE - not used
    RXD -> D11
    TXD -> D10
    GND -> GND
    VCC -> 5V
    EN -> D9

    Based on the diagram linked in the code:
    http://www.instructables.com/id/Modify-The-HC-05-Bluetooth-Module-Defaults-Using-A/
  • Ah sorry. For the code I linked Tx and Rx are connected to Rx and Tx on the arduino (pins D0 and D1, can't remember which is which, but they're labelled on the board silkscreen). When connecting, remember that Rx is receive and Tx is transmit, so the Transmit (Tx) connects to the Receive (Rx) on the HC-05 and vice versa. The number of times I've got that wrong....

    Power and ground are connected, other pins are left disconnected:

    State - not used
    Rx - Tx (Arduino)
    Tx - Rx (Arduino)
    GND - GND
    VCC - 5V
    En - Not Used

    There are two ways to use serial with the Arduino. There is on hardware serial port (some have more than one), and it is also possible to emulate one in software using the SoftwareSerial library. We have used the hardware serial as it is more efficient, but it is the same pins as used to communicate over USB, so you can't use it to communicate with a computer and the HC-05 at the same time. The instructibles tutorial needs to talk to the computer and HC-05 at the same time, so creates a software serail port on pins 10 and 11.

    The instructibles tutorial uses the EN pin to put the HC-05 module into AT mode (setup mode). I use an alternate method - disconnect power to the module, either by removing the 5v or ground wire, or by completely unplugging it, then holding down the little button on the module, plugging it back in, then releasing the button.

    Hopefully that helps?

    I will add a comment in the code for HC-05 pin out, cheers :)
  • Awesome sauce, all running properly now :-) - many thanks for the support!

    Sensors arriving tomorrow so will get some testing done tomorrow evening.
  • Great to hear, good luck with it :)

    Let us know how you get on.
  • OK - got the parts now and onto the next problem... hall effect sensor. I am using the hobby components HCSENS0021 but in true style the pin description does not match the device and no matter what arrangement I try it is not responding to a magnetic field. So, I have got it to run the LED on on the unit and I can see +4.5V on the data out using these connections:

    PIN 1: GND -> Y
    PIN 2: +5V -> R
    PIN 3: DATA OUT -> G

    However I am expecting the 4.5V to drop to 0V when a mag field is in contact with it. Sadly, nothing happens - even using a strong magnet.

    Any help much appreciated as usual...

    Also, I am seeing spurious values for voltage and current in the app - I have nothing connected yet and I was fairly sure this was not the case when I was looking at it a couple of days ago... is that expected?
  • edited June 2016
    Hi,

    The pins for voltage and current are floating so the readings will be fluctuating pretty randomly - totally normal. If you want to stop it you can either comment out the code reading the pins, or ground the pins.

    I've not used that hall effect sensor myself, but sometimes they behave better with a pull up or pull down resistor. Try connecting a 10k resistor between the data pin and ground and test, then data and 5v if no difference.

    Good luck

    Rowan
  • I got in a mess with Hall effect sensors a short time ago. Turns out there are four different types, Unipolar, Bipolar, Latching and Omnipolar, who knew (not me).
    In my nativity (and speed to get one) I thought they all worked the same. I got a Honeywell Bipolar one and found that it would only give a signal out as I expected if we had a North followed by a South pole so it depended very much what your magnet arrangement was. See here fore the detail.
    http://www.allegromicro.com/en/Design-Center/Technical-Documents/Hall-Effect-Sensor-IC-Publications/Unipolar-Hall-Effect-Sensor-IC-Basics.aspx

    What I wanted was a hall effect sensor where it didn’t matter which way the magnet was around so Omnipolar is the type you need for that. The one I got in the end was RS 901-4023 (Taiwan Semiconductor TSH253CT B0G). This is £0.51 each, but annoyingly from RS you have to buy a pack of 20. This works really well and gave good results at Goodwood this weekend.

    I would suggest if you are having trouble with that hobby components HCSENS0021 sensor try reading the part number on the IC itself and google it to find the datasheet. That will tell you what type it is and confirm its pin out.
  • Another thing the direction of the field to the sensor also matters, you get some funky pulses out of them if you mount them end on and the field swaps direction. You need the planar part of the silicon facing the magnetic field and not the edge of the silicon. They will show this on the data sheet. If in doubt experiment.
  • Sim does raise a very good point - you'll need a unipolar or omnipolar, non latching hall effect sensor. We've always used unipolar and had a little trial an error to make sure the magnet is in the right orientation to trigger the sensor.

    We've been using Allergo A3141 sensors @ £0.16ea from aliexpress.
    http://www.allegromicro.com/~/media/Files/Datasheets/A3141-2-3-4-Datasheet.ashx?la=en

    Another spec to look out for is the period, or rise and fall times of the hall effect. If this is too slow, especially on the faster motor shaft, the output will not have time to reach 0V in the short amount of time that the magnet will be triggering the sensor and the output looks more like a saw tooth wave than the square wave desired.

    The actual speed required is difficult to calculate as it is determined by the time taken for the magnet to pass the hall effect sensor, and the time between magnets. (And to get technical, how much overlap is needed between the magnet and sensor before it is detected...).
    The 0.04uS rise time, and 0.18uS fall time of the A3141 sensor is more than good enough though, giving a perfect square wave with three magnets on the motor shaft at 1800rpm. The datasheet times are measured at 8v, running it at 5v as we do likely decreases these times as there is less difference between high and low - assuming a constant slew rate.
Sign In or Register to comment.