Simple Arduino Throttle Interface - Now for ESC

gtadmin

10 kW
Joined
Aug 7, 2009
Messages
744
Location
Whyalla South Australia
Hi Guys,

As part of the discussion on Adrian's <1Kg Friction Drive I mentioned that I begun a similar implementation for my hub motor, but I would only make that code available (ie a new thread) if other ES'ers were interested in it. A couple of PM's later and here we are.

Firstly, I haven't bought any hardware yet and this is still theoretical, but that will change in the near future once I work out the bits'n'pieces. Also, I am NOT an electronics type of guy, so I will require some guidance in choosing components etc.

So I downloaded the IDE from Arduino's website, rolled up my sleeves and ....

Notes on the Arduino and IDE

The Arduino IDE V0022 behaves strangely when adding extra "tabs" representing other files in the sketch. I started converting my use cases to code and needed to add a reference to the EEPROM library. You do this by using a "#include <EEMPROM.h>" statement at the top of the code page. However, I couldn't get that to work unless the EEPROM.h code file was to the left (in the tab order) of my code file. This applies to other "includes" as well :x

To overcome this, I've added the tabs (files) in this order: Description.pde, EEPROM.h, Sounds.pde, Declarations.pde, Functions.pde, StartUp.pde and lastly MainLoop.pde, and the IDE is :) in that it compiles.

Another gripe I have is that the font size is way too small for my eyesight (especially the status area) and the error status is red text on black background which is almost impossible for me to read. This means (in the first instance) that the code is written in a text editor, then copied and pasted into the appropriate file for compiling. Squinting badly helps with the second :x

The last note I have is that I'm used to writing event driven applications, not those that loop continuously, so there may ( :roll: ) be some errors.

Cheers,
GT
 
This is a software solution and will be less accurate in it's implementation than a hardware solution would be. But I'll leave hardware solutions to the Lecky-Techies ...

I had written about 25% of what I would expect to be the total code required when I received the PM's. This has led me to write some use cases before recommencing the code. Please feel free to add to / help solidify these. Here they are ...


/*==========================================================================================
Arduino Throttle Interface
============================================================================================

This describes the Use Cases for this "Sketch" [as Arduino refers to source code ;) ]

The aims of this "sketch" are to provide a simple system that acts as a "Big Brother" monitoring and control system, whilst enabling the simplest of user controls.

It is most relative to those of us who use their bicycles as low powered commuters*, which probably excludes those who choose to use RC motors. In fact, this is only written to provide a throttle input into a XeiChang (AKA Infineon) type controller (one whose speed is controlled by varying the throttle input between 1.0V and 4.2V). There are two reasons for this:

1. I am using a hub motor and not a RC motor (at least not just yet anyway ;) )
2. adrian_sm's "Commuter Booster - <1 kg Friction Drive" has this implemented. I don't
intend on re-inventing the wheel (although 1. may influence this).

This does not mean that you can't modify it to control an ESC for RC motors - you can :)
[If you do, please either post it here or PM me if you wish it to remain private]

As this is open source, instead of providing a myriad of configuration switches, constants are used throughout the "sketch" to configure user parameters. Each one is documented in it's intended use and suitable values. Comment out those that do not apply to your circumstances.

* Upto 2kW is considered low powered in this context

============================================================================================

Push-button throttle

A push-button throttle provides several advantages over a normal throttle. These include:
1. The reduction in throttle variation while riding over undulating / corrugated surfaces,
which causes the rider's hand / thumb to vary the throttle. However, I don't think this
is a major consideration for lower powered commuters.
2. Eliminates the need for the rider to continuously operate the throttle
3. Eliminates breakages of normal throttles caused by [1] and [2]
4. It has the greatest reliability due to it's simplicity (less moving parts)
5. It is (probably) legal in countries where a normal throttle is not, as a push-button is ON/OFF.

============================================================================================

UC01

Pushing and holding the throttle button whilst pedalling, quickly ramps the output signal from 1.0V to 4.2V until the bike reaches the rider's preferred "cruising speed", where the rider releases the button. The bike then maintains that speed, including whilst climbing hills, until the rider stops pedalling.

UC02

Resumption of pedalling accelerates the bike up to the previous "cruising speed" without the rider having to push the throttle button. The bike must already be moving for the resumption to be immediate.

UC03-4

The previous "cruising speed" can be overridden during resumption by the rider pushing the throttle button, either momentarily to set a lower "cruising speed", or continuously to increase the previous "cruising speed".

UC05

To prevent accidental activation of the resume function, pushing the throttle button while depressing a nominated brake lever resets the "cruising speed" to 0. To disable accidental activation without resetting the speed to 0, the brake lever is depressed.

UC06

An alternative strategy to UC05 is to enable resume only after a minimum speed is obtained, and 7.5kmh is the suggested speed. Pressing the throttle button below this speed resets the "cruising speed" to 0.


============================================================================================

UC07 (Normal throttle)

The use of a "normal" throttle does provide an advantage over a push-button throttle in that the speed and rate of acceleration of the bicycle are under direct rider control.

However, unless you are performing one or more of UC08-UC13, using this throttle interface just adds complexity for zero gain.


============================================================================================

Monitoring and control

UC08 (Piezo buzzer)

A piezo buzzer (OT02) will emit sounds indicating several conditions, including error conditions. It is yet to be determined whether to indicate each individual error as a different sound, or just one sound for all error conditions.


UC09 (Battery Load)

Battery load will be monitored through a sensor. This enables other functions (UC10, UC11, UC13). It also allows us to provide a "fuel tank" gauge in the same manner as previously described by Jeremy Harris ie by calculating amp-unit seconds used and subtracting it from the total pack's amp-unit seconds. This value is stored in EEPROM.

The "sketch" includes all the code required for this other than the driving of the gauge itself.

** What sensors are available and where do I get one from in Australia? **


UC10 (Phase Load)

Phase load isn't measured by this "sketch" but calculated as a function of battery load and bike speed. Exceeding the phase load limit will reduce the throttle output.

** User input is invited to determine this function. **


UC11 (LVC)

The controller I am using with my 12S LiPo pack is set at 31.5V (2.625V per cell), which is well under the safe voltage for a LiPo cell. The controller could be modified to increase the LVC, but using software LVC provides greater flexibility (and much quicker to change).

There are three set points in the "sketch" that trigger actions based on the pack voltage (and therefore cell voltage).

The LVC-H (nominally 3.7V = analog757) reduces the throttle output until such time as the voltage rises above the set point.

The LVC-M (nominally 3.6V = analog736) reduces the throttle output until the battery load falls to 7A.

The LVC-L (nominally 3.5V = analog716) provides 0 throttle output.


============================================================================================

UC12 (Power on mode)

On power up, two push buttons may be pressed to:
1. Reset the battery capacity to "full"
2. Bypass the Oz Legal Mode for off-road use only :)

Upon successful start up, the piezo buzzer will sound indicating OZ Legal mode (UC13), or off-road mode (which also indicates legal mode in other parts of the world)


============================================================================================

UC13 (Oz legal mode)

To be legal in Australia, the assistance provided by the motor to the bicycle must be controlled by pedalling, be limited to a top, assisted speed of 26kmh, and to provide no more than 200W assistance.

To implement "controlled by pedalling", the act of pedalling is defined here as having rotation of the cranks of at least 10rpm.

To limit the motor power to 200W requires the battery load be limited to 7A.


===========================================================================================

IO

Digital Inputs:

DI01 - Pedal sensor: This is usually implemented by having a hall effect sensor mounted on the bottom bracket with a rotating disk mounted to the crank shaft. The hall sensor picks up the magnets' field as each magnet passes the sensor, providing a pulse. This pulse will be input to one of the Interrupts (0) to ensure the pulse is caught by the sketch. Note that Interrupt(0) is actually digital pin (2).

DI02 - Speed sensor: This is usually implemented by having magnets mounted on the spokes of the wheel, and having a hall sensor mounted in close proximity to the path the magnets take whilst the wheel is rotating. The hall sensor picks up the magnets' field as each magnet passes the sensor, providing a pulse. This pulse will be input to one of the Interrupts (1) to ensure the pulse is caught by the sketch. Note that Interrupt(1) is actually digital pin (3).

DI03 - Push-button throttle: Any spring return, momentary contact switch will suffice. Naturally, one that is designed (or easily modified) to suit bicycle handlebars is preferred. State signal connected to digital pin (4)

DI04 - Brake lever: State signal connected to digital pin (5).


Digital Inputs Power On:

DI05 - Battery Capacity Reset: Any small, momentary contact switch will suffice. State signal connected to digital pin (11).
DI06 - Oz Legal Mode Overide: Any small, momentary contact switch will suffice. State signal connected to digital pin (12).


Analog Inputs:

AI01 - Normal throttle input will be to analog input (0).
AI02 - Battery load sensor will be connected to analog input (1)
AI03 - Pack voltage will be supplied through a voltage divider connected to analog input (2)


Outputs:

OT01 - Signal input to the controller. This will be implemented on PWM digital pin (9).
OT02 – A piezo buzzer. This will be implemented on PWM digital pin (10).

===========================================================================================
*/
 
electraflyit said:
Hi,
Are you going to have a 'Current' throttle function as well.
Eddie
Hi Eddie, could you please define what "a current throttle function" means? As far as I know, to increase the current to a motor you need to create a demand for that current ie increase load, and you do that by asking for more speed = opening the throttle.

If it can be defined in another manner and have it controlled by throttle alone, I'll program it :D

Cheers,
GT
 
Here is a good current & voltage sensor.
http://www.sparkfun.com/products/10644

And for ESC throttle out, here is what you will need.
http://arduino.cc/en/Reference/ServoWriteMicroseconds

1000ms is zero throttle
2000ms is full throttle

- Adrian
 
And this link describes using hall sensors and rpm calcs.
http://www.arduino.cc/playground/Main/ReadingRPM

Note the use of the internal pull up resistors.

- Adrian
 
adrian_sm said:
Here is a good current & voltage sensor.
http://www.sparkfun.com/products/10644

...

...
- Adrian
Hi Adrian, thanks for the sensor links. The other bit; well I wasn't going to show that unless someone else disclosed it (and I wasn't thinking of you either) :p The end user of this is a hub powered commuter - me :D

Edit: on that sensor, I had looked at it and thought that I wouldn't be able to solder it properly. I also looked at a Allegro ACS756, but couldn't find an Oz supplier?

Cheers,
GT
 
Uploaded V02 of the functions & V02 of the setup and loop code. Can't actually verify that the code works as I need to get the hardware first. If someone is prepared to perform peer review it would be much appreciated.

Even better if someone can upload and test 8)

Edit: haven't added the error tones or EEPROM.write yet though!

Cheers,
GT
 
Uploaded V03 of the functions & setup and loop code. I need to get the hardware first, and I've ordered some for testing. If someone is prepared to perform peer review it would be much appreciated.

Even better if someone can upload and test 8) Now I'm not sure that this will happen given the lack of suggestions and comment in the last week :p

Still haven't added the error tones or EEPROM.write yet though!

Cheers,
GT
 
Awesome. Hope the cheap Arduino works, the price is pretty hard to beat. Let me know how it goes.

Now the real fun begins when you hit the road. As I just found out trying out my new "improved" throttle logic. :roll: And it looked so good on the screen. :(
 
adrian_sm said:
Awesome. Hope the cheap Arduino works, the price is pretty hard to beat. Let me know how it goes.
Will do once everything gets here, and I find the time (getting close with my cruiser though). Just going to run it off-bike with the RC motor and simulate with switches, at least until the next frame.

Now the real fun begins when you hit the road. As I just found out trying out my new "improved" throttle logic. :roll: And it looked so good on the screen. :(
As Pauline said "Please explain?"
 
I was just trying out my new throttle logic, that can suit both the "I want to go as fast as I can" and "I just want to relax, and cruise" riders. Code looked great on the screen, but when I tried it on the bike it behaved a bit different, didn't capture events that I expected, and so on.

No matter how good the code looks on the screen, when you try it out on the actual bike, thats when you find all the real bugs.

That's the problem when I try to develop things in spare time, I end up testing too much new stuff at once on the bike. Better off to test each element in isolation, and slowly piece it together, but it is not in my nature. :lol:
 
adrian_sm said:
...That's the problem when I try to develop things in spare time, I end up testing too much new stuff at once on the bike. Better off to test each element in isolation, and slowly piece it together, but it is not in my nature. :lol:
I know that feeling :) Now I might code the lot, but I'll rem most of it out and just take it one function at a time, prove that, un-rem the next function, prove that ...

Sorry to hear about the bugs, need a hand? (Probably not, but I'll offer anyway)
 
Nah, I was just venting mid debugging. If I get stuck I might take you up on the offer.

Cheers.
 
Back
Top