Coder Social home page Coder Social logo

gevcu's Introduction

GEVCU

Note - If you have pulled this code between July and Sept of 2016 then you received commits that have been removed from this repo. It has been decided to move development of GEVCU6 code over to the GEVCU6 repo. If you have the commits from that multi-month window then point your origin to the GEVCU6 repo instead and everything will still be there and be correct. Sorry for any inconvenience this causes.

Generalized Electric Vehicle Control Unit

Our website can be found at : http://www.gevcu.org

A project to create a fairly Arduino compatible ECU firmware to interface with various electric vehicle hardware over canbus (and possibly other comm channels)

The project now builds in the Arduino IDE. So, use it to compile, send the firmware to the Arduino, and monitor serial. It all works very nicely.

The master branch of this project is now switched to support the Due. The master branch is sparsely updated and only when the source tree is in stable shape.

The older Macchina code has been moved to its own branch. This code is now VERY old but should work to control a DMOC645.

ArduinoDue branch is more experimental than the master branch and includes the work of Michael Neuweiler.

The WIP branch is sync'd to EVTV's official changes and as such could be considered as a testing ground for the official source code distribution.

You will need the following to have any hope of compiling and running the firmware:

  • A GEVCU board. Versions from 2 and up are supported.
  • Arduino IDE 1.5.4 - Do not use newer versions of the IDE
  • due_can library - There is a repo for this under Collin80
  • due_rtc library - Also under Collin80
  • due_wire library - once again
  • DueTimer library - and again

All libraries belong in %USERPROFILE%\Documents\Arduino\libraries (Windows) or ~/Arduino/libraries (Linux/Mac). You will need to remove -master or any other postfixes. Your library folders should be named as above.

The canbus is supposed to be terminated on both ends of the bus. If you are testing with a DMOC and GEVCU then you've got two devices, each on opposing ends of the bus. So, both really should be terminated but for really short canbus lines you will probably get away with terminating just one side.

If you are using a custom board then add a terminating resistor.

If you are using the new prototype shield then it should already be terminated. The DMOC can be terminated by soldering a 120 ohm resistor between the canbus lines. I did this on my DMOC and hid the resistor inside the plug shroud.

This software is MIT licensed:

Copyright (c) 2014 Collin Kidder, Michael Neuweiler, Charles Galpin, Jack Rickard

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

gevcu's People

Contributors

cgalpin avatar collin80 avatar jrickard avatar neuweiler avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gevcu's Issues

Installing on Arduino Due to Control late model car?

Hello, me again.
We are converting a late model car which has a stock ECU and would like to replace it with the GEVCU.
Can it control ABS?
Can it export data to the cluster and speedometer so that it works?
Are these pins correct for Arduino? Pins 9/10 are canbus high and low?

Pin 1 - +12V Input
Pin 3 - +12V output for first digital input
Pin 7 - EXT GND connection to chassis ground / Battery - (in my case)
Pins 9 & 10 - First canbus
Pin 19 - Gnd connection for first and second analog inputs (Throttle)
Pin 20 - First analog input (Throttle)
Pin 21 - Second analog input (Throttle)
Pin 22 - Third analog input (brake / testing input for me)
Pin 23 - Fourth analog input (test pot on my wires)
Pin 24 - +5V power for first and second analog inputs (Throttle)
Pin 26 - +5V power for third and fourth analog inputs (test pots for me,
probably brake transducer for you)
Pin 30 - Gnd connection for third and fourth analog inputs (Brake / Testing)
Pin 32 - First digital input. Tied to pin 3 above through a switch

I used a gnd at pin 19 for one of the gnds. It really doesn't matter
which one you use. All four (19,29,30,31) are equivalent.

GEVCU-4 v5.220 stopped working

Just stopped working on an EV with the Azure Dynamics motor controller.

Web page is greyed out when in the car and when on the desk but has a heartbeat on serial monitor and I have re-loaded the original code successfully.

Any help is appreciated.

Merge good stuff from ArduinoDue branch into WIP branch

The official EVTV branch is now based on the WIP branch and not the ArduinoDue branch. However, there were valuable commits to the ArduinoDue branch that should be backported to the WIP branch. So, this will now commence. The inverse should also happen - porting relevant changes to WIP into the ArduinoDue branch. There are some philosophical differences between the two branches but the majority of the code is the same.

Output 4 does not work

It appears that output 4 is inoperable on GEVCU4 hardware. Attempts to set the pin state high seem to be ignored. This pin corresponds to D2 / TIOA0

Test on additional hardware and track down whether this pin is allocated to hardware by some part of the code base.

Joystick mode

Add a mode where the input is joystick style - It would still be an analog input POT but one centered in the range. Values much over the center range cause forward motion. Values much under it cause reverse motion. This control scheme is used in boats and could be used for cars well but tends not to be.

Implement speed mode for supported motor controllers

Early on testing used speed based mode for the DMOC. This was quickly switched to torque based mode as that is more common in cars. However, some people might want to control the speed of the output shaft instead for things like boats or to implement cruise control. So, allow speed based control to work for DMOC and other controllers that can be so controlled.

Throttle difficult to use with single pot pedal

If the pot pedal object is instantiated with two ADCs but you only have one throttle pot then bad things will happen as it will still try to use the second one. The code needs to look at calibration data and ignore the second ADC if the calibration reads 0.

Better debugging facilities

Currently it can be tough to figure out why something is not working. For instance, why is the motor controller stuck in neutral? What is causing it not to be in drive or reverse? The end user has no idea. Presumably something in code is doing it on purpose but the end user has no way of knowing what they can do to correct the situation. As such, it would be good to augment the code with facilities to provide better debugging information. This could be done via OBDII style fault codes. For instance, if there is a throttle problem in an ICE car you might get P0220 which means that there is a problem with the throttle position sensor. In fact, we should output that exact code when there is a problem with the throttle position sensing.

Doing this probably requires that we have a buffer for errors that can be read by a connected OBDII device (or listed on the web page or dumped out on the console).

This could end up being a huge amount of work to do it right. But, without extensive support for diagnostics we'll never be where we should be and users will be stuck guessing why things don't work.

Use this on an electric car

I am working on a college project that needs a whole CAN bus system to control a car. The messages will be generated by a computer and send to the controller and then actuators . Can this project be used for my project? note: currently the car have no ECU or CAN bus system

Simple configuration of more devices

Currently it is possible to configure generic throttle and motor controller parameters via the web interface. But, other devices exist. It should be possible to configure charging voltage and current for chargers. It should be possible to configure the DC/DC bus voltage for the accessory (+12V). Maybe not all chargers or DC/DC converters can be thus configured. In that case they're free to ignore the settings. But it might be nice to still be able to set a basic list of generic and mostly shared settings for each device type so that people can quickly configure their car from the web interface. More advanced configuration can be done on the serial console.

Deadzone at top of pedal travel

This is only sort of an issue not necessarily a bug since I did it on purpose during testing. The pedal commands nothing at the very top of pedal (while not being pushed). There is no regen, no forward torque, no anything. This will eventually be configurable as some vehicles will need standby torque for an automatic transmission and some people will want max regen from accelerator at the top of pedal. But, right now it does nothing. This issue will be closed once the proper behavior is implemented.

Latch up with canbus

If the canbus gets disconnected (or starts disconnected) and then later reconnects then the firmware will lock up.

Switch to ADC values on status page of website

Currently the status page shows throttle percentages. However, this is unhelpful when one is setting up the throttle parameters. It would be helpful to instead list the actual ADC values so that these values could then be used for setting up the throttle range.

iChip buffering is suboptimal

The buffer used to be 32 positions in size and that was not large enough. It has since been updated to 64 but it uses String objects and they might use dynamic memory. Look into this. Also, sometimes it might be necessary to block access to the buffer until a certain set of commands has been processed.

Add configuration for default IP and SSID

The new wifi modules support AP mode. The older modules could be flashed with special firmware for AP mode. Either way it'd be nice to be able to set the default IP and SSID so that multiple GEVCUs can be in the same general area without conflicting. Actually, being able to set the security is necessary as well. Not everyone will want open wifi on their GEVCU.

Throttle calibration inoperable with queued timer

Recent changes to implement queuing on the timer ticks causes the throttle calibration to fail. It will stick at whichever throttle value was current when the calibration was started - the throttle value never updates. Proper operation returns of queuing is disabled.

Problems with 1.5.6 Arduino IDE

The firmware seems to experience random hard freezes if compiled under 1.5.6. As such, don't try to do that right now until the problem is corrected either on our end or Arduino's end.

Build Errors on a Seeduino v3.0

Is the Seeduino v3.0 a supported platform?
I am a newbie who does not yet have a CAN shield. I tried checking out the ArduinoDue branch of the GEVCU code with 1.5.4. IDE and encountered the following errors. I obviously am doing something wrong but did import the required libraries mentioned in the main GEVCU README.md
I don't seem to have the file variant.h
Thanks in advance for your support

In file included from /Users/anand/Documents/Arduino/libraries/due_can/due_can.h:72,
from config.h:35,
from BatteryManager.h:33,
from BatteryManager.cpp:29:
/Users/anand/Documents/Arduino/libraries/due_can/sn65hvd234.h:28:21: error: variant.h: No such file or directory
In file included from config.h:35,
from BatteryManager.h:33,
from BatteryManager.cpp:29:
/Users/anand/Documents/Arduino/libraries/due_can/due_can.h:160: error: ISO C++ forbids declaration of 'Can' with no type
/Users/anand/Documents/Arduino/libraries/due_can/due_can.h:160: error: expected ';' before '' token
/Users/anand/Documents/Arduino/libraries/due_can/due_can.h:180: error: expected )' before '_' token In file included from MemCache.h:35, from PrefHandler.h:35, from Device.h:34, from BatteryManager.h:34, from BatteryManager.cpp:29: /Users/anand/Documents/Arduino/libraries/due_wire/due_wire.h:37: error: expected )' before '
' token
/Users/anand/Documents/Arduino/libraries/due_wire/due_wire.h:99: error: ISO C++ forbids declaration of 'Twi' with no type
/Users/anand/Documents/Arduino/libraries/due_wire/due_wire.h:99: error: expected ';' before '_' token

Gevcu looses halve of the programmed data

Hi, the GEVCU has lost halve of the data (throttle settings like min max of T1 are still stored, but lost are: All digital inputs and outputs, battery voltage, torque, precharge delay.
This happened now the third time and I need to reprogram the controller with the data, to go ahead whith driving.

Is this behaviour known? How can I solve it? Im driving the car since december and in happened in total three times, just occasionally.

Additionally, I can only reprogram it with some computers, but not with my android 5 phone. It doesn't find the gevcu.

Torque slew rate is slow

This issue could be either in the GEVCU code or in the DMOC or both. When you step on the throttle it doesn't quite respond with the proper haste. There is a lot of throttle smoothing going on on the GEVCU side so that might be the cause or the DMOC might be limiting torque slew rate. This should be investigated and solved one way or the other.

Non-Coda UQM

I have seen hints in various forums that you were considering adding support for non-Coda UQM controllers. Do you have an outline of the work that needs to be done and perhaps some hints so I could take on this project?

Thanks

PWM outputs

GEVCU5 boards are capable of PWM on the outputs but there is currently no support for this functionality in software. It would be nice if it were possible to set up a PWM map on the GUI interface that allows the end user to calibrate the PWM output to how their gauge works.

Ability to enable/disable devices from the website

Currently it is required to use the serial console to enable or disable devices. This is problematic for people who aren't well versed in handling serial consoles. It would be useful if a list of devices appeared in the website and could be checked or selected such that devices could be enabled or disabled as needed by the end user.

Easier firmware uploading?

Right now the only real way to upload a new firmware image is to compile it yourself and click Upload in the IDE. There are other IDEs that can do this and it is technically possible to do it from the command line as well (I have done this). However, all of that is terribly far from user friendly. Because of this a lot of projects end up writing custom bootloader / firmware updater code to allow for an easier pathway. We've got wifi and might feasibly be able to support remote firmware upgrades like the iChip wifi modules can do. We do end up making a lot of changes to the code so allowing end users to easily update would likely be handy. Is there any interest in this?

IChip parameter loading code locks up

There seems to be two ways to lock up the initial parameter setting. The first one is to try to change the logging level while the ichip is active. The second is to not be in loglevel=0 when the system starts up. Both are big problems. This happens with the code in the ArduinoDue branch.

Webpage often doesn't work properly

It has been reported (And I believe I've seen it myself) that often the webpage on the ichip module won't work quite properly. It won't load all tabs. It will sometimes get better, or at least different, upon upload of the web pages again. Reloading sometimes changes which tabs work.

Investigate serial buffering between MCU and IChip

Arduino 1.6.0 includes new code to implement serial TX interrupts. This allows serial writing to be non-blocking most of the time. However, no one knows for sure how this has affected the ichip interface code. Are we filling up the TX buffer? How often does it block if so? Can some of the complications in the ichip param updating code be removed now?

Possible EEPROM corruption

There are reports that sometimes after power cycling the values retrieved from EEPROM will be different for the throttle control variables. This can cause unintended acceleration events. Further testing is required to isolate the issue.

Compiling Code Throws Warnings

Colin/Jack:

When compiling the GEVCU code, the latest version of the Arduino IDE (1.8.11) throws the following errors when writing text strings, logging, etc. - several dozen actually. (see below the fold)

obviously these are warnings and the code will still compile, but pretty cumbersome having to debug around these. appears to be a syntax issue between C/C++. one approach might be to use
const char* vs. char* in each of the declarations -- the issue is primarily setting commonName and when sending log messages -- there may be others, but that's as far as I've gotten through all the warnings.

your thoughts on whether this is a really BAD idea or other options you might suggest - as you've been closest to the code throughout.

note: I'm loathe to suppress the warnings in the IDE, etc. for obvious reasons, but if that's the only practical option...


sketch/CanBrake.cpp: In constructor 'CanBrake::CanBrake()':
sketch/CanBrake.cpp:40:13: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
commonName = "CANBus brake";
^
sketch/CanBrake.cpp: In member function 'virtual void CanBrake::setup()':
sketch/CanBrake.cpp:46:71: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
Logger::info("add device: CanBrake (id: %X, %X)", CANBRAKEPEDAL, this);

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.