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 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 here 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, @Ruds_JLR, @icooper, @Griff_JLR and Ben!

Comments

  • Sounds like a good project :)
    One thing you may wish to consider is providing an interface to the GpSpeed controller. This has a port, P4 Controller Connector, designed to connect to a car controller/data logger that provides 5V regulated power, a conditioned 24 Volt rail for battery voltage measurement, the output from a LEM HXS50 hall effect sensor for current measurement and PWM inputs for fan and motor control. Info at: http://www.greenpower.beamweb.co.uk/groups/electronics/GpSpeed/index.html
    and http://www.greenpower.beamweb.co.uk/groups/electronics/GreenpowerElectronics/index.html
  • Hi Ruds,
    We might well be interested for our new car - we intended to use an android device on the instrument panel from the get-go using a cycling app or similar for speed, average speed, time raced so far etc and this elaborates on that idea somewhat. It may even get rid of the need for any other instrumentation, but I guess that's up to whoever's using it. As Terry said, a lot of teams who'd be interested in this either already run or intend to try out RR's GpSpeed controller so that might be a good thing to incorporate.
    We look forward to hearing about your progress with this project.
  • Hi All, - I did this in 2000 using PIC chips. It consumed many hours of development. Life will be much easier now with Arduino which has a good development environment and loads of ready-made hardware to play with. There is no doubt that learning how your car is driven and how it consumes energy is a very beneficial exercise. For those that have gears it is useful to know which gear is in use, and where on the track the gears are changed (another interesting challenge...). When you make a change to the car you can see the effect if you log everything. Take care not to distract the driver with any information - driving it takes a lot of concentration just steering it and keeping out of trouble. One final note, "If you don't measure it, you can't control it". Keep at it - this is what Greenpower is about.
  • Hi Ruds.

    We are interested in doing this for at least one of our cars. I would really like it to be student driven if possible. Is this going to be something they can do by themselves? I have two massively keen year 8 students who I would love to have their own project to do within the team.

    Is it possible to email me as the first point of contact and hopefully we can get things underway? My name is Steve and I am the teacher in charge of the Greenpower project at King James's School in Knaresborough my email is kjsgreencar at gee mail dot com

    Thanks!

    CR

  • Hi Steve,

    Great to hear from you, we'll add you to the distribution list!

    We're intending to provide the board and a set of components with all the documentation necessary for assembly and actually getting it running - hopefully this will fit your needs?

    In other news, I've written up a quick post on our website on how we use measured data during races here: http://wechook.com/?p=518

    And I've uploaded a drawing to the website here: http://wechook.com/wp-content/uploads/2016/01/nano-schematic.png
  • Hi Steve,

    To add to Matt's (Ruds) reply, the hardware is intended to be self assembly using through hole components.

    On the Arduino coding side, we plan on supplying well commented code for teams to flash to the board (very simple process and as ever documentation will be provided). This code will run as is but intentionally has room for expansion by teams, both to improve the accuracy of measurements and to add features.

    (regarding measurement accuracy, the provided code will be generic to all boards, but each board will be slightly different due to tolerances, so for accurate measurements it's best to build the board, make measurements and 'tune' the code appropriately)

    As for driver distractions, the app currently has a few data displays, one being a simplified one showing four variables. For ultimate non distraction it would be possible to connect the phone and leave it in the drivers pocket (or somewhere out of sight) just for the logging.

  • Hi Ruds, Griff, and all @JLR,

    Please also add me to the distribution list -
    bking at richardlander dot cornwall dot sch dot uk...

    Thanks,

    Ben

  • One of the great things we learned in Greenpower was how changes to rolling resistance and aerodynamics affected energy consumption. To find out the effects of change you need to produce a consistent 'measure'. This isn't easy, but settling on Wh/mile was quite good - however you will not necessarily achieve the same Wh/mile over all venues, plus the effects of speed, wind and rain come into play as well. For those just joining Greenpower ask yourself, "How much energy do you want left in the batteries at the end of the race?". Then consider what affects getting to that value. All good stuff to be thought about on these dark nights in front of an open fire.
  • Hi OldTimer, that is a very good point.
    The app currently doesn't give a measure of efficiency although obviously logs the data to make it possible in post processing. Ben is on the case and adding it now - we were thinking an instantaneous measure of Wh/Km (We're going SI units) over the last 5 seconds of driving and also a per lap average in the lap view.
  • Hi Griff - instantaneous is good too - perhaps you might have two averaging periods, one over a time, and one over distance (both user configurable). That way the user can see the effects of too short an averaging period i.e. noisy result, and be able to set the distance to either a course lap or any distance they fancy. Good idea re SI units - I'm trying to get away from Imperial Units but its a slow process!
  • SimSim
    edited March 2016
    How are people out there measuring RPM on the motor shaft for data logging, such as with the Arduino?
    Aren't there three common methods:
    * Broken beam IR (bit awkward as you have to haven an emitter and detector at either end, extra wiring)
    * Hall effect (glue magnet on the shaft and use hall effect sensor, ok but magnet has to be accurately aligned with sensor and not get knocked and/or fling off)
    * Reflected IR (detector and sensor next to each other, reflective tape on shaft)

    Once this is sorted there is the issue of counting the revolutions. Presume most people use a micro and interupts for this although it would be nice if it could be converted to a voltage that could just be read by the Analogue to Digital Convertor. That would put it in the same bag as all the other measurements.

    I am leaning to reflected IR but tests with IR LEDs show it has a shockingly short range of millimetres even with the LED overdriven.
    We would be interested to hear what peoples thoughts are?
  • I've played with broken beam in an old uni project, and Hall Effects for everything we've done greenpower related. Of the two the hall effect sensor is far easier to set up.

    For attaching magnets we've either used drilled recesses and glue (not on the motor shaft itself due to regulations) or just placed them and wrapped electrical tape around them. It looks like a bodge but has proved to be pretty robust!

    Alignment hasn't really been an issue... the sensor needs to be close to the magnet, we've made little plate aluminium brackets to hold it and not had too much trouble. Having neodymium magnets helps increase the triggering range.

    I'd be interested to hear how you get on with reflected IR - I've not specifically looked into it but as you have a sender and receiver it already seems more complex than a hall effect to me... Do you have to consider protecting it from dirt/cleaning it at all? (I should probably google...)

    As you guessed, we've used interrupts to count the pulses. I don't really see any other way without additional circuitry. The pulse received from the magnet is very short and if it were being sampled raw on a microcontroller pin the microcontroller would have to be spending all it's time just checking that pin - if it were busy when a pulse occurs it would easily miss it - interrupts make a far more elegant solution.
    For all other signals going into the microcontroller it's the voltage we're interested in, whereas for the wheel and motor speeds, it's the timing we're interested in. The only way I'm aware of to detect accurate timing of signals on a microcontroller is through interrupts.

    In our code each pulse detected adds to a counter, each second that counter is read and reset. Divide this by the number of magnets on the shaft and you get revolutions per second.
  • Hall effect switches are the easiest and most reliable nowadays. I have used slotted wheels/opto switches but these suffered with sunlight problems and needed careful mounting and setup. I've also had some success with inductive sensors but these can be expensive. Regarding interrupts - its the most appropriate way. Sensing changes electronically can be done using either software polling or interrupt techniques. For slow, linear changes polling is best. For moderate speed digital changes, interrupts are best. Just a reminder of the old adage "If you don't measure it, you can't control it". The more you measure, the more you can learn. Measurements are essential to be able to assess changes you make that affect the rolling resistance and drag coefficient of the car.

    Once you have made loads of measurements, evaluated changes and perfected the car's design then you will surely be in the top ten, and be in favour of the KISS principle...but that's another story....
  • Thanks for such comprehensive answers guys. I think the reason I thought IR would have been so good was the increased range but reading through your responses you are right it sounds like I am making it too complicated. I think you are right hall effect is by far the simpler solution. I think what was putting me off hall effect was the magnetic reed switch on my bike computer. I know it is different technology but in my experience takes a bit of accurate alignment to set up and then one day gets knocked and you get the grief of having to set it up again.

    What sort of distance do you have been the magnet and the sensor in your solutions? Are we talking 5 mm?

    My question about the interrupts was a bit loaded as I was fishing for a solution that didn’t use a micro. We have set up a motor test rig as school for the students to test their motors with. It is pretty much the same as the Chipping Sodbury motor test rig:
    http://www.greenpower.beamweb.co.uk/files/RotaryRacer/MotorTesting.html.
    Only difference is that we have used an Oldham shaft coupler to make it a bit safer to avoid the need for chain drive. I have wanted to get all the data logged from it with the pico dataloggers that the school have. Problem is that you can log all the useful parameters but not RPM.

    Think I have the solution now. Found this:
    http://www.555-timer-circuits.com/datasheets/555an.pdf figure 18.
    A tachometer using a 555. Basically connect this to the sensor, set the minimum pulse duration to 2 ms (should be good for 3000 rpm with a 6 mm diameter magnet) by changing R4 to 22K. Rather than a meter put a 1N4148 diode and RC network on the output and it should then give a dc level that reflects the RPM. Bit more complicated than a micro and interrupts but may serve our purpose and keeps it simple/ish for the students.
  • 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!

    Matt will be doing a blog post about the data we managed to gather in the next few days buy I thought it best to at least add to this forum post for everyone that was interested.

    We had great success with out 2 hour test using the 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....

    To wet your appetite here is a video I did about the use of the eChook Nano at the end of the 1st race.



  • edited May 2016
    I'm really taken with the Arduino nano & am using a batch of them for battery balancing on a big EV project I'm doing, and for controlling an ebike. Just noting some basic information for would be users:
    1) you can buy the nano on ebay for as little as £1.50. These cheap Chinese copies need a different USB serial driver but once this is installed it's happy days (business as usual).
    Except the board now resets whenever you connect USB - would this be a problem?
    2) On the ebike I'm making a speedo with a needle (old fashioned but user friendly) by using a small radio control servo. These are as little as £1.50 (again) - google "hobbyking". To drive the RC servo you'll need the "PWM" library (search the Arduino help, or google might be more useful) - use the 16 bit timer (pins 9 & 10). I set the timer up for 50Hz and use "analogWrite" to set the servo position: full range is 65 to 295 in the analogWrite command and that gives 180degrees on the servo. The 50Hz timer I also use as the main control "heartbeat"
    3) default voltage reference on the nano is the 5V supply - you might find things work more predictably if you set the analog reference to "INTERNAL". The reference is then a proper 1.1V band-gap reference, but it's 1.1V so you will have to rescale analog signals. The 5V moves quite a bit (external 5V? built in 5V regulator? 5V from USB?)
    4) for motor rpm, you can use a hall sensor and count the revs over 0.6 second (add 2 zeros to get rpm). For car speed take the wheel sensor into an interrupt (pins 2 or 3) and use the millis() function to directly measure the milliseconds it takes the wheel to rotate, A single division gives you a very accurate speed every turn of the wheel. This same system might give better rpm performance, but might over-stretch the processor...
    Hope some of that might be useful :)
  • PS - loving the bloot connection to the iPhone - I'll bend your ear about that if I see you at one of the races (I didn't go to Rockingham)
  • PPS - if you use the internal 1.1V reference your ADC resolution is about 1mV. You would get around 1A accuracy from a 1milliohm shunt. If you're worried about £15 to £18 spend on a hall effect current sensor, use a 20p shunt resistor instead. Power loss in a 1mohm shunt at 20A would be 0.4W (about 0.1%)
    Just a thought. You can trade off power loss against accuracy.....
  • We've always used these current sensors.

    http://www.devicecraft.com/DataSheets/HallEffectCurrentSensor_IS-19and20.pdf

    They cost $5.50 each and postage is $10, so a batch of 9 would work out at a little over £4 each. Usually takes about a week for delivery.
  • edited May 2016
    The cheap 'Arduino' Nano's are excellent, although cheapest I've found is around £2... so pricey! :p

    The Arduinos we're using on the eChook board are indeed the cheap chinese ones. Resetting on USB connection has no affect as we're not using it other than for flashing the software.

    We're using a DCDC buck step down power module based around an LM2596 for the 5v signal, followed by a 1500uF low ESR smoothing capacitor. The step down modules are about 70p each, so keeping things cheap, and from using them in other projects seem robust. While I've yet to actually check the quality of the output with the low ESR smoothing cap, earlier tests with a 1000uF electrolytic cap showed a ripple of <10mV on 5V @ 200mA. That's 0.2%, so should be acceptable. The 1500uF Low ESR Cap should make things better again, and the readings we have been getting are pretty stable.
    The code also includes a global reference voltage modifier variable, so if the power supply isn't set to exactly 5v, it's easily compensated for in code.

    We could have used the 1.1v internal reference, but the signal to noise ratio is bad enough with a 5V signal and we already have heavy filtering on each input to get sensible readings. Decreasing the SNR to improve reference voltage accuracy, when the 5V reference is relatively good is probably a bad trade off - having said that, we haven't tested it so may well be proved wrong!

    While part of the idea of the phone is to negate the need for extra instruments etc, all the unused pins on the arduino have been forwarded to an expansion header, so custom gauges would be easy to implement with a few lines of code - they would look awesome.

    The bluetooth connection is actually to android - that's just a very iPhone-esque android phone. The HC-05 bluetooth module on the Arduino side is very easy to interface with and simply provides a bluetooth serial interface. The arduino sends out USART packets and these are converted and transmitted over bluetooth. Pairing and connection handling is managed for you. The less easy part is the Android App, this depends on your ability with Java!

    Ian is more familiar with the current sensors than me, however the expensive one's we've been working with have a reference output and signal output, I believe to compensate for drift over time. It is possible to use a cheaper single output sensor with the board, it will just need a wire added to bypass the differential amplifier stage for the expensive sensor to feed the output directly to the arduino. I'll make sure we pop instructions for this in the documentation! (Ian may well be along shortly to correct me on the current sensors...)


  • edited May 2016
    Thanks Griff. I must say I've been amazed by the repeatability of the nano ADC regardless of which reference. I moved over to the bandgap reference because readings changed significantly when USB was plugged in, or external DC/DC converter power and it was throwing the battery balancer all over the place. It's just a happy coincidence that the range is then very suitable for direct shunt measurements.
    I'd better explain the "a shunt costs 20p" comment; when I looked for shunts they were all ridiculously expensive so I bought a metre of "constantan" off ebay for a quid (which will make several tens of shunts. Resistance wire comes in nichrome, constantan and manganin (plus many others I'm sure). Nichrome just won't solder, so it's hard to use. Constantan is mostly copper so it solders just fine. I'm not sure about manganin, but it has even more copper in so it should be better.
  • edited February 14
    Apologies for the lack of updates from the echook team. The team have been very busy buying houses and preparing to have babies (who knew this would take so much time up!). I have very limited excuses but have at least kitted out the weChook racing workshop with a Myford ML10 lathe so hope to learn some new skills for use in GP racing, you're never too old to learn something new!

    Finally though some good news. We have designed V1.1 of the board which will be fabricated in the next few weeks. We are still in discussion with Siemens about how to distribute these on a larger scale but our pre-production run should yield 10 boards that hopefully teams will be able to use and test this season.

    V1.1 vs V1.0
    We have removed some of the less useful components on the board which has reduced component count slightly reducing overall complexity a bit. Mostly we filtered everything in hardware in V1.0 but have realised this is overkill for some of the inputs that can easily be digitally filtered where required.

    Power connector is now a smaller pitch than previous, we were worried about users plugging the power cable in to an incorrect connector and potentially damaging the eChook. All other connectors have the same style and pinouts to make the new board as compatible as possible with the old.

    We have designed our own 5V switch mode regulator. We had some quality control issues with the previous chinese sourced daughter boards.

    The layout has been changed so that the components are all on top leaving all the soldering to the bottom. I have also increased the pad sizes where possible. These changes should make the board much easier for small hands/beginners to solder. I will do a build video once I have one in my hands!

    The board has been made slightly smaller overall. The bluetooth module is now to be 'off board', connected by wire, we had some occurrences where the bluetooth module was too easy to dislodge during racing on V1.0. Hopefully this way we will see the design of some great cases that incorporate a slot for the bluetooth module (get those 3D printers heating guys!).

    We will do our best to keep updates a bit more regular from now on.....in between stripping wallpaper in Rowans house...!
  • v1.1 eChook Nano protos have arrived at weChook HQ!



    I will keep everyone updated as we test these boards and can hopefully get some out to eager teams shortly
  • Hi guys, where's the code kept now codebender has retired?
  • Hi Killerwhat,

    Codebender (rip :( ) is still hosting old sketches, and as we haven't made any updates since codebender retired, that is still relevant.

    I have put a copy of the code on the Arduino.cc online IDE and any updates will be pushed to there as a temporary measure. Longer term I need to pop it on a Github repo.

    Code on arduino.cc here: https://create.arduino.cc/editor/Gryphonic/d4c5cd26-3a28-4a1d-af01-38d0471f027b/preview

    Cheers :)
  • Hi all,

    Just a brief update. There's been a bit more of a delay to the new boards as after ordering them we found a far more elegant/robust/low cost solution for the power supply stage, so after some testing have re-ordered the new boards - being manufactured as I type :)

    Also some code updates as promised - we're now on a github repo: https://github.com/RJPGriffin/eChookArduinoNano

    From now on all the latest versions of the code can be found there. Latest change enables the button inputs for cycling the view in the app and setting the misleadingly named 'Launch Mode'.

    It was great to hear there were a few boards running in the practice sessions, hopefully you've found the data useful :)
  • Further update for anyone using the code - All calibration variables have been removed from the main code and stored in Calibration.h. This way you can copy in any future code updates without worrying about your calibrations - just keep your calibration.h file safe :)
Sign In or Register to comment.