A fantastic day at Rockingham saw the weChook racing team manage to run an echook nano for 2 hours on our car Electric 2Galoo. Thanks to all who came to speak to us on the day about the car, as always it’s a pleasure to talk to like minded people who just love to build race cars!

We had great success with out 2 hour test using the echook board both as a motor controller driver board as well as a telemetry data logger. The phone screen was used to inform me (the driver) how much current we were drawing and was perfect for testing our race strategy plans. We also managed to collect 2 hours of good data from our sensors, result!

David @cullimoreracing has kindly offered to run an eChook Nano on Jet2 but we will be looking for more test cars to get these boards on to for the start of the season. Before we do do this we need to tidy up our documentation and work out how we are going to fund the project at this point (the boards are cheap but with components the cost is looking to be ~£30 before you add on the £17 current sensor…we aren’t trying to make any money from this project but we are also not trying to lose too much, we have racecars to build!). We have 9 more boards from this initial batch, watch this space for what we plan to do with them….

Here’s a video describing the main board features

Having covered how Ian uses our measured data whilst out on circuit in the last post (read it here: https://wechook.com/?p=518 ), I’m now going to cover what we can do with it when we’re not racing – be it in the pit lane or once we’re back home.

The first step is getting the information from the car to my laptop. As long as we remember to put it in, the telemetry board will record all measurements to a text file on an SD card, which can then be easily transferred across to a computer. The system also transmits data live wirelessly during a race, but this is of little use when the car goes out of range or behind a tree – pretty much everywhere apart from Merryfield and Dunsfold Park.

For the information to be valuable during the constraints of a race day, all the information has to be pulled together quickly – there’s not a lot of time to make changes in between the end of practice and the start of the race so every second counts. In order to maximise the utility of our data logging, I wrote some code in MATLAB that will read the data files, and generate a report with useful plots and calculations. I’ve uploaded two of these reports, from two different races at Rockingham to the website:

• Rockingham Heat 2015 (Electric Boogaloo) – https://wechook.com/wp-content/uploads/2016/02/RockinghamRaceData.pdf

• International Final Day 1 – Lap Race 2015 (Electric 2galoo) – https://wechook.com/wp-content/uploads/2016/02/LapRace.pdf

As an aside – I heartily recommend that any aspiring young engineer go out there and get some experience using MATLAB – it is easy to pick up and there is a huge wealth of help and support available online. As a data analysis and visualisation tool it far exceeds Excel, and will make a piece of work look far more professional! I use it extensively at work to perform simulations, automatically generate reports (automating a task that used to take hours keeps my manager very happy) and design control algorithms. From experience, I can also say that if I’d learnt to use it whilst at university, it would have made my dissertation project a whole lot more manageable, due to the Gigabytes of data that I was dealing with from incredibly high resolution measurements of impact data.

Sales pitch over! Once I’ve worked my magic with MATLAB and generated a report we can work out how much current and power we were using at any given point, and how fast we were running the motor. Using this approach with data from a run in practice, we can determine whether we can complete a full race distance at that pace without flattening our batteries (I’ve done plenty of battery testing, so I have a good understanding of how much energy the batteries have available).

Based on the data from the Rockingham heat, we were able to plan our power usage for the Lap Race – we estimated how much shorter it would be than the standard hour and then determined how much more quickly we could discharge the battery. If you look at the two reports linked above, you can see that we drew just under 25Ah from the batteries in both events, but at a higher average rate in the lap race.

Also shown in the reports are traces of throttle position and motor speed. Comparing the throttle trace from the Lap Race to that from the heat earlier in the year, it can be seen that Ian is performing fewer gear changes, and spending less time at part throttle. It can also be seen that motor speed tailed off much more quickly at the end of the Lap Race – we’re putting this down to the fact that we were using our best batteries in the Rockingham heat, but we saved them for the F24+ decider on the International Final weekend.

We’re planning to extend our data collection next year to include wheel RPM (from which we can calculate vehicle speed, and determine which gear we were in) as well as motor temperature, to avoid the risk of cooking another one! With this data we plan to be able to run an improved race strategy in the 2016 season – instead of targeting a constant rate of discharge from the batteries, we will be looking at how we can most effectively convert each unit of energy into speed.

Which brings me nicely onto the subject for my next post: Constant Current vs Constant Speed control!

Seeing as we’ve been espousing the virtues of data collection of late, I’ve decided I’d best write at least a bit about some of the things we do with our data.

I’m going to split this into two posts – the first covering how the driver uses the information during the race, and the second discussing what we do with the logged data in between sessions and race days, as well as what we’re hoping to achieve in the future.

From the Rockingham heat onwards, our cars were fitted with a screen that showed the driver a live readout of battery voltage, motor current and motor speed. Voltage isn’t much use on a moment to moment basis – it fluctuates with the current that is being drawn, meaning there’s no simple way to estimate the charge left in the battery

Motor RPM is also tricky to use – we know we need to keep the motor in its ‘happy range’ in order to keep power consumption low and stop the temperature from getting too high, but it’s difficult to plan a race using motor speed – without a good model of the motor, we don’t really know whether we need to hit 1750 rpm or 1800 rpm to make it to the end of the race!

That leaves battery current as the most useful resource to the driver. We’ve done plenty of testing, which shows that our best batteries have a capacity of roughly 25 Amp-hours, when discharged at a high current. For comparison, our worst batteries have a capacity of 22Ah, which can make a big difference when trying to reach the end of a race.

With 25Ah at our disposal, and an hours worth of racing to complete, the maths isn’t too hard; we need to hit an average of 25A over the course of the race to make sure we get to the end – simples!

With a single speed, relay controlled car, this is achieved through selecting the right gear ratio – get it wrong and you won’t reach the end of the race, or you will get there but at a slow pace. Choosing that gear ratio can be tricky – for me it came down to experience and voltage measurements. I’ll discuss more on this in the next post though!

Electric 2galoo had the luxury of a wide range of gear ratios, and a speed controller. By shifting up and down the gears and by varying the throttle input, Ian was able to target a constant rate of power consumption. At the International Final, this allowed us to control the rate that the battery went flat very nicely – gaining us a place on the last lap as the competition ran out of juice!

2galoo’s current consumption from the international final

We’re currently developing a data logging product that will be available for sale to all greenpower competitors – read more about it here – https://wechook.com/?p=511 . If you’re interested in investing in one, get in touch with us on twitter (@Ramjet_gpt) or on the greenpower forum here: http://www.greenpower.co.uk/forum/discussion/3398/introducing-project-echook-nano

Hello all!

The weChook Racing and Driven teams have recently launched a joint project (Project eChook Nano) to develop a standalone system capable of logging important telemetry data from a Greenpower car. Both of our teams feel like we learn a lot from our current telemetry setups and that making this type of information more easily available for other team’s vehicles would be incredibly beneficial and would really help with the engineering and learning aspects of Greenpower racing.

Our aim in developing this hardware is create something simple and affordable that will allow those teams without electronics experience to collect live data from their car for analysis during races, and as something to study in between events. It will be based around an ArduinoNano, and be provided with the base software to perform standard logging functions, whilst giving the students the opportunity to implement their own code to customise the functionality as they see fit.

The hardware is designed to interface with an android app that Rowan has posted about on the greenpower forum here: http://www.greenpower.co.uk/forum/discussion/3335/data-logging-and-driver-information-display-android-app-offer. The hardware on the car communicates with the app via bluetooth, and can provide instantaneous readouts to the driver, as well as logging the information for later analysis. The app will also use the phone’s sensors to supplement the information gathered from the hardware.

A further aim of the project is to provide the ability to live stream the information to web interface via the phone’s 3g connection, allowing information to be viewed live from the pit wall. An exciting prospect to try to understand why a competitor car is accelerating past yours but consuming less amps….perhaps time to get the chain oil out during that next pit stop 😉

We’re designing with the following I/O (and some of our suggestions on what they can be used for):

Inputs
• 2 x Voltage (12V, 24V)
• 2 x RPM (Motor, Wheel)
• 3 x Temperature (Different bits of the motor, battery)
• 1 x Current (Motor)
• Throttle Position
• Brake
• Cycle View & Launch buttons (for use with the app)
Outputs
• LED x 3 (visual status indication)
• Bluetooth Output (interface to the app)
• 2 x PWM output (Fan, Motor controller)

Our primary intention is for this to be a passive component, that can be added to a car with minimal disruption, and will not affect the actual running of the car – we don’t want to be responsible for taking someone out of a race! The pins are there however to receive a throttle position input, and output a PWM signal to a motor controller. Teams can pick and choose what sensors they feel are necessary for their learning, though we would suggest current consumption is the most interesting!

We’re are currently working hard to get the base system cost less than £40 to make this accessible to as many teams as possible. Sensors are not included in this figure but most are cheap components (bar the LEM current sensor which can be found for ~£18). Due to the open source nature of this project we aim to provide teams with all the information required to source and put together the hardware themselves, but initially we will provide a ‘build kit’ so we can get some hardware out there in the field and get keen teams testing it as soon as possible.

At the very least, we’ll be running the system on Electric TubeOfGlue (the weChook racing team’s development vehicle) for the season if no other teams are interested!

Please get in touch with us on the greenpower forum (http://www.greenpower.co.uk/forum/discussion/3398/introducing-project-echook-nano#latest) or on Twitter (@Ramjet_gpt) if this is something your team would be interested in having or even being involved with. We have captured our ideas here but it would be great to hear from others on what is most important to their team.

Best Regards from the team, Matt, Ian, Rowan and Ben!

eChook Nano Schematic