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.
Home Page: http://www.openvehicles.com/
License: Other
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. We will be loading up what we have onto github within the coming few weeks. 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. When will it be ready? We have been working hard on this for the past couple of months. Initial prototypes have been made and tested; and we are very happy with the choice of factory and their work. The hardware design is now being finalized and we will soon be ready to start the first production run. If there is sufficient interest, final hardware will be available within the next two-to-three weeks. If we can't get sufficient interest, we'll just build it for ourselves and not worry about the larger community. How does it compare to the Tesla Tattler? The Tattler will be an off-the-shelf product offering a purely-SMS controlled solution to controlling roadster charging (as well as other such functions). It is built on some fairly sophisticated hardware and requires no user 'tinkering' to get it working. From our understanding, you just plug it in and play. It connects to the car in the same way as OVMS, but the cellular modem is very different. 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.
Implement, and release, the base iOS App.
Need to confirm whether open-source release of this is not in violation of Apple's AppStore provisions.
Support encryption scheme 0x30.
Using the new C (command) messages, support retrieval of GPRS utilization data.
I had my kid, and we were getting out to go play in the park. As we left the car, my hands were full and I figured I would use OVMS to lock the vehicle later. When I was thinking of leaving, I was looking for the keys and couldn't find them. I thought, "I couldn't have possibly..." But yes I did. I locked the car with the keys in the ignition... with the car on!
The server module for talking to the car need to be tidied-up (after completion of TCP/IP work) and released.
Support a STREAM feature for the car firmware. If enabled, car will stream location updates while apps are connected and car is in motion.
There seems to be a bug when the car is set to performance mode.
The iPhone app will then show an ideal range of 0km and the actual ideal range will be shown as estimated range. If I switch back to normal mode everything is back to normal after the screen is refreshed. Switching back to performance mode will show the same bug.
It seems to be that the temperature display in the iOS App is fixed to Celcius. It should be able to convert to Fahrenheit if the car is set to Miles (rather than KM).
Final set of messages for v1.0 release:
1] Version and firmware status
2] Vehicle ID
3] TPMS
4] Door status
5] Lock/Unlock
And, also, better display of car identification based on VIN.
We need car firmware support for:
1] Firmware announcement (F message) of support for instructional messages
2] Instructional message support for:
- Lock & Unlock
- Set charge mode
- Start & stop charge
It would be nice to alert (SMS/PUSH) if the trunk is opened while in valet mode. Also, it is possible to pickup a glove box open even, can the glove box be opened in valet mode, and if so can we also alert on that?
Proocol 0x30 seems to have an issue decoding the server welcome message in the car firmware. Seems to loop in the hamachi code. Maybe stack related or only showing up in debug builds.
High-res phones are causing layout issues in the Android App.
eg; HTC One X
Feature suggested by foxium, and seconded by markwj (as brilliant): a parking meter.
When the car is parked, a timer is started that is visible from the App. Will show how long the car has been parked at its current location.
Perhaps an extension to this is that an alarm could be set to on the smartphone, to alert after a specified time (and automatically cancelled should the car leave parking mode.
We need server support for in-app registration of cars.
Smooth the location update display in iOS App - now we are streaming, this is required.
Implement, and release, the server-to-app API.
Increase to 16 features, and map to 8 features to top 8 parameters - to make them persistent
We need iOS App support for in-app registration of cars.
I had my kid, and we were getting out to go play in the park. As we left the car, my hands were full and I figured I would use OVMS to lock the vehicle later. When I was thinking of leaving, I was looking for the keys and couldn't find them. I thought, "I couldn't have possibly..." But yes I did. I locked the car with the keys in the ignition... with the car on!
In the NET state model, support blocking a state until a specific modem feedback is received. For example, wait for the ">" when submitting a SMS/message.
Updates to protocol and server for server-to-server replication of car records
Support timed charges in the car firmware. We need the status message to include charge mode and timing. We also need a control command to set the timed charge information.
The Android App seems to be giving "Unsupported firmware" for v1.2.5 firmware.
Message is:
Unsupported Firmware, Please upgrade vehicle module firmware to 1.1.9-exp3 or later.
We've seen the temperature data as intermittent/missing on some cars. Anecdotally, this seems better on the car firmware with interrupt-driven can bus, but we still have one car that doesn't seem to report the data.
A 'working' car shows:
D 124,0,3,34,12,16,3426,4879,0,25690
A 'missing' car shows:
D 108,0,5,0,0,0,5594,85569,0,118863
Both cars are running Tesla firmware v4.6.3 (as shown by log parser). The 'missing' car is a little older (the 'working' car is new, while the 'missing' car was delivered December 2010).
Whenever the module receives an unknown SMS message (not a command), it should forward the message to phones via notifications. This would be useful for messages like card balance alerts (pay as you go cards), and other operator alerts.
The home screen widget is showing a double battery in the case the car module has not yet connected to the server (gray, empty, battery).
We need Android App support for:
1] Firmware announcement (F message) of support for instructional messages
2] Instructional message support for:
- Lock & Unlock
- Set charge mode
- Start & stop charge
There is a bug in net_sms in the handling of feature #14 car bits. The precedence for the "&" and "!=" operators is unexpected and causing all outbound sms messages to be suppressed if the car bits is non-zero.
We need iOS App support for:
1] Firmware announcement (F message) of support for instructional messages
2] Instructional message support for:
- Lock & Unlock
- Set charge mode
- Start & stop charge
To support other vehicle types, we need to move can.{h,c} and can_roadster.{h,c} and have a configuration / #define switch to select the vehicle type to build firmware for.
We also need can_* to implement a method to return the vehicle type code (e.g.; TR for Tesla Roadster) and change net_msg.c to use that when reporting the vehicle type to the server/apps (rather than hardcoded TR as at present).
This will be foundation for the Volt/Ampera work currently being undertaken.
In the event model, queue notifications when busy or out of network coverage.
We need server support for:
1] Firmware announcement (F message) of support for instructional messages
2] Instructional message support for:
- Lock & Unlock
- Set charge mode
- Start & stop charge
Report from Bennett Leeds:
I used OVMS for my first away from home trip this last weekend. The hotel was able to provide me with a 110 outlet and an extension cord. I set the car to 14 amps and charged away - worked great. Just for curiosity, I upped the amperage this morning to
15 amps. Seemed OK. After an hour or so I upped it to 16 amps. Now the battery display said "16 amps" but the connector display still said 15 amps. When I got to the car, it had stopped charging with the "Extension Cord Detected" message on the VDS. Interestingly enough, the extension cord was warm (I think it was only 14 or 16 gauge). There was still juice and I was able to restart charging at 14 amps, but when I upped it again I got the VDS message, but nothing on OVMS (nor did I get a text).
My only clue was that the two amperage readouts on the main page didn't match. And, of course, the SOC didn't increase - but at 110volts it takes a while before that's noticeable anyway.
When I turn on the app for the "first time" it shows the legacy boxes for the tire pressure which I do not have. however, when I consult the already running app. these boxes do disappear as they should with my configuration.
When a car is set to delay charge start until a particular time, it appears that OVMS does not show the status correctly. It would also be nice to control this and perhaps have a function to start charging immediately.
We need Android support for in-app registration of cars.
Create a document to describe all known Tesla Roadster CAN bus messages.
Should this be on the wiki or in the source code repository?
May be these should be converted to kph, like range data, when "K" is set in the param?
Fix calculation miles -> km to match car VMS as closely as system.
Can we, or is it worth, implementing the CAN bus as interrupt driven.
In the iPad app the arrow part for the PEM MOTOR and BATTERY boxes disappears under the top car image instead of being on top as they should be and are on the iPhone.
When battery temperature is below 0 degrees Celsius it will show 254 degrees Celsius for -1 ...
Seems like a data overflow or unsigned/signed casting problem.
I just quickly looked at the code and all the temperature data types are unsigned? (Is it in Fahrenheit?)
Then again in net_msg.c line 292 the sprintf assumes signed data types(%d instead of %u).
Support the handling of CAN bus messages while in a delay loop in the NET module.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
