Minimalste Rohdaten exportieren für Micrcontroller-Kartengerät

Mooin,

nach längerem habe ich endlich wieder Zeit mich ein wenig mit OSM zu beschäftigen :slight_smile:
Bin seit kurzem mit Arduinos am basteln, und wollte nun als Nebenbei-Projekt einen GPS-Logger mit (später) Kartenanzeige realisieren. Luftdruck, Temperatur und Luftfeuchtigkeitssensoren sind unterwegs. Das Logging dieser auf MicroSD-Karte wird als erstes eingebaut. GPS kommt dann nächsten Monat dazu…bt747 habe ich noch rumfliegen.
Die Anzeige einer Karte, aufgezeichneter Strecke und POIs auf einem ultra sparsamen und kleinen Gerät ist das Ziel. Kein Regenunfreundlicher Touch (nämlich gar keiner), sehr gute Lesbarkeit (helles 1,69" Farb-OLED) und der Betrieb ab 3,6 V (LiIon/LiPo/3xNiMh). Unabhängig vom Smartphone, welcher ja sehr Energiehungrig ist, bei Sonner schlecht ablesbar und bei leerem Akku null als Kartenansicht nützt :wink:
Grundkosten: 20-30 € Microcontrollerboard (Teensy 3.2 - Arduino-Kompatibel) und 29 € für 1,69" Farb-OLED inkl. MicroSD-Port.
Irgendein Gehäuse und vorzugsweise der Nokia-Akku aus 747er Logger, da mehrere vorhanden und sehr günstig.
Vielleicht arbeitet jemand hier auch an ähnlichem oder hatte sowas vor - könnte man dann über eine Zusammenarbeit nachdenken :slight_smile: Das ganze natüürlich auf Open-Basis.

Jetzt zur eigentlichen Frage - womit ich mich bisher nie beschäftigt habe:
wie bekomme ich die bestimmte Rohdaten selektiert/exportiert? Benötige für den Anfang rein die Strassen, Orts-/Waldgrenzen. Bezeichnung der Strassen und Orte. Das alles im Textformat. Für dieses wird dann ein Programm erstellt, welches die Daten schon soweit wie möglich vorkaut und komprimiert, da die Leistung des Microcontroller natürlich sehr begrenzt ist.

Gruß
Paul

http://wiki.openstreetmap.org/wiki/DE:Osmfilter wäre meine Wahl.

OSM-Rohdaten sind im XML-Format. Darauf solltest du dann aufsetzen.

Gruss
walter

Danke! :slight_smile: Ja XML ist ja kein Ding - code in C#, wo ich problemlos XML einlesen kann. Wegen der begrenzten Leistung muss ich mir aber eine etwas kompakteres Format ausdenken :wink:

Hoffentlich kein Atmega-basierter Arduino. Damit wirst du bereits beim Loggen an die Grenzen stoßen.

edit: Hatte ich überlesen. Der Teensy dürfte auch schon äußerst knapp werden. Nicht nur die 256 KB Flash, sondern vor allem 64 KB RAM. Wie willst du damit bitte einen Kartenindex lesen?! Du musst dir wohl viel Mühe mit einem geospatial index geben müssen. Alles wird über direkten Zugriff auf die SD-Karte laufen. Du springst dann für jeden Node von Offset zu Offset. Da wird man zusehen können, wie jeder Node gerendert wird. :slight_smile:

Wie wäre es mit selbstgerechneten Bitmaps als Karte so wie es die Standardkarte von OSM auch macht?
Da braucht der Controller nur die Pixel von der SD Karten auf das Diplay zu schicken.

Wie genau das ablaufen wird muss ich mir dann überlegen. Der RAM ist ja der limitierende Faktor - zumindest beim 3.2er. Der 3.5er hat ganze 256 KB Ram. Und es ist ja möglich zusätzliche RAM-Chips anzubauen. Wobei ich das ja nachbaufähig ohne viel Löten bauen möchte.
Irgendwie wird das schon funktionieren. Das meinte ich ja mit vorkauen am PC. Muss halt ein Tool machen, welches die Daten so gut es geht einteilt und vorrechnet. Man braucht hier auch keine genauigkeiten im cm bereich, wenn das Display auf 160 Pixel breite 50 Meter darstellt.
Die Idee kam mir erst gestern Abend, als ich ein GPS-Projekt gesehen habe. Das hatte mich ein mein altes WSG 1000 erinnert (ich glaube so hieß der logger mit dem unbeleuchtetem S/W LC-Display?). Das war mein bisher schönstes GPS gerät. War einfach zu bedienen, konnte einiges und lief mit einer Akkuladung ziemlich lange. Nur Karten darstellen konnte er nicht.

Überlegung heute:

  • Arduino Pro Mini 3.3V 8 Mhz (5-10 €, 33x18 mm klein, 2 Gramm leicht; für die Bedienung des Geräts (Mini-Joystick und Tasten), Auslesen der Sensoren (GPS, Barometer, Temperatur, Luftfeuchte, digitaler LUX-Sensor) und Ansteuerung eines 128x32 Pixel Monochrom OLED. Das wäre für das reine logging ausreichend. Zwischen den Loggingvorgängen kann er schlafen gelegt werden, wodurch der Verbrauch in den uA Bereich geht. GPS dürfte hier das meiste an Strom ziehen…muss man testen, welche Intervalle als Minimum sinnvoll wären, daamit der Logger einige Tage durchhält. Auslesen + Schreiben von Temperatur ist mit einem Akku über Wochen/Monate möglich.

  • Teensy 3.2 (20 €, 35x18 mm klein, 32 Bit M4 mit 72 Mhz - gibts auch mit über 90 Mhz. Takt ist wohl einstellbar. Ist 10 mal so schnell wie ein Atmel 320er 16 MHz). Reine Berechnung und Darstellung der Karte auf einem 160x128 Pixel Farb-OLED. Falls die Darstellung viel Zeit benötigt, kann die Aufgabe auf zwei Teensys aufgeteilt werden. Einer Berechnet, schickt die Daten an den zweiten, welcher nur auf dem Display zeichnet. Die GPS-Koordainten und die Abfrage des Joysticks + Tasten (Bewegung, Zoom, Kartenmenü usw.) übernimmt rein der kleine Andurino und schickt die Daten an den ersten Teensy, welcher die Karte berechnet.

Der Teensy 3.6 wurde vorgestellt. Dieser hat einen M4 mit 180 Mhz sowie 256 KB Ram. Preis soll etwa hälfte über dem des Teensy 3.2 liegen. Also 30 € vs. 20 €.

Wird nur geloggt, so kann der Arduno den/die Teensys schlafen legen, wodurch diese quasi gar keinen Strom verbrauchen. Das große OLED Display kann in der Zeit aus. Das kleine braucht auch nur an zu gehen, wenn Tasten gedrückt werden. Angezegit werden können Anzahl Datensätze, aktuelle GPS-Koordinate, Temperatur uswusw… Vorteil gegenüber anderen Loggern ist, dass man hier alle Paramter direkt einstellen kann. Und alles auf eine Microsd gespeichert wird. Mit 16/32 GB kann man über Wochen Daten loggen, ohne sich Gedanken über den Platz zu machen :wink:

Der Arduino würde einen eigenen MicroSD-Slot bekommen, da der andere fest in dem großen OLED-Display verbaut ist. D.h. man hätte eine Speicherkarte für Logging-Daten und eine mit Kartendaten, die man jederzeit tauschen kann, ohne das Logging zu beeinträchtigen.
Das ist übrigens das Display (Arduino Shield). Kostet bei Mouser.de 29 €:
http://www.newhavendisplay.com/nhd169160128asc3-p-9288.html

Theoretisch könnte man auch jedes andere Display einsetzen. Normale LCD-Displays bekommt man ab etwa 5 €. Teils mit Touchscreen, höheren Auflösungen. In 1.8, 2.2, 2.5, 2.8, 3.2 Zoll. Nachteile dürften der Stromverbrauch und die schlechte Ablesbarkeit bei gutem Wetter sein, wie man das ja vom Handy her kennt.

Das nur so grob. Erste Tests mache ich mit einem 2,8" TFT, das ich hier rumfliegen habe und ein/zwei Arduino Uno @ 16 Mhz. So sehe ich dann was ich an leistung benötige bzw. wie viele Details ich darstellen kann. Daher anfangs rein nur Strassen + Grenzen.

Das wäre nur möglich, wenn genügend RAM da wäre. Das Problem ist, dass man bei 64 KB nicht wirklich sehr viel speichern kann. Da würden nur wenige Pixel passen, wenn man diese in 8 BIt Farbtiefe abspeichert. Be einem Byte pro Pixel sind das ja gerad emal 64 Pixel - dh. ein 8x8 Pixel Icon in 8 Bit Farbtiefe würde den Speicher bereits zu 100% ausnutzen :confused:

Tut mir ja leid, aber ich bezweifle sehr stark, dass das etwas wird. Versuch erst einmal ein paar einfachere Projekte, vielleicht nur ein reiner GPS- oder Barometer-Logger. Alle von dir genannten Lösungen halte ich für nicht realisierbar. Ansonsten:

  • Bitmaps sind immer noch wesentlich speichersparender umzusetzen als Vektordaten
  • Selbst 90 MHz könnten knapp sein
  • 256 KB RAM ist ziemlich wenig
  • Für so viele IO-Komponenten fehlen dir die Pins
  • GPS abschalten = du verlierst ggf. den Fix

Was ich dir empfehle:

  • Entweder ein einfacheres Projekt nehmen, z.B. nur ein GPS-Logger ohne Ausgabe oder andere Sensoren
  • Mächtigeres Entwicklerboard (vllt. sogar ein Raspberry Pi Zero?)

Ein 8x8 Pixel Icon in 8 Bit Farbtiefe sind nur 64 Byte bzw. 192 Byte wenn 8 Bit /RGB Farbe!
Außerdem haben die mir bekannten Displays einen eigenen Speicher, sodass der uC die Daten “nur” von der SD Karten zum Display durchschieben muss.

Wieso sollten die IOs nicht ausreichen…? Der Arduino selbst bestitzt 14 digitale IOs und 7 Analoge IOs. Joystick = 2 anloge. Vier Knöpfe = vier digitale. Die Sensoren und Displays laufen über SPI/I2C.
Das Loggerprojekt kommt ja sowieso als erstes. Sensoren wurden heute verschickt. Ein 0,96" OLED Display habe ich hier, mit welchem ich gerade einen BT-Wecker code. Das mit den Karten wird ja auf diesem aufbauen.
Das wird schon werden…wie gesagt will ich für den Anfang nur ein paar Strassen haben. Die müssen auch nicht in dem Detailgrad vorhanden sein, wie in OSM gespeichert - daher das Vereinfachungs-/komprimierungstool.
Das ganze wird dann in so kleine Bereiche aufgeteilt, dass ich neun davon im Speicher behalten kann. D.h. dass ich in minimalstem Zoom den mittleren anzeige und acht Felder drumherum bereits im Speicher vorberechnet liegen. So kann man scrollen, ohne nachladen zu müssen. Das kenne ich noch von Früher aus der Spieleprogrammierung.
Programmiere übrigens seit ich 12 bin (damals sogar 3D Grafik auf dem C64 programmiert…auf 1 Mhz und mit weniger speicher). Bin mittlerweile fast 38, und weiß, was an sich gehen sollte. Grafikprogrammierung war schon immer ein Schwerpunkt bei mir. Vor allem mit wenig Ressourcen umgehen bzw. die Optimierung dahin.
Ich glaube nicht, dass ein 10 Jahre alter Garmin-Handheld mehr CPU Leistung und RAM hatte als der Chip hier. Eher weniger, würde ich behaupten. Und es funktioniert :wink:

Zur Leistung des neuen Teensy 3.6 hier ein VIdeo. Kommentar vom Programmierer darunter: “Yes, it is uncompressed 3202402 Bytes/Pixel, 24FPS. More FPS are possible :slight_smile: This is 3.5MB/s transfer SD->Teensy plus 3.5MB/s transfer Teensy->Display.”)

https://www.youtube.com/watch?v=cyGIW3KFrtw&t=0s

Raspi fällt aus wegen Stromverbrauch. Das ganze soll vieele Stunden bzw. Tage laufen. Das reine logging ja eher Wochen. Mit Raspi - auch dem Zero - würde das ganze vielleicht einen Tag laufen. Der Zero gönnt sich 40-80 mA im Idle. Ohne Display, Abfrage Sensoren, speichern der Daten usw… Der Arduino mi 16 MHz kann bei 3 Volt im Schlafmodus auf < 8 uA gebracht werden. Sonst nimmt der sich auch nur wenige mA wenn er läuft. Man muss ihn nur einige male in der Sekunde kurz wecken, um Status der Knöpfe abzufragen und in bestmmten intervallen die Sensoren abzufragen.
KLar geht der Fix beim Abschalten des GPS verloren - ist dann aber theoretisch schnell wieder da. Was sind normale Fixzeiten? 2-5 Sekunden? Man entfernt sich ja nur paar Meter, weshalb der Fix sehr schnell wieder kommen sollte. Wenn ein Aufzeichnungsinterval von 15 Sekunden gewählt wird, dann kann das GPS für 10 Sekunden jeweils aus= 2/3 Stromersparnis bzw. 3-fache Laufdauer des Loggers. Muss man halt testen, was hier möglich ist. Theoretisch müsste das GPS MOdul aber auch eine Art Sleepmode haben, wo er das GPS SIgnal vielleicht seltener abfragt und so Strom spart.

@fx99: Ups…hast natrlich Recht ;> Hmm…das ist interessant. Mit Displayprogrammierung hatte ich bis jetzt noch nicht zu tun. Ein Buffer im RAM würde denke ich bei den 64 KB keinen Sinn machen…das wird zu knapp. D.h. eher direkt auf dem Display zeichnen. Bei dem Teensy 3.6 sieht das dann anders aus. Man müsste nur testen,w as schneller geht. Die Bibliotheken zeichnen von selbst direkt auf das Display (oder auf den RAM des Displays? Wird da doch gepuffert?). Wenn ich im RAM einen Puffer aufbaue, dann muss ich selbst die Zeichenroutinen programmieren. Ob das dann effektiver läuft…

Nicht ganz was Du suchst, aber evtl. trotzdem interessant:
Delicious 3D Maps Baked into a RaspberryPi

Willst Du das wirklich alles selbst basteln? Weiß nicht, ob da eines dieser Frameworks infrage kommt, aber so was wie Vector Tiles wäre vermutlich schon hilfreich, z.B. das Mapbox Vector Tile Format ist sehr kompakt und fürs Rendering optimiert:
https://github.com/mapbox/awesome-vector-tiles
https://github.com/systemed/tilemaker
http://osm2vectortiles.org/

Danke für die LInks :slight_smile: Drei der Frameworks habe ich gestern bereits geladen.
Fertige Vektorsachen bringen mir leider nichts - ich muss ja einfach nur das eingelesene XML-Zeug für mich umkonvertieren. Z.B. werden die GPS-Koordinaten abgespeckt und auf Gnazzahl umgerechnet → Spart RAM. Der Mikroprozessor hat 64 KB RAM. Dazu kommen 4 x 128 KB Speicherchips, die ich die letzten Tage recherchiert habe. So hätte ich einen halben MB an RAM. Da muss auf jedes Byte aufgepasst werden, was man speichern möchte. Das selbe ja schon bei den Dateien selbst, welche von der Teilgröße her auf den Ram angepasst werden müssen sowie schon alleine von dem Dateiaufbau auf möglichst schnelles Einlesen optimiert sind. Der Microprozessor schafft es wohl auf 200-250 kb/sek. Man will ja nicht mehrere Sekunden warten, wenn man nur ein wenig die Karte gescrollt hat :slight_smile: Hinzu kommt noch eine Optimierung der Daten selbst - d.h. Vereinfachung von Strassen/Flächen auf weniger Punkte.
Die Raspi-3D-Karte ist lustig :slight_smile: Allerdings läuft das ganze nicht mal einen Tag. Alleine das riesige Display dürfte schon ne Menge Strom schlucken :confused: Bin gespannt was das 1,8" TFT bereits nimmt.

Bei MVT sind die Koordinaten relativ zum Tile kodiert, siehe
https://www.mapbox.com/vector-tiles/specification/#encoding-geom

Das wird für die Tiles abhängig vom Zoomlevel gemacht. Tag Strings werden nur einmalig gespeichert und referenziert.

Mit Rohdaten musst du noch die Way-Nodes auflösen, für Flächen-Multipolygone die Ways und deren Nodes und diese noch in die richtige Reihenfolge bringen. Und mit Tiles wird das Selektieren der Daten für den aktuellen Ausschnitt einfach.

Ich weiß nicht, was Du da speziell anders machen willst, wollte nur anmerken, dass es für die Aufbereitung von Rohdaten fürs Rendering eigentlich schon genug Tools gibt.

Ich will ja nicht rendern, sondern in einem eigenen Vektor-Format abspeichern. Das ist der Unterschied :wink: Und je nach Zoomstofe die Details der Polygone zu setzen verstößt da schon gegen zwei Paramter: Rechenleistung und Speicherbedarf. Niedrigste Detailstufe = niedrigster Speicherbedarf und geringste Auslastung = es kann mehr angezeigt werden und/oder läuft flüssig(er).

Das was die Tools da ausspucken - auch wenns im Vektorformat wääre - müsste ich trotzdem noch verarbeiten/komprimieren. Es soll später von der Bedienung her einfach sein → OSM Datei wählen → Konvertierte Datei auf MicroSD → Karte ins Gerät + Einschalten. Fertig. Damit soll ja jeder umgehen können, der sich das Gerät nachbaut. Und nicht erst in fünf Tools einarbeiten.

Das Umwandeln von Vektordaten in ein Bild /Pixel nennt man in dieser Welt “rendern”. Wie auch immer Du es drehst,
darum wirst Du nicht herumkommen. Die allgemeine Idee hier ist, diese Aufgabe off-line machen (zu lassen).

Ich weiß ziemlich genau was rendern ist - bereits in den 90ern mit 3D Studio und POV-Ray “gespielt” :wink: Ich rede hier doch nicht vom rendern - ich rede von OSM-XML-Datenformat in ein eigenes, viel kompakteres und auf den kleinen Speicher des Microprozessors otpmiertes Vektorformat (Punkte, Linien und Polygone) umzuwandeln. Nix Pixel. Das soll ja am PC mit einem Konvertierungstool erfolgen. Die aufbereiteten Daten kommen dann via SD-Karte in das Gerät.

Grobes Beispiel:

Aus den OSM Daten:








Wird das generiert:
007Strasse Blahblah 00251299980092300995130004909230130

3-Stellige ID für den Typ (hier: highway), Name (16-20 Stellig düfte reichen), Anzahl Punkte (hier: 002). Danach je 16 Stellig die Punkte. Koordinaten werden auf 6 Nachkommastellen gekürzt, damit die Koordinaten in eine Long-Variable passen. Halber Speicherbedarf + mehrfach schnellere Multiplikation und Division.

Da alle mir gekannten Displays aus Pixeln aufgebaut sind, muss diese Umwandlung von Vektor Daten in Pixel (Rendern) irgendwann irgendwo erfolgen.

Ehm…das wird dann natürlich am Gerät selbst gemacht. Wie bei Garmin-Geräten, wenn man dort Vektorkarten nutzt. Die “Teils” werden im Textformat vorliegen - wie die vorgerenderten. Sodass er schnell aus 9 Dateien die aktuelle Position + Umgebung laden kann.
Falls das Laden, Berechnen und Darstellen zu langsam sein sollte, bekommt der noch einen Coprozessor, der sich nur um die Ausgabe kümmert.

Das Rendern am Gerät ist auch Pflicht, da ich bei dunkler Umgebung (daher auch der LUX-Helligkeitssensor) den Bildschirminhalt entsprechend automatisch anpasse. Die OLED Displays sind pervers hell…ích baue gerade einen Bluetooth Wecker mit einem 0,96" Monochrom-OLED. Die Uhrzeit in dünner, ca. 6 mm hoher Schrift wirft auf gut 3 Meter noch Licht auf die Wand bzw. einen sichtbaren Schatten, wenn man dazwischen steht. Das Display komplett gefüllt kann schon fast als Taschenlampe genutzt werden - und die Pixel hier sind nur Türkis und nicht weiß. Daher muss eine zwei/drei Stufige Anpassung des Inhaltes an das Umgebungslicht erfolgen. Bei absoluter Dunkelheit wird der Kontrast zusätzlich abgenommen, damit man nicht von den Linien geblendet wird.

Du solltest beachten, daß sich etliche Ways Nodes teilen … dann speicherst du die Nodes doppelt.

Gruß Klaus

Yep…das ist mir auch schon aufgefallen. Wäre auf jeden Fall sparsamer die Nodes mit ID abzuspeichern und bei den Objekten nur die Node-IDs, als die Koordinaten mehrfach. Gehn halt je 2 Byte extra mit drauf für ID je Node.

Also eher so in der Datei:
007Strasse Blahblah 0020000100002
000015129998009230099
000025130004909230130

OSM speichert das so ab:

  • alle Nodes mit Id, lat/lon und Tags
  • alle Ways als Listen der verwendeten Nodes + Tags
  • alle Rels als Listen der verwendeten Member + Tags

und das hat durchaus seine Gründe :wink:

Gruss
walter