deshi-basara/librexc

Free & open car hacking tool for reading vehicle data via Arduino

#libreXC Contributors: deshi-basara, vpav, florianbeck
Organisation: Stuttgart Media University
License: GPLv3 (http://www.gnu.org/licenses/gpl-3.0.html)

A free, open car hacking tool for reading vehicle data via Arduino.

Note: Have a look at the libreXC wiki as well.

Description

libreXC is a free, open car hacking tool for reading vehicle data via Arduino Yún. The project is consisting of two parts:

1. arduino — for reading and parsing vehicle information with an ELM chip
2. linuino — reading and logging the data from arduino via websocket

Note: The Arduino-Part uses libELM, which ist also part of this project, but hosted in a separate repository.

Recommended Hardware

• Arduino Yun
• SparkFun OBD-II UART

Licence & Copyright

libreXC was written by Simon Schuster, Florian Beck and Viktor Pavlovic. libreXC is licensed under the GNU General Public License v3.

librexc's Issues

Kommunikationsprotokoll

Hallo zusammen,
für die Kommunikation von Linuino zu Arduino wollen wir nach Rücksprache mit Herrn Meyer ein eigenes Protokoll verwenden.

Jede Nachricht besteht aus 5 Bytes:

|START(0x11)|CMD|VALUE|CHECK|END(0x22)|

Wir sollten noch festlegen ob wir die Bridge oder eine normale Serial-Verbindung verwenden. Über die Bridge sollte das aber auch ohne Probleme funktionieren, wenn man die Bytes vorher in Chars umwandelt und dann (einzeln) über die Bridge schiebt.

Für den Rückweg war sein Vorschlag, die "rohen" Daten ans Linuino zu schicken, das Parsing der Daten auf Linux-Seite zu machen und auch für den Rückweg so eine eigene Schnittstelle zu verwenden.

Bitte um weitere Anregungen, Kommentare und Vorschläge ob und wie wir das umsetzten.

Viele Grüße, Flo

Ziele

Muss

• OBD-Kommunikation über ELM327-Modul
  (https://github.com/sparkfun/OBD-II_UART)
• Kommunikation Arduino <-> Linux
• JSON API
• Speicherung /Logging der Daten auf Linux

Soll

• OpenXC Kompatibilität herstellen
• CAN-Daten lesen und über die selbe API zur Verfügung stellen

Kann

• Web-Backend
• Display im Fahrzeug (Pixel o.Ä.)
• Zusätzliche Sensorik

arduino cmake

Hallo zusammen,
ich habe eben mal ein Grundgerüst für CMake committet (committed? comitted? ach pfeif drauf: hochgeladen, und zwar hier 5c2cab3). Funktioniert das bei euch? Unten noch eine kurze Anleitung.
Viele Grüße.

Systemvoraussetzungen

• Allgemeine Voraussetzungen:
  • CMake - http://www.cmake.org/cmake/resources/software.html
  • Arduino SDK - http://www.arduino.cc/en/Main/Software
• Zusätzlich für Linux:
  • gcc-avr - AVR GNU GCC compiler
  • binutils-avr - AVR binary tools
  • avr-libc - AVR C library
  • avrdude - Firmware uploader

Einrichtung und Benutzung

Kurz zusammengefasst müssen folgende Befehle ausgeführt werden:

mkdir build
cd build
cmake -D ARDUINO_DEFAULT_PORT=/dev/tty.usbmodem1411 -D ARDUINO_DEFAULT_BOARD uno -G"Xcode" ..
make
make upload              # um die firmware auf das Arduino zu laden [optional]

Beim cmake-Befehl muss der Port entsprechend an das Betriebssystem und das verwendete Board angepasst werden. Der Port eines angeschlossenen Arduinos kann in der Arduino IDE über Tools → Serieller Port ausgelesen werden.
Über cmake -G"[Generator]" kann der Generator gewählt werden. Mit cmake -G wird eine Liste der verfügbaren Generatoren angezeigt.

Wenn cmake einmal ausgeführt wurde, reicht fortan make (auch bei Änderungen an dem CMakeLists.txt's).

Das build-Verzeichnis ist über einen Eintrag in der .gitignore-Datei geschützt. Bitte nur in dieses Verzeichnis hinein kompilieren.

pidParser

Ich habe mal zwei Versionen des pidParsers committed. @vpav, bekommen wir aus dem ELM-Shield irgendwie direkt die Bytes oder werden die immer als String geschickt?

Ideen-Sammlung

Hier mal meine Feature-Vorschläge, falls sich das Projekt in Richtung eines interaktiven Fahrtenbuchs entwickelt:

Reines Auslesen und Aufbereiten von Daten

• Fahrtgeschwindigkeit momentan, Durchschnittsgeschwindigkeit auf Strecke
• Glateiswarnung mit Außentemperatur-Sensor (Außentemperatur < 4 Grad)
• Autoradio: Erfassung von Interpret/Titel, Übertragung an Dienste wie Lastfm
• Motorzustände: Drehzahl, Temperatur
• Luftdruckkontrolle der Räder (bei aktivem RDKS)
• Kilometerstand
• Fehlerspeicherabfrage mit Beschreibung
• Speichern der Daten in Profile für verschiedene Fahrer (Mutter, Vater, Kind)

Einbinden externer Sevices

• Warnung bei Überschreitung der Höchstgeschwindigkeit (30/50/120 km/h)
• Blitzer-Warnung

Arduino: Stability

Der Code läuft insgesamt ziemlich instabil, die genaue Ursache ist mir noch unbekannt. Ich vermute, dass es damit zusammenhängt, dass unerwartete Nachrichten vom ELM zurückkommen.
Hier sollte der Code nach fertigstellung der Grundfunktion robuster gemacht werden, d.h. Error-Handling für falsche / zu kurze / zu lange / ausbleibende Antworten.

Kompatibilität zu openXC

In welchem Umfang soll denn unser libreXC mit openXC kompatibel sein? Bis jetzt haben wir immer nur von einer Orientierung an der openXC-Spezifikation für die (JSON)-Ausgabe gesprochen. So wie ich es aber jetzt aus der Firmware-Dokumentation herausgelesen habe, ist openXC für Entwickler besonders interessant, da man die CAN-Signale "querien" oder auf Wert-Veränderungen lauschen kann:

Abfrage der ID 0x102 auf dem Bus-Controller 1:

{   
   "buses": {
        "hs": {
            "controller": 1,
            "speed": 500000
        }
    },
    "messages": {
        "0x102": {
            "bus": "hs",
            "signals": {
                "My_Signal": {
                    "generic_name": "my_openxc_measurement",
                    "bit_position": 5,
                    "bit_size": 7
                }
            }
        }
    }
}

Eine Liste aller möglichen Abfragen findet sich in der Firmware-Dokumentation.

Es ist meiner Meinung nach relativ sinnfrei das Projekt "libreXC" zu nennen, wenn 99% der Features vom Original nicht unterstützt werden. Zu leisten wäre die zusätzliche Implementierung der ganzen Abfragen bestimmt nicht, aber so wie ich den Maier verstanden habe, hätte er ja gerne die Kompatibilität zu openXC.

Bleiben wir jetzt einfach bei der (openXC)-JSON-Ausgabe oder was denkt ihr?