Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
elweb I-Miev / Ion / CZero
Beiträge im Thema:
12
Erster Beitrag:
vor 4 Jahren, 11 Monaten
Letzter Beitrag:
vor 4 Jahren, 9 Monaten
Beteiligte Autoren:
tbergo, me68, priusfan

Open Vehicle Monitor System (OVMS)

Startbeitrag von tbergo am 20.08.2013 10:11

The Open Vehicle Monitoring System (OVMS for short) was initially developed by a team of Tesla Roadster enthusiasts to give their cars the same remote monitoring and charging features as the Nissan Leaf electric car, the open-source project has grown to include many other models of electric car.

What is it?

The Open Vehicle Monitoring System is three things:

1] A low-cost module that fits in the car. It is powered by the car, talks to the car on the CAN bus,
and uses the GSM cellular network to talk to its user.

2] A server. The car module can be configured to either talk to the server (via UDP/IP or TCP/IP over
the Internet) or the user directly (via SMS).

3] A cellphone App. This talks to the server (via TCP/IP HTTP protocol) to retrieve messages from
the car and issue instructions.

The source code is freely available on git-hub Open Vehicle Monitor System


As an EV enthusiast i started to try adding support for our loved I-MiEV,Ion and C-Zero to have remote monitoring features as Nissan Leaf. I have started coding on a fork of the original project. As we lack information on PID for detecting status of ignition and charging, my work have stranded for some time. The fork i have worked on is available here: https://github.com/tbergo/Open-Vehicle-Monitoring-System

Renault Twizy Remote Monitoring:
How To: Give Your Renault Twizy Remote Monitoring

Open Vehicles Community Releases Electric-Car Monitoring App

OVMS HW:
http://shop.zerocarbonworld.org/ev-accessories/

My intention with this post is to invite you fellow EV enthusiasts and member of this forum to contribute with you knowledge to enabling remote monitoring and charging features to our beloved EV.

Antworten:

Hello Thomas!

Could you please explain the architecture of your solution?

You are using a server in the internet collecting all data from the cars? The collector is a special hardware black box, made by Telsa Motors Inc.?

The data can then be downloaded by the app?

So you always must be online?

If so, what about data security?


Martin

von me68 - am 20.08.2013 18:07
Just to clarify my role in relation to OVMS.
OVMS was started by a team of Tesla Roadster enthusiasts to add remote monitoring and charging features to Tesla Roadster. As more EV enthusiasts have discovered this open-source project the project has grown to include many other models of electric car. So far support for Tesla Roadster, Tazzari, Think City, Renault Twizy and Opel Ampera has been developed by the users.
My involvement is only related to make a SW module to add support for our I-MiEV, Ion and C-Zero cars. I do this as an individual for personal usage on my own car. Of course this SW module will be freely available like the rest of the project.

At the moment i'm kind of stuck as i don't have manged to discover the necessary CAN bus information related to ignition and charging status, witch is essential status information in OVMS. From the Android App tread it looks like you have managed to discover a lot of new CAN bus messages. Witch can help me and other people who are interested in adding this remote monitoring capability to our I-MiEV, Ion and C-Zero.

At Google Play you can try out the app OVMS at Google Play


To try answer your questions regarding the OVMS system I have copied the following information from the OVMS Git-Hub home page:



Open Vehicle Monitoring System


Why?

We are a group of enthusiasts who want an interface to be able to talk to our cars remotely, perhaps
add on-car displays (such as heads-up speed), and we want to have fun doing it.


What is it?

The Open Vehicle Monitoring System is three things:

1] A low-cost module that fits in the car. It is powered by the car, talks to the car on the CAN bus,
and uses the GSM cellular network to talk to its user.

2] A server. The car module can be configured to either talk to the server (via UDP/IP or TCP/IP over
the Internet) or the user directly (via SMS).

3] A cellphone App. This talks to the server (via TCP/IP HTTP protocol) to retrieve messages from
the car and issue instructions.

Part [1] is all that is required. You can use a cellphone and SMS messages to talk to the App. It
requires a SMS messaging plan on the SIM card in the GSM modem in the car.

Parts [2] and [3] provide a much more seamless and powerful experience, but are optional.
They requires a small data plan on the SIM card in the GSM modem in the car.

Even if you choose [2]+[3], you can still use [1] as well (for initial setup as well as ongoing on-demand).


The Car Module

The car module is the hard part. We require an extremely reliable and low-power module to fit in the car.
While it is relatively simple for a hobbyist to create one of these, the hard part is making a common
platform that a group of hobbyists can get behind, and to make it very high quality. Home-soldered
connections and US$100k electric cars don't go well together.

What we've done is take the foundational work done by fuzzy logic and others, to build a base platform module.
We've then negotiated with factories in China (we live just over the border in Hong Kong) to get this
professionally built.

The module plugs into the car DIAG port, which provides both power and a CAN bus connection that the module can transmit/receive messages on.

The platform itself is based on a PIC18F2680 processor and SIMCOM GSM module. Factory built and assembled, but based on an open source extendable architecture. You can either buy these modules pre-built, or build your own. Any profits on the sale of hardware will got to charity.

The SIMCOM GSM module has the ability to send/receive SMS messages, as well as a built-in IP stack for GPRS communication. It allows the module to talk both communication protocols with very little PIC software required. We decided to use these modules (rather than USB modems) for reliability reasons, as well as the SIMCOM built-in support for IP protocol.

The final version re-works the CPU+CAN board to be rectangular and fit as a plug-in piggy-back on the SIMCOM module we've sourced. We've also re-worked the board layout to separate the CAN bus across a cicuit-board divide (to keep the CAN signals very simple and physically separated from the rest of the components). In the final version, we also extend the unused I/O pins of the CPU out on expansion pins (to allow for such things as in-vehicle displays). It all fits in a small case, is extremely low power, and has two LEDs for diagnostics and a windscreen / rear window stick-on GSM antenna for optimal reception. Overall, the design is very elegant and extremely robust.

The in-car module can be configured to just be a passive listener on the CAN bus, but can also be an active participant and transmit control messages onto the bus. It can even just relay CAN bus messages over the Internet to the Server/App. It is very flexible and has enough RAM and ROM to do some interesting things.

Users can either follow the schematics to build their own compatible boards, or buy them pre-made from us. We expect to be able to charge just US$99+shipping for pre-assembled in-car modules (the CPU+CAN controller module, SIMCOM GSM module, car DIAG cable, housing box and GSM antenna). This is a non-profit endeavor, with any profits inadvertently made being donated to charity.


The Server

The server is a simple open source server which talks two protocols - one to the car and the other to
the cellphone App.

The car protocol is built on UDP using encrypted communication packets. Two passwords are used - one to talk to the server and the other to talk to the App.

If the car module wants to send a message to the server, it uses the first password. Once the server
receives the message, it can decrypt and act on the instruction contained. Communications of this type are used for network registration and PUSH notification messages to Apple/Android phones, or other alerts.

If the car module wants to send a message to the user, it uses the second password. The server has no ability to decrypt such messages, so merely passes them on to the cellphone App transparently. The cellphone App itself decrypts and acts on the message. In this way, as only the car module and cellphone App have the password, the server has no way to spy/eavesdrop on these messages. Communications of this type are used for such things as car GPS location updates.

The server also includes a web interface for basic functions such as setting the password, registering the car and checking status.


The CellPhone App

The API to the car and the server is open and will be published. Anyone can write to it, and we hope they will.

Initially, we intend to release a standard iPhone and Android App, but anyone is welcome to follow the API and write their own.


Open Source

The entire project will be open source - from the hardware schematics to the APIs to the car and server firmware.

The purpose of this project is to get the community of Tesla, and other, tinkerers to be able to expand the project. We can't do it all, and there is so much to do. What we are doing is providing an affordable and flexible base that the community can work on and extend.

Everything is open, and APIs are public. Other car modules can talk to the server, and other Apps can show the status and control the car. This will be a foundation that will hope others will interface to and and build upon.

If we can't get sufficient interest, we'll just build it for ourselves and not worry about the larger community.

This project is as an open-source extensible framework based on SMS and UDP/IP control, for enthusiasts. It is designed to be controlled by SMS, websites and/or cellphone Apps.

Thanks

So many people to thank. W.Petefish for sourcing the car connector, Fuzzylogic for the original hardware and software design and demonstration of it working, Scott451 for figuring out many of the Roadster CAN bus messages, and many others for showing that this kind of thing can work in the real world.

Please help us by answering the survey, so we can gauge interest. Any questions? Ask away...

Thanks,
markwj and foxium.


von tbergo - am 21.08.2013 11:49
Hello Thomas!

Have a look to myimiev.com/forum


Martin

von me68 - am 22.08.2013 15:25
Hello Martin

Thank you for the link.
I'm also a member on that forum and find this forum by priusfan's post.

You are probably already aware, but you can also find some information regarding CAN PID's here: i-miev-odb2

So far coded support for:
B_amp & B_volt - PID373
SOC - PID 374
ODO - PID 412
RR - PID 346

To finalize coding basic support i also need to detect if the car is charging or not and if the ignition is on or off. In your post at the canion thread you mention PID 389, charging current and charging voltage. This information can be valuable to detect charging state (if the car is charging or not). I also see form the excellent graphic in the canion app that you in some cases illuminate the READY indicator. Witch information are you using to determine when to have the READY indicator illuminated? This information will be valuable to detect the state of the car.


If you can help me provide this information, I believe I'm has sufficient information to have a first basic version of OVMS support for our EV.

I'm really thankful for your help.

Thomas

von tbergo - am 23.08.2013 09:18
Zitat
tbergo
I also see form the excellent graphic in the canion app that you in some cases illuminate the READY indicator. Witch information are you using to determine when to have the READY indicator illuminated? This information will be valuable to detect the state of the car.


Hello Thomas!

I use only the information, if canion is connected to the car for illuminating the READY indicator, as described (in german) near to the screenshot ...


Martin

von me68 - am 23.08.2013 16:28
Hi Martin

Thank you for clarifying the READY light information.

Regarding the B_VOLTL and B_AMPL in PID 389
- In which bytes is this information represented?
- Is the data formatted the same way as B-VOLT and B_AMP in PID 373?

Thomas

von tbergo - am 26.08.2013 13:21
bonjour Thomas

about PID 389:
B_AmpL = BB(6) / 10
B_VoltL = BB(1)

salutations
Xavier

von priusfan - am 26.08.2013 17:31
Thank you Martin and Xavier

Regards, Thomas

von tbergo - am 29.08.2013 08:52
The first release that support i-Miev, C-Zero and iOn is now available for testing.



Some pictures from the iOS app:









Picture of i-Miev is not available in the app, so I use the Ampera ;)

Regards, Thomas

von tbergo - am 24.09.2013 20:24
Hello Thomas!

Well done!

How do you calculate ideal range & estimated range (== RR from car)?

You also build an android version, right? Can i use it with an android device without GSM-module?

Martin :-)

von me68 - am 25.09.2013 05:58
The estimated range is the RR from the car.
The ideal range is rated range / SOC, (150km / 50% = 75km)

There is also a android version available. You will not be able to communicate with the car without the Car module. But the app has a demo mode, where you can test the SW.
[play.google.com]

Link to video of the iphone app:
[www.youtube.com]
[www.youtube.com]


Regards, Thomas

von tbergo - am 25.09.2013 11:02
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.