Hallo!
Wir von der Initiative MunichWays betreiben das RadlVorrang-Netz innerhalb von München. Auf einen unserer offenen Mobilitätstreffen haben wir das Thema „Ausleuchtung von Radwegen“ erörtert.
Meine Idee ist es, den OBS derart umzurüsten, so dass die Radfahrenden bei uns in der Stadt die durchschnittliche IST-Helligkeit aufnehmen können.
Mir ist bekannt, dass der OBS sich „relativ“ leicht umrüsten lässt. Wer arbeitet noch an diesem Thema?
Danke,
WendelinMunichWays
Habe bisher noch nix zu dem Thema gehört oder mitbekommen. Klingt aber interessant 
Gab schon Ideen, den OBS mit Luftsensoren auszustatten, um alternative Fahrradrouten mit guter Luft zu finden.
Aus Neugierde: Wie wollt ihr unterscheiden, ob das Licht von einem fahrenden/stehenden Fahrzeug, einem Wohnzimmer oder einer Fahrbahnbeleuchtung kommt?
Hallo Natemom,
danke für deine Antwort. Hinsichtlich Luftqualität sei auf Eco Data Swarm verwiesen, was eine Eigenentwicklung zu sein scheint.
Der Grundzug meiner Idee war einfach: Ich habe den OBS gewählt, um den Entwicklungsaufwand so gering wie möglich zu halten. Ansonsten habe ich mir keine weiteren Gedanken gemacht, weil ich zum einen frisch mit dem OBS in Berührung gekommen und das Thema „Ausleuchtungsmessung“ auch mehr oder weniger gerade eben erst angefangen wurde.
Ich weiß, dass meine persönlichen Ressourcen begrenzt sind. Deshalb komme ich mit dieser Idee auf euch zu und bin gerne bereit, meine Idee für den OBS mit euch auf die Straßen dieser unserer Republik zu bringen. Wäre echt toll, in ein paar Jahren (?) besser ausgeleuchtete Radwege zu haben.
WendelinMunichWays
Am ehesten könnte man das mit einem auf den Boden gerichteten Helligkeitssensor, evtl. in einem schwarzen Rohr schaffen - Es gibt noch Ports am OBS, an die man sowas theoretisch löten könnte. In wie fern standardisierte Helligkeitssensoren erschwinglich verfügbar sind kann ich aber nicht sagen. Auch ist die Frage wie sehr die Belagsfarbe die Messung beeinflusst.
Da aber die Beleuchtung von Radwegen relativ statisch ist (Laternen wandern ja nicht), würde auch eine einmalige nächtliche Befahrung mit Kamera reichen um die Helligkeit zu dokumentieren. Bei einigen Kameramodellen kann man die Empfindlichkeit fest einstellen, so dass man im Nachhinein aus dem Videobild eine Abschätzung für Helligkeit extrahieren kann - Das wäre vermutlich einfacher als extrahardware zur Messung zu bauen. Im Gegensatz zum Überholabstand ist es für Helligkeitswerte ja nicht erforderlich, die gleiche Strecke oft zu befahren. Maximal vielleicht 3x, einmal bei nass, einmal bei trocken, einmal bei Schnee.
Hallo Gluap,
danke für die Anregungen. Sicherlich kann man mit einer Actioncam oder auch dem Telefon die Helligkeit in unserem Netz aufzeichnen. Mir ist nicht ganz klar, ob ich damit die in der DIN EN 13201-1 gefordeten Lux ermitteln kann. Mir ist es wichtig, dass ich einer Koordinate einen Luxwert zuordnen kann. Bilder sind für die Planer in den Verwaltungen auch wichtig,
Hinsichtlich einer Befahrung bei unterschiedlichen Witterungsverhältnisse stimme ich dir zu; es macht Sinn m. E. auch eine mehrfache Befahrung bei den gleichen Witterungsbedingung (Mittelwert!).
Die Belagsfarbe ist mehr oder weniger die gleiche; den Einfluss davon muss m. E. ganz einfach ausgemessen werden.
Kann man den OBS so konfigurieren, dass die nicht benötigten Sensoren für den aktuellen Messeinsatz abgenommen werden? Bei einer Helligkeitsmessung macht eine Abstandsmessung keinen Sinn.
Klar ist auch, dass die aufgenommenen Werte auch wieder ausgelesen und aufbereitet werden müssen. Jedoch kenne mich mit dem UI vom OBS bislang Null aus.
WendelinMunichWays
Wenn es um eine DIN-Konforme Luxmessung geht ist vermutlich die Helligkeit an einer bestimmten Stelle zu messen - Ich kann auf die Norm leider nicht zugreifen, das könnte z.B. auf der Fahrbahnoberfläche oder aber auf Kopfhöhe sein. Das ist evtl. kein leichtes Problem diese Messung vom Fahrrad aus durchzuführen - Weil unter Umständen der Fahrer immer einen Schatten auf den Lichtmesser wirft.
Ein Workaround wäre, auf mehreren Seiten des Fahrrads Sensoren anzubringen, z.b. vorm Lenker und hinterm Gepäckträger, um den Schatten des Fahrrads herausrechnen zu können. Dann müsste man noch einen Weg finden, Scheinwerferlicht von Autos und anderen Radfahrern zuverlässig herauszufiltern. Einfach die Ultraschallsensoren am OBS durch Lichtsensoren zu tauschen ist vermutlich unpraktisch, weil das OBS während der Fahrt meist vom Fahrer verschattet ist. Laternenlicht kommt ja bevorzugt von oben.
Bliebe eine indirekten Messung der Helligkeit über das vom Belag reflektierte Licht mit einer Kamera oder einem gerichteten Lichtsensor. Um daraus Luxwerte zu extrahieren, müsste man aber sehr genau das Albedo der Oberflächen kennen. Zwischen hellen Betonpflastersteinen und frischem schwarzen, nassem Asphalt dürften da Größenordnungen liegen, das ist also auch aus Kameraufnahmen kaum zu rekonstruieren.
Konfigurieren ist nicht das richtige Wort. Der OpenBikeSensor ist Open Source - du könntest also ein Gehäuse entwerfen und drucken, bei dem Sensoren getauscht werden können und die Firmware so programmieren, dass sie Werte von den Sensoren, die dich interessieren aufzeichnen kann. Es ist aber nicht unwahrscheinlich, dass das mehr Aufwand ist, als ein Extragerät mit dem Zweck „GPS Belichtungsmessung“ zu konstruieren. Firmwaremäßig kannst du dich natürlich trotzdem im Sinne des Open Source gedanken beim OpenBikeSensor inspirieren lassen.
An deiner Stelle würde ich mit einem Prototypen starten - im Zweifelsfall erstmal ohne GPS, nur ein Mikrocontroller und ein Belichtungsmesser und daraus versuchen etwas zu konstruieren, das Helligkeitswerte misst. Vergleichen könntest du z.b. evtl. mit einem Luxmesser aus dem Fotografiebereich. Wenn dann eine Methode steht, wie man die Luxwerte vom Fahrrad aus zuverlässig messen kann, könnte man sich Gedanken machen ob es Sinn macht, das an ein OBS anzuflanschen oder ob es zu speziell ist und besser als eigenes Gerät konstruiert wird.
Interessante Idee, spannendes Projekt MunichWays!
Betreiber von Straßenbeleuchtungen müssen Straßen alle paar Jahre befahren mit einem Messfahrzeug (mit Fotometer auf Anhänger wurde mir berichtet von der GF, als ich dort arbeitete – illustriert gefunden) und die Einhaltung der Vorschriften zu prüfen.
Wäre es deren Aufgabe, mal die Stadt (-werke) fragen, ob sie das auch machen oder was es kosten würde, das auf Radwege auszuweiten (wenn da nicht vorgeschrieben). Mit Rückenwind des Radentscheids sollten die Mehrheiten da sein…
Ich hatte dazu schon was im Slack geschrieben.
Mit Hinweis auf die Beleuchtung in Potsdam, die nach Nutzung gedimmt wird:
und diese Veröffentlichung gefunden, auf S. 29:
Für Radwege gilt nach DIN 13201-1 die Beleuchtungssituation C1. Je nach Umgebungshelligkeit und Verkehrsaufkommen beträgt der Wartungswert der mittleren horizontalen Beleuchtungsstärke 2 Lux bis 15 Lux. Im Bewertungsfeld muss die minimale Beleuchtungsstärke mindestens 0,6 Lux bis 3 Lux betragen
Auf der Suche nach der o.g. DIN fand ecosia den Vortrag eines Licht-Ings mit relevanten Angaben.
Ideen zum selber machen.
Zunächst Anordnung überlegen – möglichst einfach. Ich würde das analog machen wie nach DIN und nicht umständlich von Oberflächenhelligkeiten zurückrechnen.
Hallo zusammen – interessantes Thema.
Zum Thema Fremdeinstrahlung durch KFZ oder sonstige Lichtquellen: Das macht ja den Ort immer nur heller. Eine Straßenlaterne ist bekanntlich sehr statisch, eventuell geht die zu irgendeiner Zeit aus, aber wenn ich z. B. nachts zwischen 0 und 3 Uhr fünf mal messe, davon 2 mal absolute Dunkeltheit vorfinde, dann steht da vermutlich keine Laterne (oder sie ist um diese Uhrzeit eben immer aus). Also wäre wohl das Minimum statt des Medians oder Durchschnitts eine bessere Metrik zur Akkumulation von Messwerten.
Für so ein Projekt lässt sich natürlich der OBS abwandeln. Es wäre toll, irgendwann, wenn sich die Technik mehr zu einer Art Plattform entwickeln würde, in der solche „Nebenideen“ auch einfach mitgenommen werden können, als Erweiterungen zum „Baseline“ Modell. Aber so weit sind wir technisch nicht, bzw. das bräuchte viel mehr Aufwand als wir leisten können im Moment. Insofern nehmt gern das, was da ist, und wandelt es entsprechend ab (Forks und so).
Hört sich ja schon mal gut an, dass das prinzipielle Interesse da ist. Hinsichtlich gewisser Details ist noch Redebedarf, aber mir ging es jetzt erst auch einmal mit darum, eure Bereitschaft auszuloten.
Gerne übernehme ich die Verantwortung über diesen Fork und bin auch ansonsten gerne bereit, aktiv am Fork zu arbeiten.
Gerne komme ich Montag, den 2022-01-17 in eueren großen blauen Knopf um weiter darüber zu reden. Leider ist mir gestern Abend eine andere Verpflichtung dazwischen gekommen.
/WendelinMunichWays
Die „normierte Helligkeitsmessung mit kalibrierbaren Sensoren“ würde ich direkt zu den Akten legen, dazu wird man eine Ulbrichtkugel brauchen.
Ich wollte mal fragen, ob nicht der persönliche Eindruck vielleicht wichtig ist?
Wenn ich irgendwo langfahre und es erscheint mir zu dunkel - dann könnte ich doch den Knopf drücken!
Wenn es wieder heller wird, dann drücke ich erneut (sozusagen auf „aus“).
Dann gibt es zwar nur binäre Ergebnisse, aber diese kann man statistisch bewerten, z.B. wenn Du das Alter der Fahrenden* kennst, oder den Tag (mit dem Sonnenstand, den man aus GPS berechnen kann!).
So erübrigt sich der ganze Zinnober nicht vergleichbarer Messungen. Subjektiv ist es aber da mehr Leuten zu dunkel, wo Lampen fehlen.
*höheres Alter = schlechtere Lichtempfindlichkeit der Augen
klingt auch interessant der Ansatz.
Allerdings ist es dann noch schwieriger Akzeptanz der Aussagekraft zu finden bei Entscheidungsträger:innen, es bräuchte unglaublich mehr Datensätze/Abschnitt und Metadaten über das Nutzerprofil (wer fährt und empfindet?) für eine repräsentative Aussagekraft.
Interessant wäre der OBS als Erweiterung der SimRa-App, wo er dann als Eingabeoption für Derartiges dienen kann.
Evtl. wäre zur Bedienung ein Steuerkreuz besser als ein einfacher Button…
<comment type="brainstorming">
Ein Beschleunigungs-Sensor (e.g. ADXL345) waere noch eine Idee um die Zustaende der Wege/Strassen zu erfassen. Wenn nachts an der gleichen Stelle immer deutlich mehr Beschleunigung messbar ist, dann stimmt dort was mit der Ausleuchtung nicht.
Fuer die Erkennung von Gefahrenquellen braucht man keine geeichten Messwerte, lehrt uns das Machine-Learning. Hier reicht statistik; Messen kann da dann ein Fachmann mit teurem Geraet.
</comment>
und wie soll man aus Beschleunigungen auf die Beleuchtung zurückschließen? Beschleunigungen sind doch von der Oberflächenbeschaffenheit des Weges, von der Feder- und Dämpfungskonstante des Systems (wo ist der Beschleunigungssensor am Rad montiert, vorhandene Federung (fully vs. hardtail, mit welcher Dämpfungseinstellung der Federung wurde gefahren), wie hoch ist der Reifendruck, abhängig. Dann gibt es noch temporäre Änderungen der Oberflächenbeschaffenheit (kleine Äste nach einem Sturm, Erdbrocken von Traktoren, Eisbrocken bei unvollständiger Räumung).
Das alles beeinflusst die Beschleunigungswerte, die gemessen werden nicht unerheblich. Aber wie man darüber auf die Beleuchtung schließen soll?
Na, es hilft zwar wenig die Messungen zweier Räder zu vergleichen, aber wenn du das innerhalb der gleichen Fahrt normalisierst ergibt sich sicher ein sinnvolles Bild. Wenn du das dann in Bezug setzt mit der GPS-Position und über mehrere Fahrten hinweg könnte das aussagekräftig sein. Wichtig ist eben nicht der absolut gemessene Wert (welcher auch immer), sondern der Vergleich zu anderen Werten, die eben nicht von deinen genannten Variablen abhängen. Ausreißer (wie den Ast nach dem Sturm) entfernst du über statistische Methoden – soweit die Theorie 
Das schon, aber wie der Bezug von Beschleunigung auf Beleuchtung hergeleitet werden soll, ist immer noch nicht geklärt.
Eher auf Wege-Qualität, das ja, aber nicht auf die Beleuchtung.
Nachts faehrt man (nach meiner erfahrung) eher in schlagloecher, etc. weil man sie nicht sieht. Eine (schwache) KI sollte einen unterschied erkennen, ob es eine veraenderung gibt. Das sagt natuerlich nichts ueber die Lux-Werte an der stelle aus und ob sie rechtlich genuegend ausgeleuchtet ist.
Es sagt nur aus, ob sie gut genug ausgeleuchtet ist um unebenheiten und gefahren gut zu erkennen.
p.S.: immer noch brainstorming
so unterschiedlich sind die Bedürfnisse: wir wären hier froh überhaupt einen Fahrradweg zu haben und keilen uns mit den motorisierten Straßenmitbenutzern, auf den ersten kurvigen, Geschwindigkeits-unbeschränkten Kurven-Kilometern um jeden cm. Ein Fahrradweg entlang der unbeleuchteten Straße wäre schon purer Luxus.
Dagegen ist die Oberflächenbeschaffenheit von Fahrradwegen schon ein Thema, das man mit einem Beschleunigungssensor beurteilen könnte. Schlaglöcher, hochdrückende Wurzeln, nicht ausreichend abgesenkte Bordsteine an Kreuzungen mindern die Akzeptanz von Fahrradwegen.
Allerdings kostet ein zusätzlicher Sensor zusätzliche Energie und vor allem noch Speicherplatz (vor allem auf den Servern).
… bis hin zu einer app, die einem auf unbekannten wegen vor gefahren warnt oder als info bei der tourenplanung. Ist warscheinlich wichtiger als die korrekte ausleuchtung geeicht nach DIN auf +/- 2 Lux zu messen.
Welchen einfluss tag/nacht auf eine strecke haben ist dann eine zusaetzliche erkenntnis. Manche wege sind schlecht ausgeleuchtet warscheinlich ungefaehrlicher als welche, die gerade so den DIN normen entsprechen, aber nachts dennoch gefahren bergen. Vor allem bei naesse und ggf. scheinwerferlich ist es fuer viele deutlich schwieriger nachts hindernisse zu erkennen und die rattern dann drueber.
0,01 bis 0,023 US Dollar pro Gigabyte ist natuerlich schon echt teuer, wenn es zu grossen datenmengen kommt. Wie viel Petabyte braucht man denn da an platz? 
Es ergibt aber wohl mehr sinn, wenn man die daten auf dem Smartphone sammelt. Das ding hat ja einen beschleunigungssensor.
Habe mal die aktuellen preise raus gesucht fuer schreiben, einmal auswerten und dann loeschen oder fuer spaeter archivieren:
Für langlebige Archivdaten, auf die einmal pro Quartal zugegriffen wird und die einen sofortigen Zugriff im Millisekundenbereich erfordern: 0,004 USD pro GB.
Also ca. 3.50 Euro pro TerraByte pro monat. upload traffic inklusive.
Datenmengen sind hier kein Thema. 100 Hz * 6 Achsen * 8 Byte (double precision) * 3600 Sekunden / Stunde = 17 MB pro Stunde Fahrzeit . Komprimiert eher so 5 MB. Muss halt nur effizient geschrieben werden 
das heißt 200000 Stunden Aufzeichnung für oben berechnete 3.50$ im Monat.
Ein solcher mems Sensor kostet auch erstaunlich wenig und braucht vergleichsweise wenig Strom. Ist eine gute Idee die schon lange umhergeisgert, nur niemand hat es bisher gemacht (Again).
I2C Anschlüsse sind auf dem PCB noch frei. Fehlt nur die Firmware Unterstützung.