Blog

Wenn man ein Bikesharingsystem bauen will, braucht es natürlich auch Räder. Bei kommerziellen Bikesharingsystemen gibt es da eine große Vielfalt an Fahrrädern. Von robusten Fahrrädern mit Zahlenschloss über die – vorsichtig gesagt – auf Kosteneffizienz optimierten OBikes bis hin zu den spannend durchdacht konstruierten Jump-Bikes, die sehr auf Details wie innenliegende Züge etc. achten.

Für uns lag nun die Herausforderung darin, passende Räder für unseren Praxistest zu finden und sharingfähig zu machen. Sie sollten im MVP mit GPS-Tracker und Zahlenschloss funktionieren, perspektivisch aber auch mit den von uns zerforschten Sharing-Schlössern getestet werden können. Hier wollen wir einmal zeigen, wie wir das gemacht haben.

Wir haben uns nach einer Ausschreibung für recht robuste Alltags-Stadträder mit 7-Gang-Schaltnabe, Nabendynamo und eingehauster Kette entschieden. Und von da zum Sharingrad war es gar nicht mal mehr so weit. Wie ein echtes Startupbusiness haben wir erstmal Design Thinking gemacht (so heißt das ja, wenn man mal schnell was mit Pappdeckel und Kabelbinder baut) und ausprobiert, wie die Beschilderung aussehen könnte.

Alles was dann noch fehlte, war ein Stapel Acrylplattenzuschnitte, die dann im Lasercutter des Verschwörhaus mit passenden Nuten versehen wurden. Consti, Kathi und Max konnten an diesen dann ihre Rakelkünste üben und einen Stapel Aufkleber mit den Sharing-Nummern und QR-Codes aufbringen. Die kamen aus einer Seriendruck-PDF-Vorlage, die wir von einem Dienstleister als Aufkleber ausdrucken ließen.

Und das war es dann eigentlich schon fast. Dazu kamen noch die bereits beschriebenen Feuchtraum-Abzweigdosen, die mit Sanitärschellen am Steuerrohr verschraubt wurden, und die Zahlenschlösser – fertig ist das Sharingrad.

Mittlerweile haben wir auch schon einige Tests mit den chinesischen Sharingschlössern angestellt. Leider passen die nicht so recht in das Dreieck zwischen Sattelrohr und Sattelstrebe. Wir haben aber mit Hilfe des ADFC eine Anbringung getestet, die für das erste Testen einmal reicht. Dazu aber später hier mehr :)

Once you deploy digitransit with your GTFS feeds, you might encounter spiky trip shapes that don’t follow street geometry. Here is how to fix this.

Fellow developer Vlatko from the City of Osijek sent us this screenshot. The bus appears to just bulldoze through buildings, not following any street geometries at all.

What happens here is the following. GTFS has a separate file called shapes.txt that defines shape geometries for trip patterns. Within trips.txt, individual trips can reference a shape_id they adhere to.

If this shapes.txt is not defined within your GTFS feed (and many feeds do not provide shapes right now), digitransit/OpenTripPlanner will only display the linear distance between individual stop points – regardless of the actual route the trip should take.

How to mitigate this

There are several approaches to retroactively add shapes to your existing GTFS feed. We have tried two variants and can recommend them both:

Conveyal Transit Data Tools

This is a complete software suite you can access through your browser in order to edit, reconfigure or even build your GTFS feed from scratch. Good for getting a first feel for your feeds and analyzing them.

pfaedle

pfaedle is a command line tool by Patrick Brosi that matches GTFS feeds to OpenStreetMap relations very precisely. This might take a bit longer to set up initially and adapt to your needs, but once it runs it should save you time in the long run.

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!