weChook Racing: How we use data in the pits

Having covered how Ian uses our measured data whilst out on circuit in the last post (read it here: http://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:

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!

weChook Racing: How we use data on circuit

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

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 – http://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

 

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

eChook Nano Schematic

weChook Racing – Greenpower Motor Testing part 2

Introduction

After testing two brand new Greenpower motors (http://wechook.com/?p=321) we borrowed the two motors that had been fitted to Project E and C-XeVolution for the last season.

We were aiming to determine how effective these motors were compared to the new pair and to each other.

 

Background

Over the course of the season, the two motors fitted to C-XeVolution and Project E had both covered hundreds of miles, so we wanted to determine whether there had been a significant gain or loss of performance from the extensive run in. Unlike C-XeV’s motor, nether of this season’s motor’s has been significantly overheated, however the motor from C-XeVolution did get warm at Castle Combe and the International Final, due to the hills.

 

Test Procedure and Equipment

The used motors were tested using the same equipment as the new motors. This time, we decided not to attempt the highest current draw using the heated seat pads, as the results were not reliable enough. In order to test at the higher currents, its likely that we’ll have to add more bulbs.

 

Results

Shown below are two plots. The first shows a comparison of the 4 motor’s efficiency plotted against motor rpm, the second shows efficiency plotted against battery current.

Plot 1

RPMpart2

Plot 2

Currentpart2

Conclusions

When plotting the motor’s efficiency against current, C-XeVolution’s motor is comparable to the second new motor, however it must run much more quickly in order to achieve this efficiency. Evolution’s motor’s performance appears to be tending towards that shown by C-XeV’s motor in the last test report, suggesting that the extra heat it experienced at Castle Combe and Goodwood may have started to cause some damage.

Project E’s motor also appears to need to run at a higher speed in order to achieve its peak efficiency, although it is more efficient than the first new motor over most of the tested speed range.

It suggests that, if we had managed to the run the motor at ~2000 RPM, rather than ~1700RPM, we would have been in a much more efficient range.

 

Further Work

Further testing of the new motors after a more extensive run in will allow us to see how efficiency is affected by distance and thermal cycling. The motors will be cycled using a power supply to start with, and then run in anger once the rest of Ramjet is complete.

We also need to develop a more reliable method of testing the motor at higher duty, in order to better compare motors at the speeds they tend to experience during a race.

weChook Racing – Greenpower Motor Testing part 1

Introduction

As part of the development process for Ramjet, we have been testing a pair of brand new motors, as well as an old (and heavily abused) motor that was used in C-XeV –  Driven’s 2012 competitor.

The aim of the testing was to calculate the comparative efficiency of the two motors, and develop an insight into how the motors perform at different speeds and powers (and see what a really bad motor looks like as well!).

Background Information

During a Greenpower F24+ race, the motor is run using two 12V Lead Acid batteries wired in series to generate the required 24V. Bench testing has shown that an average current draw of ~22Amps or less is required to reach the end of a race without over discharging the batteries, or ‘falling off the cliff’. If the battery is discharged to the extent that the voltage begins to collapse, lap times at the end of a race can be severely compromised. This can be seen in C-XeVolution’s performance in the Greater London F24+ Heat, when compared to Project E. (504 compared to 711: http://bbk-online.net/gpt/lap213.htm)

Over the course of the race, Project E lost 6 seconds compared to its fastest lap, whilst C-XeVolution dropped nearly 40 seconds. In the race, C-XeVolution was consistently consuming an average of 24 Amps, whilst Project E was consuming 21 Amps.

On a race by race basis, current consumption is controlled by gear ratio. In order to most effectively select a gear ratio, a good understanding of the motor must be gained. Adding further complexity to the mix is the fact that the profile of each circuit varies so wildly. At Dunsfold Park, Project E’s current consumption stayed consistently between 18 Amps and 23 Amps, whilst at the National Final in gusty conditions, the current dropped as low as 15 amps on the main straight, and topped 35 Amps uphill. As such, simply investigating the motor performance at the intended average current would not be enough.

Test Procedure and Equipment

The electrical lab-car, built at the start of the year to develop and test Driven’s 2014 electrical system, was used to test the motors. The test motors were attached to another, spare motor, which acted as a generator powering a number of bulbs. The number of bulbs in the circuit, and thus the torque applied to the test motor, was controlled using a separate arduino board.

Using a current clamp and a voltmeter, we recorded the power into the drive motor, and out of the generator across a range of different output currents. We also used a tachometer to measure the motor’s shaft speed. It’s been assumed that at a given rpm, the generator’s efficiency will be same, independent of the motor being used to drive it. Thus by comparing the two new motors on a plot of efficiency against rpm, we can eliminate the efficiency of the generator from the equation.

Following the first test session, the motors were run in, unloaded and from a power supply, for 3 hours and 12V and 3 hours at 24V. Once the motors had been allowed to cool down after this, they were tested again. We decided to add some more load to the test rig for the second set of tests, to understand the efficiency at lower rpms/higher currents. These loads were not as stable in their power consumption as the bulbs however, and so there is less confidence in the results at a higher current.

Results

Below are three plots. The first shows the motor/generator system efficiency against motor RPM, and the second shows efficiency plotted against current output from the generator, which is broadly analogous to load on the motor when racing. The final plot is a repeat of the first, but with C-XeV’s motor included.

Plot 1

RPMnoCXeV

Plot 2

CurrentnoCXeV

Plot 3

RPMwithCXeV

Conclusions

Compared to the two new motors, C-XeV’s old motor ran at a significantly higher speed when unloaded. To achieve the same current output from the generator, it would require more current from the power supply than the new motors. Due to the higher speed of the generator, its voltage output was higher, masking somewhat the motor’s inefficiency. It is inarguable however, that it is less efficient at the speeds experienced during a Greenpower event that the two new motors.

When comparing the two new motors, there is a noticeable difference, with Motor 1 having an efficiency 5% or more greater than Motor 2. The margin increases towards the top end of the powers seen during a Greenpower F24+ event.

After the run in period, both motors showed a lower peak efficiency. The gap between the two motors at lower speeds decreased, and the peak efficiency for both motors appeared to be at a higher current. The second set of tests also showed the folly of allowing current to reach 30 amps or above. Efficiency quickly dropped off and the motor began to noticeably heat up.

Based on this testing, it appears that the motor’s peak efficiency lies between 13 and 16 Amps. It is also known, based on Peukert’s Law that a batteries effective capacity decreases the more quickly it is discharged (Have a look at wikipedia: http://en.wikipedia.org/wiki/Peukert’s_law, or Chipping Sodbury’s page: Greenpower Science).

To me, this suggests there may be an alternative race strategy, that involves running less aggressively, at peak motor efficiency and a low battery discharge rate, for a portion of the race, before moving to a low efficiency, high power mode for a blast to the line. Whether this strategy is quicker over the duration of a race would depend on the battery’s Peukert Constant, the change in motor efficiency at different currents, and the overall aerodynamic efficiency of the car.

Further Work

Further work will involve further running in of the motors, before another testing session, and performing the same series of tests on the motors fitted to Project E and C-XeVolution (Driven’s last two cars) for the 2014 season for comparison. Both motors have been well run in, and neither has been significantly overheated, which will make for an interesting comparison both to the brand new motors, and the very much overheated motor from C-XeV.

A new work stream opened up by this testing is to investigate the possible effectiveness of a split strategy, running slightly slower at a super high efficiency, to allow a final blast towards the end of a race. In order to determine the worth of this strategy, a better understanding of the battery and motor performance will be needed.

 

Driven Electric Race Car – Heated Battery Boxes

For those of you who have been paying attention I have been working on a project called ‘Driven’ for the last 18months. ‘Driven’ is a single seat electric car project where myself and other Jaguar Land Rover graduates design and build a car to race in the Greenpower race series. On this project I had some help from Zoe and Will, graduates in the year below me on the scheme who will be taking over the project when I leave, thanks for the help guys!

The lead acid batteries we use in our electric car are heavy and the team needs an easy way of transporting them to races and storing in the workshop. Currently we use insulated battery boxes to store our batteries in, transport them to the race however, the boxes are too large and have no way of actively heating their contents. Since batteries are allowed in the rules to be heated to 25degC it makes sense for the team to always be running the batteries at this temperature: with lead acid the warmer the battery the more capacity we can get from it (within reason).

Solution: New battery boxes that incorporate a 12V heated seat pads from old car seats. These will allow us to both transport the batteries and warm them prior to a race simply by plugging in a spare car battery. By making the box just big enough there isn’t too much excess air in box that has to be heated up.

For this project I actually constructed a list of requirements before starting the build:

  • 2 boxes should be constructed to hold 4 batteries each (4 batteries are used per car for race days and the team has 2 cars).
  • Boxes should be easily moveable
  • Boxes should be easy to strap in to the van for transport
  • Boxes should use a Red SB50 anderson (12V) for power connection to the heated pad, this is the teams standard connector
  • Boxes should be made from a wooden frame base with plywood cladding
  • Boxes should look presentable, logos on side prefered.
  • Lids should be removable and allow charging of batteries inside the box + battery access.

IMG_20140619_193352IMG_20140619_192841IMG_20140619_193727IMG_20140619_201508

The bottom frame of the box is made from 2×4. This effectively transmits the weight of the batteries to the castors and gives space to insert a piece of insulation foam. A heated seat pad is re-purposed and simply pressed in to place using the piece of foam. Holes are drilled in the bottom of the plywood base for temperature sensors and to give an easy way to push the foam and pad out in case of maintenance. Castors are mounted so that the box can easily be pushed around the teams workshop.

IMG_20140620_183851IMG_20140620_185634IMG_20140620_185644IMG_20140620_190859

With 2 bases completed Zoe cut up the plywood sides while Will and I glued and screwed them to the base. Extra timber is used inside the box to stiffen up the corners and give the insulation something to press up against. The 50mm insulation is easy to cut with a saw and simply presses in to place, it seems to hold any heat in very effectively.

IMG_20140621_102837IMG_20140621_103740IMG_20140621_105122

A quick coat of paint and some securing handles later and we are finished. Another nice quick project that should help the team for many years to come. Now we just need some nice ‘Driven’ branded stickers to add the final touch.

IMG_20140621_162947IMG_20140621_164500IMG_20140621_165226IMG_20140621_173701

STM32 Programming

Merry Christmas all. Over the Christmas break I have found some time to put together some of the telemtry and control system I have been designing for the driven electric car. I have written this post primarily for my own benefit as it has taken me a couple of hours to get to a stage of programming my board which would have been avoided had it not been for a simple misunderstanding.

The main ‘brain’ of the board is an STM32F103RB, fantastic bits of kit and my first push away from the AVR family I had become so comfortable with at university. At the time of writing I have designed and soldered up a test PCB and have been plating around with getting a program on to the STM.

I am using my STM32VLDiscovery board’s built in STLink-V1 as a SWD programmer. A simple procedure to wire up between the boards (discovery and my pcb) and get comm’s…AS LONG AS YOU DON’T NEGLECT THE ANALOGUE VDD PIN. I had not forseen the importance of connecting this pin initially and had left it disconnected (for the simple reason I couldn’t find the 0603 inductors I had ordered to nicely smooth the analogue supply line going IN to this pin. After a few hours headscratching, checking and rechecking for shorts, I finally found this disconnected pin to be the source of all my problems. Christmas truely has come early.

So watch out for this in the future Ian, and hopefully this note may help someone else in the future.

Aerodynamic bicycle wheel coverings

It has been some time since I have stayed up til 1am working away to get a project done. It seems once you leave University and start working for a big company times like this are rare and I find myself missing the feeling of satisfaction when, at the end of a long session of chooking, you get to go to sleep.

Fortunately this void has recently been filled by Driven…..from my projects page, ‘since starting my graduate scheme for Jaguar Land Rover I have joined the ‘Driven’ engineering project. A team of graduates who design and build a new car every year for an electric vehicle race hosted by Greenpower.’

So far the Driven project has helped me meet many talented people all with the common goal of making an electric vehicle. This has also presented some unique challenges as the team is far bigger than those I have worked with in the past, with the idea behind this being that we function as a microcosm of the overarching company. In addition to building a car every year the team hopes to (and hopefully succeeds in) inspiring the younger engineers at the race events. I plan to use this blog to document some more of my work for the car in the hope that some principles can be applied by other teams to their cars.

Covering the wheels of our cars we can reduce the loses we have due to aerodynamic drag and hopefully this will increase our top speed and efficiency. Although I am no aerodynamics expert I am aware that a spinning wheel made of spokes presents a drag factor when those spokes are moving through the air. My housemate Shawn would be able to describe the effects of this in far more detail than I can but essentially forcing more air to move in and around the car is BAD.

As well as the spokes going through the air creating turbulence we also want to make the side of our car as flat as possible so that the air is passed down the side, rejoining neatly at the back. Since both our Driven cars have open front wheels covering these can further improve (reduce) the drag coefficient of the body. As an added bonus covered wheels can look pretty cool.

This is a quick and easy way to cover wheels we have been experimenting with. It is cheap and can be done easily at home (this was done in my kitchen). So far I haven’t done any quantitative testing on these wheels vs uncovered but as far as I know the aero benefit should outweigh the slight weight penalty.

Tools used:

  • Stanley Knife
  • Hole Saw + Drill
  • String
  • Pencil
  • Electrical Tape
  • Cutting board
  • 1 screw / nail
  • 1x beautiful assistant, thanks Ben!

We started our build with a big sheet of thermoform plastic, around 1 – 2mm thick should be perfect. Ours is thermoform but only because it is what we could get our hands on, any plastic should work here. We did try some basic thermoforming but found that the plastic would just sag on to the spokes and create a very wavy surface.

IMG_20130627_221956IMG_20130627_231921IMG_20130627_231949IMG_20130627_232038

Start by drilling a hole where the centre of the wheel will go. We then insert a screw in to this to act as a centre reference. A piece of string and a pencil can then be used as a giant compass to draw a circle of approximately right size to suit your wheel. Cut big to start with, it’s always easier to make the circle smaller than bigger if you go wrong! Once you have your circle drawn you should be able to use a stanley knife to cut around the line. Be careful here.

I apologise for the poor picture quality, it was late and my kitchen isn’t the most photogenic place anyway (though much improved by a photogenic assistant!).

IMG_20130627_232547IMG_20130627_232630IMG_20130627_233422IMG_20130627_234346

Next up select a hole saw that is a bit bigger than a convenient flange on your hub. Use the hole we drilled earlier as a guide and the hole saw create a bigger hole.

Now the ‘overlap’. Our wheels (like all bike wheels) are slightly convex in that the hub sits out wider than the rim. This means that a flat piece of plastic won’t simply fit on top. To overcome this we must create a very slight cone to fit the wheel. This ‘overlap’ method is far from perfect as it does create a slight bump on the wheel which makes for a not perfectly flat surface, however, it is easy to achieve at home.

Start by cutting from the inside of the cover to the outside. Then place on your wheel. It should be noted that as the outside of the cover is pulled down to the rim a natural overlap can occur at the new cutline, simple. At this point you may have found that you have to adjust the size of your cover. Ideally you want to have around half of the rim showing and half of it covered as this will make life easier in the next step.

IMG_20130627_234125IMG_20130627_234355IMG_20130627_234630IMG_20130628_002035

Next we run a line of electrical tape all the way around the outer edge of the rim. Covering the new cover and then folding some over the edge of the rim and in to where the tyre sits. Electrical tape actually seems pretty good at going around the circumference of the circle and with practice I can always do it in one long pass. A piece of tape neatly covers that overlap line and then we finish the wheels with some black hot glue just to hold the centre to the hub. It can be worth doing both sides of your wheels, just remember you still have to have access to the valve holes! I just cut a small window on the inside covering to allow access to this.