CycleHack Berlin

Die CycleHack-Bewegung entstand vor zwei Jahren in Glasgow, als sich einige Leute trafen, um gemeinsam Ideen zu entwickeln, die das Radfahren für alle leichter machen sollen. Heute ist daraus ein CycleHack-Wochenende an 38 Orten auf mehreren Kontinenten geworden. Auch in Berlin gab es von Freitag bis Sonntag eine CycleHack-Premiere in der offenen Werkstatt FabLab auf dem Bötzow-Brauerei-Gelände.

Aus einer Vielzahl von Projektvorschlägen wählten die Teilnehmer fünf Aufgaben, um sich mit ihnen 48 Stunden zu beschäftigen. Eines der Projekte hieß „Dekoboko“, das japanische Wort für „uneben“. Aufgabe war, die Fahrbahnbeschaffenheit der Fahrradinfrastruktur zu messen und zu dokumentieren.

Mit dem Oberrohr eines Fahrrads wurde ein Beschleunigungssensor fest verbunden, der die Erschütterungen beim Radfahren maß und sie auf einer Karte verortete. Der am Wochenende gebaute Prototyp wurde rund um den Veranstaltungsort getestet. Die nächste Grafik zeigt die protokollierten Testfahrten im Kollwitzkiez zwischen den Magistralen Prenzlauer Allee rechts Richtung Nordosten und der Schönhauser Allee links Richtung Norden, am unteren Bildrand befindet sich die Torstraße.

Eine ebene Fahrbahn wird grün markiert, je heftiger die Erschütterungen sind, desto röter werden die Messpunkte. Die Kopfsteinpflasterstraßen (Straßburger Straße, Kolmarer Straße, Rykestraße) sind tiefrot markiert, hellgrüne Punkte in der Wörther Straße, der Choriner, der Schwedter und der Torstraße zeigen eine erschütterungsfreie Fahrbahn an.

Andere Projektgruppen des Berliner CycleHacks bauten eine mobile Fahrradzählanlage mithilfe eines Druckschlauches, programmierten den Chatbot „BerlinBikeBot“ für den Messenger Telegram, der Daten von verschieden Seiten abgreift und sie an einer Stelle komprimiert zur Verfügung stellt, konstruierten ein „Smart Dynamo“, der über die Frequenz des Nabendynamos eine Geschwindigkeitsmessung erlaubt, analysierten Unfalldaten aus offenen Senatsquellen, um die Unfallhäufigkeit auf einzelnen Straßen im Zeitverlauf darzustellen. Eine letzte Gruppe zeigte, wie man aus einem Fahrrad in Minutenschnelle ein Windrad bauen kann. Alle diese Projekte zeigen, dass CycleHack Berlin seinem Motto „48 Stunden voller neuer Ideen für die Fahrradstadt Berlin.“ gerecht wurde.

CycleHack weltweit
CycleHack Berlin
CycleHack Berlin bei Twitter
CycleHack Berlin bei Facebook  

25 Gedanken zu „CycleHack Berlin

Kommentare-Feed
  1. Ähm, solche Messfahrräder gibt es doch schon längst und sie werden auch eingesetzt, nur wird darüber nicht sonderlich viel berichtet. In Münster war letztes Jahr solch ein Rad im Einsatz, aus NL ausgeliehen.
    Wissenschaftliche Auswertungen und Begleitungen gibt es auch, okay eher nicht so dolle in Schland, aber die bislang gesammelten Erkenntnisse aus Ländern die sich für qualitativ hochwertige und attraktive Radverkehrsanlagen interessieren, sind ja durchaus verfügbar und in Fachkreisen bekannt.

  2. ja gibts alles usw usf.

    vor fukushima gabs auch mobile messstationen für radioakitivät … aber leider sehr klobig und teuer dazu. dann haben sich ein paar nennen wir sie mal hacker zusammengerauft und haben zügigst ein gerät entwickelt, dass unters auto geklemmt werden kann und für nen schmalen taler zu haben war. innerhalb kürzester zeit konnte so eine isotopenkarte bisher unbekannter genauigkeit angefertigt werden … dazu gehörte natürlich auch eine entsprechende webplatform, auf denen alle messpkte dargestellt wurden …

    jetzt denke man sich mal sowas fürs rad. aufgrund der deutlich billigeren sensorik nochmal ne spur günstiger. endlich kann JEDER messen, der sich dafür interessiert und im idealfall eine dynamische karten entwickeln. sowas hat auch durchaus politisches potential bzw kann der stadtplanung wertvolle hinweise liefern …

  3. @Jochen G., es gibt ja viele Geräte zum Messen von Daten auf Fahrrädern: Geschwindigkeit, Abstand, Erschütterung, Luftqualität, Lärm, Strahlung, usw. Es macht aber einen Unterschied, ob solche Geräte von Firmen entwickelt und vertrieben werden oder ob sie von der Maker-Szene entwickelt werden. CycleHack-Projekte werden mit frei erhältlichen Sensoren und Arduino-Rechnern oder Raspberry Pi gebaut, die Projekte sind dokumentiert und Open Source. Manche Projekte sagen: „Liebe Chinesen, baut das nach! Kostet doch nur Material für weniger als einen Euro!“ Eine Zählanlage mittels Druckschlauch ist technisch wahrscheinlich ein alter Hut, wurde gewiss schon vor zwanzig Jahren gemacht. Aber nun kann es potentiell jeder machen und kostet fast nichts.

  4. @jochen G.
    Hast Du da Quellen?
    Ich kenne aus D nur das Projekt der BW-Hochschule München (Rosenheim und Nordhorn untersucht), das aber eine recht langsame Samplingfrquenz hat und nur recht grobe Unebenheiten detektiert. Für Vergleiche o.k., aber nicht um Rückschlüsse auf Rollreibunt, Vibrationen, Stoßbelastungen zu ziehen.
    Dann noch die Profi-Lösungen (Argus-agil), aber meies Wissens nach keine Anwendung für Otto/Erna–Normal.
    Sowas wie die ’sense-Box‘ wäre ideal, um auch flächendeckend das Thema nach vorn zu bringen, die Wege (ähnlich fietsbalans-2) zu evaluieren und die Reisezeitverluste durch schlechte Oberflächenbeschaffenheit aufaddieren zu können.
    Wichtig dabei: open source, und preisgünstig für alle verfügbar, bzw. replizierbar.

    Weiss denn jenand ob und wo es eine dokumentation gazu gibt?
    (Am besten incl. Arbuino-file)

  5. Finde die Idee grossartig. Gerade im Zeitalter überall verfügbarer Smartphones sollte sich da doch eine günstige Lösung für die Massen entwickeln lassen. Batterie, micro Arduino mit low energy BlueTooth und Sensor in ein kleines Kästchen ans Rad, den Rest (GPS und Kommunkation mit einem Server, der die Daten anonym sammelt) erledigt eine App. Schade das von dem Cyclehack so wenig Details auffindbar sind.

  6. Smartphones haben doch sogar selbst beschleunigungssensoren. Gibt auch apps zum anzeigen: zb vibrometer. Da ließe sich für Smartphone am Lenker also sicher auch was direkt und ohne zusätzliche Hardware programmieren.

  7. Das hellgrüne ist die Knaackstr. (Asphalt).
    Die Wörther Str. ist die nächste Str. Richtung Norden und orange (weil Kopfsteinpflaster).

  8. Alfons -> http://fahrradzukunft.de/18/radweg-oberflaeche/ <- das sollte als Einstieg soweit ausreichen.

    Huckel und Buckel zu deteketieren, kann auch mein Hintern, dafür brauche ich kein smartes Fon (hab eh keines). Knackpunktiger ist da aber die Auswertung und Aufbereitung, um damit dann konkreter Arbeiten zu können und ob sich sowas dann mal eben nebenbei mit etwas hipper Steckerstöpselei bewerkstelligen läßt… ich bin da ehrlich: Ich weiß es nicht.

    Worauf ich aber eigentlich hinweisen wollte, es braucht hier keine Grundlagenarbeit á la Hamburg „wir haben jetzt mal eine Ampel mit REstlaufanzeige für Rot erfunden und begleiten dieses einmalige Pilotprojekt wissenschaftlich für 2 Jahre“, wenn es diese Arbeiten bereits gibt und man die Erkenntnisse nur einzuholen und dann auch anzuwenden braucht.
    Es läuft letztlich einmal mehr auf den politischen Willen hinaus. Leute die aber ihre Augen mit Absicht dicht verschlossen halten, kann man auch mit 10.000 smarten Open Source Projekten keinen Milliter bewegen, denn sie wollen das ja nunmal nicht. (Ja, ich bin da bekennender Pessimist.)

  9. Jochen: vor der Auswertung und Aufbereitung steht ja erstmal die Datensammlung. Und die ließe sich die nicht trefflicher und umfassender bewerkstelligen – bishin zu flächendeckender fast Echtzeit Feststellung von eben gerade aufgebrochen Schlaglöchern – als wenn zb Strava, komoot,…Googleapps Vibrationen zusammen mit dem Standorttracking aufzeichnen und sammeln würden.

    Ein Teil des Strava geschäftsmodells ist es schon heute, aufbereitete Bewegungsdaten des radverkehrs an Kommunen zu verkaufen.

    Zu Deinem eigentlichen Punkt gebe ich Dir natürlich Recht.

  10. Hier der link von Straßen Angebot für Kommunenhttp://metro.strava.com/

  11. und kombiniert mit weiteren „offenen“ kartenmodellen hätte nun auch der ortsunkundige die Möglichkeit die größten Katastrophen zu umgehen …

    die welt reicht halt oft weiter als das eigene popometer am tellerrand vorbeischrappt …

  12. Bei Openstreetmap also immer schön den Straßenbelag nachtragen 🙂

  13. Zu osm.org hab ich gleich noch eine Ergänzung: dafür gibt es schon einen recht guten key „smoothness“ (doku im wiki.osm.org ), als Fleissaufgabe noch „surface“ eintragen, und das OpenStreetMap basierte Fahrradrouting freut sich gleich…

  14. @rbt: Strava verwendet die trackingdaten im eigenen Routenplaner (Webseite. Nicht in der Apple)um gut befahrbahre Wege zu ermitteln. Man kann sich die streckenabschnittsbeliebtheit beim planen auch als heatmap einblenden. Den Planer kann man kostenlos verwenden auch wenn man Strava sonst nicht benutzt. Nur registriert muss man sein. Und gpx lassen sich vom Planer exportieren und über Labs.strava.com auch importieren, so dass man anderswo hergestellte Routen mit der heatmap dort noch feintunen kann oder anderswo dort entworfene Routen mit anderen Tools weiterverarbeiten kann. Ist also auch halbwegs „offen“

  15. Apple=App

  16. @Jochen
    Den letztjährigen Artikel aus Fahrradzukunft kenne ich gut, auch das dort beschriebene Meßsystem (München).
    Die Tücken liegen dabei wie so oft im Detail. Zur recht geringen Samplingfrequ. des BW-Messfahrrades schrieb ich ja oben, auch der G-max-Wert der Sensorik ist aus heutiger Sicht nicht in wünschenswerter Bandbreite ausgewählt (System ist auch schon über 10 Jahre alt).
    Die erwähnten integrierten Smarthone-Lösungen haben das Problem, dass sie weder annähernd eichbar, noch sie (dadurch bedingt) für Vergleiche von Strecken benutzbar sind, zumal – neben den unterschiedlichen Smartphontypen auch die unterschiedlichen Montagen auf unterschiedlichen Rädern für untaugliche bzw. nicht vergleichbare Ergebnisse sorgen.
    Hier wäre es gut so eine Art ‚Standard‘ zu finden (bspw. Montage an der Gabel und definierten G-Wert des Sensors).

    Interessant wird es m.E. dann, wenn sich Reisezeitverluste durch schlechte Oberflächen quantifizieren lassen, und wenn untaugliche Oberflächen für die Radverkehrspolitische Arbeit in aussagekräftige Präsentationen gepackt werden können.
    Auch Vergleiche Fahrbahn/Radweg sind dann SEHR aufschlussreich; Alterungsprozesse beim üblichen unsachgemässen Bau von RVA lassen sich nachweisen, etc.

    Dazu braucht es aber geeignete Hardware!
    Es gibt eine Reihe von Sensoren (die ADXL-Typen, wie etwa den 335), die mit unterschiedlichen Wertebereichen und Empfindlichkeiten zu eruieren wären, und es gilt das Problem der Samplingfrequenz zu beachten.
    Um überhaupt Phänomene wie etwa den stark bremsenden Rauasphalt detektieren zu können muss zwingend bis runter in den Sub-cm Bereich gemessen werden können.
    Das erfordert dann entstprechende Samplingraten (mehrere Khz) und Speicherraten, die beim Arduino nicht ganz unproblematisch zu erzielen sind.

    Insofern wäre es super, wenn die Ergebnisse irgendwo (nebst der Rohdaten (CSV-Datei) , der verwendeten Sensorentypen und der Ard.-Programmierung) veröffentlicht werden würden.

  17. @rbt, Berlinradler, zarl

    was soll denn dann ggf. für OSM verwendet werden?
    Der i.d.R. gute glatte Fahrbahnasphalt, oder die ‚Radweg‘ genannten wurzeligen Marterstrecken auf den ‚Nebenanlagen‘?

  18. @Alfons, man kann die Oberflächen sowohl für die Fahrbahn (Key „surface“) als auch für die „Radwege“ (cycleway:surface oder sogar cycleway:left:surface) angeben.

    Letzteres war mir aber auch nicht so klar, bis Du die Frage gestellt hast 🙂

    Analog gilt das auch für die „smoothness“. Natürlich stellt sich die Frage, wie flächendeckend so detaillierte Informationen eingetragen werden und ob sie beim Rendering bzw. Routing dann auch verwendet werden.

  19. @Alfons: Mit der Eichung sehe ich (zumindest in Großstaädten) erstmal kein riesiges Problem wenn man die Daten pseudonymisiert sammelt (d.h. man weiss welche Daten mit dem gleichen Setup aufgenommen sind) und die Sensoren ein einigermassen vorhersagbares Anprechverhalten haben, könnte man die Datensätze anhand von Referenzstrecken (von denen man ein paar am Anfang selbst fahren müsste) angleichen.

    Samplingrate ist in der Tat ein Problem, die Speicherrate könnte man vielleicht dadürch verringern, dass man nur alle 1s Frequenz und Amplitude der Erschütterungen speichert. Wie Du schon sagst: Es wäre super mehr details zu dem Hack zu erfahren…

  20. @brickbrock
    Gerade das „gleiche Setup“ ist aber gar nicht so einfach. Schon geringe Abweichungen bei Reifenwahl, Reifendruck, etc, machen da große Unterschiede. Ausserdem Fahrgeschwindigkeit.
    Zusätzlich halt noch die unterschiedlichen Geräte …

    Normen (wie z.B. bei Lautstärkemessung) gibt es zwar z.B. im Bereich Arbeitsschutz, aber bis das anwendbar/übertragbar ist muss noch einiges gemacht werden.
    Erste durchaus beeindruckende Einzel-Versuche gab es ja bereits in den 80ern http://lustaufzukunft.de/pivit/comfort/
    aber seitdem ist in D leider recht wenig in der Richtung passiert, obwohl die Technik jetzt preiswert für alle zur Verfügung steht/stünde.

    Bzgl. Samplingfrequenz: auf Arduino basis lassen sich durchaus auch Raten oberhalb 2Khz realisieren (habe einen Prototypen mit Ard.nano und ADXL-Sensor, der das kann), ein Problem ist aber m.E. das Abspeichern auf SD (müsste aber eigentlich gehen) oder eine ausreichend gute WLAN-Lösung.
    Es gibt auch schon Ideen zur Audifikation / Sonifikation.

    Ob die Samplingfrequenz ausreicht liesse sich u.U. mittels eines auf Kontaktmikrophon (plus definierter Masse) basierenden Audio-Recordings überprüfen, das mit 48Khz als Referenz für Rohdatenfeinheit dienen könnte. Dabei müssen natürlich die Grenz- und Resonanzfreuenzen des Systems stimmen.

    Vielleicht meldet sich ja hier jemand vom CycleHack, oder auf im Artikel verlinkten Seiten gibts Berichte/Daten, Austauschmöglichkeiten.

  21. @Alfons: mit gleichem setup meinte ich ein gerät auf eine Art am Fahrrad befestigt, also quasi ein Individuum welches (leider) eine eindeutige ID bekommen müsste. Wenn dieses Setup nun Daten über verschiedene Strecken liefert (glattere und rauere) und ich einige (hoffentlich eine ziemlich glatte und eine ziemlich rauhe) dieser Strecken selbst gemessen habe kann ich Rückschlüsse über andere Strecken ziehen und diese dann verwenden am die Daten anderer Nutzer anzugleichen/skalieren. Man müsste halt sicherstellen, dass das Ansprechverhalten der Sensoren über den interessanten Bereich einigermassen linear ist.

    Die ID ist ein Datenschützproblem, was man allerdings dadurch abschwächen könnte, dass man KEINE Zeitstempel überträgt, und vielleicht auch auf Anfangs- und Endstücke der aufgezeichneten Routen verzichtet.

    Was das Sampling angeht halte ich es nicht für nötig die Rohdaten zu speichern, sondern darauf basierende Werte alle Sekunde oder so zu speichern (viel schneller macht bei der Genauigkeit der üblichen Handy GPS-Sensoren meiner Meinung nach wenig Sinn) Das wäre ein Datenpunkt alle ~4m bei 15km/h und alle 8m bei 30km/h

    Kann ein Arduino 48kHz Audio in Echtzeit verarbeiten?

  22. Das CycleHack-Wochende ist eine großartige Idee. Unglaublich auf was für tolle Einfälle da zustande kommen.

  23. Wow, toll diese Bewegung. Da bin ich gespannt auf mehr!

    Beste Grüße,
    Lukas

  24. Eine ganz ganz tolle Sache – tolle Idee und wir freuen uns, hier ebenso teilnehmen zu dürfen.

  25. Mich begeistert davon vor allem der Smart Dynamo:
    http://www.cyclehack.com/catalogue/smartdynamo/
    Sowas gibt es unter dem Namen BikeLoggerauch kommerziell zu kaufen, aber viel zu teuer.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.