Skip to main content

Blog

Wie funktioniert eigentlich das mit den Fahrradtrackern?

von Stefan Kaufmann · 13. Januar 2020

Auf dem 36. Chaos Communication Congress des CCC zwischen Weihnachten und Neujahr gab es einige Ulmer Beteiligung – und unter anderem auch einen Vortrag von unseren Stadtverwaltungs-Fellows Consti und Max, der es auch bis Heise Online geschafft hat.

Nebenan auf radforschung.org gibt es einen begleitenden Artikel samt allen Quellen, den Vortrag selber gibt es natürlich auf media.ccc.de in ganzer Länge und auch mit englischer Übersetzung anzusehen.

Einschub: Der Vortrag erwähnt die Stadt als Fellowship-Geberin eher subtil – das ist Absicht und so gewollt, denn die Regeln des Congress sagen ganz klar, dass dies eine nicht-kommerzielle Bühne ist, auf der Marketing für ArbeitgeberInnen nicht akzeptiert ist.

Im Nachgang gab es daraufhin viel viel Feedback, Tipps und Fragen. Und eine der meist gestellten Fragen war, wie denn die Positionsübermittlung der Fahrräder derzeit funktioniert. Deswegen hier mal ein Aufschrieb dazu.

Wie die Daten überhaupt übertragen werden

Eine grundlegende Annahme für uns ist derzeit, dass wir uns nicht auf klassische SIM-Kartenbasierte M2M-Kommunikationsstrukturen verlassen wollen – also irgendwas, was klassische Mobilfunkbetreiber anbieten.

In Ulm gibt es bereits seit Ende 2016 ein gut ausgebautes LoRaWAN-Netzwerk auf Basis des freien The Things Network. Das ermöglicht uns, ohne laufende Subskriptionskosten kleine Datenmengen zu übertragen und zu experimentieren. Ein Nachteil muss aber erwähnt werden: Das Grundprinzip des Netzwerks ist, dass vorwiegend Daten von den Endgeräten zu den fest installierten Gateways übertragen werden. Die Rückrichtung von der Infrastruktur zu den Endgeräten ist eigentlich mehr die Ausnahme, und sie funktioniert auch nur unter gewissen Voraussetzungen.

Das ist aber im derzeitigen Projektstadium nur mäßig projektkritisch – und es spricht auch nichts dagegen, gegebenenfalls in einem anderen Setting auch M2M-SIM-basierte Geräte einzusetzen.

Vom MVP zur eigenen Hardware – oder, alles mal probieren

Der aktuelle Stand ist, überhaupt Positionierungsdaten ins Backend zu übertragen. Beim Feldversuch auf dem Chaos Communication Camp im Sommer 2019 passierte das mit TTGO T-Beam Development Boards. Das sind für ca. 20 EUR pro Stück aus Fernost bestellbare Entwicklungsplatinen, auf denen ein programmierbarer ESP32-Controller, ein halbwegs passables GPS-Modul und ein LoRaWAN-Modem (RFM95W) gemeinsam verbaut sind. Und weil auf der Platine auch gleich eine Lade- und Entladeregelung sowie eine Halterung für eine 18650-Akkuzelle dabei sind, ist das praktisch eine alles-in-einem-Lösung, die wir einfach so an die Fahrräder binden und benutzen konnten.

Naja, jedenfalls fast: Selbst wenn das Gerät nur alle 10 Minuten aufwacht, um die Position zu bestimmen, brauchen die Platinen auch im Deep-Sleep-Modus vergleichsweise sehr viel Energie. Die Akkus waren indes meist nach gut 30 Stunden komplett leer und mussten regelmäßig getauscht werden. Für den Praxiseinsatz ist das natürlich so gar nicht tauglich.

Der Quellcode, den wir auf dem Camp im Einsatz hatten, ist selbstverständlich auf Github verfügbar. Wie man dort erkennen kann, hatten wir auch mit günstigen Beschleunigungssensoren MPU9250 experimentiert, die das System aufwecken, wenn am abgestellten Fahrrad gewackelt wird.

Positionierung auf WLAN-Basis

Consti hatte eine andere Idee, wie man lange Betriebszeiten mit wenig Energie hinbekommt. Er hat einen eigenen Aufbau auf Basis eines ESP8266 getestet, der intervallbasiert die BSSIDs umliegender WLAN-Netzwerke erkennt und diese dann ins Backend schickt. Über den offenen Mozilla Location Service ist dann eine grobe Rückpositionierung möglich – falls genügend Menschen für diesen Ort Positionierungsdaten angelegt haben. Für eine grobe Positionsbestimmung reicht das allemal – denkbar ist natürlich, genau wie bei allen anderen Methoden, die Positionierung über passende Beacon-Verfahren an den festen Abstellstationen noch zu präzisieren, wenn man dafür geeignete Hardware einsetzt.

Kommerziell erhältliche Tracker

Um schnell Räder auf die Straße zu bringen und Tests fahren zu können, hatten wir zudem einige kommerziell erhältliche GPS-Tracker mit LoRa-Modem gekauft und getestet. Das war hier vor allem der Dragino LGT92 – der witzigerweise ein ähnliches Feature Set hat wie unser Eigenaufbau aus T-Beams mit Beschleunigungssensor, und dessen Erfassungszyklus auch ähnlich gedacht ist wie das, auf das wir mit den T-Beams kamen.

Zum Testen reichen die Geräte ganz passabel aus; an den Fahrrädern haben wir sie in Feuchtraum-Abzweigdosen mit Schellen aus dem Baumarkt befestigt. Ein Tracker kostet bei den üblichen Einkaufsplattformen rund 40 €.

Unsere geplante eigene Lösung

…ist eigentlich grob eine Mischung zwischen dem T-Beam und den Dragino-Trackern: Eine eigene Plattform auf ESP32-Basis mit verbundenem MPU9250-Gyroskop und abschaltbarer Spannungsversorgung für die allzu energiehungrige Sensorik, v.A. das GPS. So kann der Tracker die meiste Zeit im Tiefstschlafmodus verbringen und dabei kaum Energie aufnehmen – und in periodischen Abständen, bzw. wenn die IMU Bewegung erkennt, wacht die Platine auf und ermittelt ggf. die Position.

Langfristig möchten wir diese Plattform auch mal testweise mit den Rahmenschlössern verbinden, die Consti und Max bereits analysiert hatten, um damit Entsperrvorgänge anzustoßen. Für den Anfang freuen wir uns aber auch schon um eine sehr energiesparsame Variante, die im Idealfall bei Benutzung des Rads auch über den Nabendynamo erhaltungsgeladen werden kann, so dass die Wartungsintervalle möglichst ausgedehnt werden können.

Im Testaufbau hat das alles auch schon sehr gut funktioniert. Im Tiefschlaf braucht das System weniger als ein halbes Milliampere, und trotzdem funktioniert die Positionierung vor allem draußen schnell und zuverlässig. Auch hier können Beacon-Systeme an ausgewiesenen Abstellpunkten zur Präzision der Erkennung beitragen.

Selber mitentwickeln

Wir möchten als Freie Soft- und Hardware entwickeln – und dazu gehört auf jeden Fall, auch anderen den Einstieg in die Mitentwicklung zu erleichtern. Sobald wir die ersten prototypenfähigen PCB-Designs haben, landen die natürlich auf Github. Und wir möchten interessierte Hackspaces auch gerne Platinen aus der ersten Serie zum selbst belöten zuschicken, sobald sie gefertigt sind. Mehr dazu folgt hier, sobald es soweit ist!

Vernetzungstreffen beim FORUM Offene Stadt und dem Code-for-Germany-Summit in Hamburg

von Stefan Kaufmann · 13. November 2019

Sowohl OpenBike als auch digitransit sind Freie/Open-Source-Softwareprojekte – und das heißt auch, sie brauchen beide unbedingt eine aktive Community von Menschen, die an den Systemen weiterentwickeln, neue Features entwickeln, und vor allem auch die Dokumentation so ausbauen, dass die Systeme für andere nachnutzbar sind. Deswegen hat es uns sehr gefreut, vergangenes Wochenende beim FORUM Offene Stadt bei der Körber-Stiftung in Hamburg und danach beim Code-for-Germany-Communitysummit von den beiden Projekten zu erzählen und uns mit Gleichgesinnten zu vernetzen.

Beim Barcamp-Format im Kubus der Körber-Stiftung konnte Maxi einer ganzen Traube von Menschen den digitransit-Stack vorstellen, und es ergaben sich auch gleich sehr schnell Ideen für neue Features oder andere Orte, an denen das System auch einmal getestet werden könnte.

(Nebenbei: Es sind tatsächlich genau diese Formate, die Menschen sowohl aus der Verwaltung, als auch aus digitalem Ehrenamt, Wirtschaft und Forschung zusammenbringen, die am meisten Inspiration und Austausch mit sich bringen. Das ist jetzt eine alles andere als revolutionäre Erkenntnis, aber in der Praxis lässt sich doch immer wieder feststellen, dass die meisten Konferenzen immer nur in der eigenen Suppe schwimmen.)

Beim anschließenden Code-for-Germany-Summit konnten diese Ideen dann auch gleich weiter vertieft werden. Die vor über fünf Jahren ins Leben gerufene Community aus dezentralen OK Labs ist ein wertvolles Netzwerk von motivierten und kompetenten Leuten, die im wahrsten Sinne des Wortes mit Code die Welt verbessern wollen. Oder zumindest ihre eigene Stadt. Und so gab es gleich eine ganze Reihe an Nachfragen, Verbesserungsvorschlägen und Ideen sowohl für OpenBike als auch für digitransit.

Wer auf dieser Ebene mitwirken will, sei hier ausdrücklich auf die weite Community der weit über 1000 Menschen im Slack der Open Knowledge Foundation hingewiesen. Dort gibt es auch eigene Kanäle sowohl für Open-Source-Bikesharing als auch für die Entwicklung an digitransit. Wer dort mitlesen und -schreiben möchte, kontaktiere uns gerne jederzeit.

Dankeschön an dieser Stelle an das Team von Code for Hamburg, das dieses Wochenende großartig organisiert hat!

Der Auftakt – so ging es am 14. Oktober los

von Kathi Schweiger · 17. Oktober 2019

Eigentlich ist aktuell im M 25 am Münsterplatz eine (empfehlenswerte!) Dauerausstellung zur Hochschule für Gestaltung zu sehen. Am Montag, dem 14. Oktober durften wir daher zwischen Architekturmodellen und Original-Einrichtungsgegenständen der hfg das Projekt OpenBike im kleinen Kreise interessierter VerwaltungsmitarbeiterInnen und ProjektpartnerInnen vorstellen.

Die Grundidee ist schnell erklärt: Wir bauen Freie und Open Source Software, um ein Bikesharingsystem in eigener Hand betreiben zu können. Damit können künftig auch kleinere Kommunen, Vereine oder auch Betriebe ihr eigenes Sharing-System einrichten, ohne dafür zwangsläufig auf Dritte als Dienstleister angewiesen zu sein. Und weil das System Frei und Open Source ist, können nicht nur wir bei der Stadt Ulm daran weiterentwickeln und neue Features hinzufügen, sondern auch beliebige andere können dazu beitragen – und alle können danach etwas davon haben.

Ob und wie das alles in der Praxis funktioniert, muss natürlich auch mit echten Menschen getestet werden. Eine erste, eher freizeitnahe Testumgebung fand sich im August beim Chaos Communication Camp in Brandenburg. Binnen 12 Werktagen galt es aus dem Nichts ein funktionierendes Testsystem zu schaffen, und das funktionierte auch recht gut. Kleine Tracker an den Fahrrädern übermittelten immer wieder die Position, die dann über eine Karte findbar waren. Wer sich einmal angemeldet hatte, konnte nun das Rad „buchen“ und bekam den Code für das Zahlenschloss angezeigt.

Nun gilt es, diese Erfahrungen in der Stadt Ulm umzusetzen. Durch die Förderung im Rahmen der Linie MobiArch des Verkehrsministeriums Baden-Württemberg können wir nicht nur Software entwickeln, sondern auch eine Reihe Räder beschaffen, die nun für eine eingegrenzte Test-NutzerInnengruppe benutzt werden können sollen. Weil sich das so anbot, werden diese TestnutzerInnen im ersten Schritt einmal städtische Beschäftigte sein – wobei die Abgrenzung nicht 100% scharf ist, d.h. wer testen will, muss nicht unbedingt städtisch angestellt sein.

Damit so etwas überhaupt funktioniert, wird es möglich sein, sich über verschiedene Dienste anmelden zu können. Beim Chaos Communication Camp nutzten wir eher IT-nahe Dienste wie StackOverflow, Github und FragDenStaat. Wer dort bereits einen Account hat (oder sich einen anlegt), wird sich aktuell bei unserem Testsystem anmelden können und kann dann durch uns für die Testgruppe freigeschaltet werden.

Wichtig für uns ist nun vor allem, wo die rund 10 Räder der ersten Tranche ausgebracht werden sollen. Wir werden für den Anfang vor allem stationsbasiertes Bikesharing testen, d.h. Räder werden an definierten Stationen entliehen und zurückgegeben. Wir hatten bereits bei der Einladung an alle Beschäftigten die Möglichkeit gegeben, bevorzugte Abstellorte an uns zu melden. Dadurch und durch die Auftaktveranstaltung haben sich nun einige Standorte ergeben, die wir nun auf Praktikabilität prüfen und mit den ersten Rädern beschicken werden.

Wenn also in der Realität bald die ersten Räder an städtischen Liegenschaften stehen, ist nicht mehr viel zu tun: Es reicht, sich (momentan nach wie vor über die oben genannten Dienste, wir empfehlen derzeit noch FragDenStaat) anzumelden, die eigene User-ID per E-Mail an uns zu schicken, und dann kann’s losgehen. Wir sind gespannt ;)