ATMEL-Programmierer für OSM-Projekt gesucht

Sehe ich das richtig das du einfach nur den Druck von den Sensoren einlesen willst und auf SD-Karte schreiben?
Oder hast du auch vor zusätzlich ein GPS-Empfänger auszulesen?
Ein GPS-Modul ist dann der große Stromfresser dieses benötigt glaube ich um die 40 mA.
Was ist der Sinn dieser Basisstation? Hast du vor die Geräte über Funk miteinander Kommunizieren zu lassen?
Oder benötigst du nur den Druckverlauf an einer bekannten Höhe? Hierfür würde es ja reichen ein “Mobilteil” an der Stelle über den gesamten Messverlauf liegen zu lassen.
Willst du die Daten gleich in einem FAT-Dateisystem auf die SD-Karte schreiben oder reicht es wenn du die SD-Karte als Speicher verwendest und diese nur mit einem Spezialprogramm oder Speziellen Kartenleser auslesen kannst?
Wie funktioniert die Synchronisation zwischen den Mobilteilen und der Basisstation?
Was hast du dir für eine Stromversorgung gedacht?
Wie lange soll so eine Messung den laufen?
Wie schwer und wie groß soll das Gerät werden?
Bei den Genauigkeit muss man auch beim Aufzeichnen immer drauf achten das der Abstand zum Boden sich nicht verändert. Also mal kurz in die Hand nehmen und schauen ob es noch aufzeichnet ist schon problematisch.

Nur weil ich so detaillierte Fragen stelle heisst es noch nicht das ich Zeit zum bearbeiten habe.
Aber ich denke das dies ein paar von den Fragen darstellt die sich jemand hat der bei dem Projekt mitarbeiten will.
Ich will auch keine Diskussion anfangen was machbar ist und was nicht.

Gruß
badger

Mich würde noch interessieren, wie das Gelände erfasst werden soll:

linienartig, anhand der gelaufenen tracks entlang der Wege,
oder
flächenhaft, anhand von gelaufenen Rastern
oder
flächenhaft abgeflogen mit Flughöhensensor?

Wie wird im ersten Fall ein Höhenmodell erzeugt? Ich sehe da große Lücken in der Erfassung

Wie wird die Lage korrigiert (DGPS mit der Lage des Höhenreferenzpunktes?)?
Ich sehe die üblichen Probleme bei der kombinierten Lage/Höhenerfassung im steilen Gelände, und gerade hier ist es für Wanderer interessant.

Horst

Du siehst also, es gibt zumindest ausreichend “Interessierte” :slight_smile:

Stimmt OTM ist down: http://wiki.openstreetmap.org/wiki/OpenTopoMap
Ich fände es cool, wenn man das SRTM per Hand verfeinern könnte also z.B. durch eine Art bemalbare Heatmap, durch Importe,…

Danke für Eure Fragen - ich werde diese in einem Wiki-Artikel aufgreifen und beantworten :wink:

Du meinst http://explorerspal.org/? Die beiden sitzen gerade beim Dresdner Stammtisch neben mir und meinen, dass es Berührungspunkte geben könnte.

Viele Grüße, wir Dortmunder treffen uns am Sonntag.

Es gibt sicherlich Berührungspunkte, allerdings kostet ein Sensor 20-40 EUR (je nach Genauigkeit). Wenn man dies mit dem GPS-Modul und dem großen Display kombinieren würde, überspannt man die Ausgabetoleranz eines normalen Mappers :wink:

Unsere alte Planung war (ohne Entwicklungskosten):
Platine (4 EUR) + Bauteile (6 EUR) + Sensor (20-40 EUR) = 30-50 EUR. Die meisten Mapper haben schon ein GPS-Gerät und die Höhenmessung würde sowieso autonom laufen - naja, Start & Stop/Pause :wink:

Ich schreibe heute Nacht mal den Artikel dazu. Da der Sensor unter 1x1 cm ist und sowieso Digitalsignale auswirft, wird es problemlos möglich sein, diesen in den “Explorer’s Pal” zu integrieren. Ihn komplett auf das Gerät abzustimmen halte ich leider aus den genannten Gründen für unwirtschaftlich - für den normalen Mapper jedenfalls.

Ich bin ja mal auf die Wikiseite gespannt.
Die Synchronisation zwischen externem GPS und Höhenmesser ist allerdings nicht einfach.
Dies funktioniert nur wenn man zusätzlich noch eine RTC oder DCF77 mit vorsieht.
Auf der Platine würde ich aber auch ein GPS-Modul vorsehen dieses gibt es auch schon für unter 30 Euro.
voelkner
Welche Bauteile bestückt werden kann dann der Anwender selber entscheiden.
Mit dem GPS-Modul würde das ganze ein eigenständiger Logger darstellen.

Es kam bei OSM noch nie auf den Millimeter an. Alleine aufgrund der Verwendung von unkorrigiertem GPS kann man sowieso keine hohe Lagegenauigkeit erreichen.

Aber wie Du schon sagst, sollte RTC oder DCF77 onboard sein. RTC würde Intelligenz beim User voraussetzen, DCF77 Intelligenz beim “Designer” :wink:

Hmm spricht was gegen eine Bluetooth Kopplung, so dass man die gesamte Intelligenz auf einen PDA,… auslagern und so flexibler bleiben?

Bluetooth ist mit BTM-222 möglich.
Kostenpunkt 10 Euro und 114 mA bei 3V3
Das könnte sogar direkt SPI sprechen.
Kann man am PDA eigentlich mehrere Serielle Bluetoothverbindungen parallel betreiben?
Ich könnte mir vorstellen das man eine Platine erzeugt die wahlweise unterschiedlich bestückt werden kann.
Die Software wird dann durch eine Konfigurationsdatei an die Gegebenheiten angepasst.

Optionale Bauteile währen dann:
Druckmesser, SD-Karte, RTC, DCF77, GPS, Bluetooth, RS232.

Jups und man kommt mit nem deutlich kleineren Mikrocontroller hin. RS232 naja wenn man dann noch nen FTDI reinbaut kann man das ja per USB tunneln aber ich denke da hat man mit Bluetooth eine etwas breitere Unterstützung für mobile Datengeräte.

Meines Wissens können die ganzen BT Stacks nur eine SPP Kopplung herstellen. Gut Linux gehen sicherlich auch mehere… Aber das müsste ich wirklich mal ausprobieren…

DCF könnte dadurch ja auch weggelassen werden, da man die Zeit vom PDA und auch vom GPS bekommen kann.

Ich dachte da ehr an eine flexible Lösung

Will man den Drucksensor mit dem PDA verbinden so baut man auf die Platine nur
Drucksensor und BTM-222 (Bluetoothmodul)

Will man nur den Druck loggen
Drucksensor, DCF77, SD-Karte

Verzichtet man auf DCF77 braucht man
Drucksensor, SD-Karte, RTC, RS232 zum stellen der RTC

Will man ein kompletten Logger
Drucksensor, GPS, SD-Karte

Selbst ein einfacher Logger mit GPS + SD-Karte wäre möglich

Software ist dann so flexibel das sie die Daten entweder auf SD-Karte speichert, per Bluetooth versendet oder beides gleichzeitig.

Auch die Wahl zwischen RS232 und FTDI ist denkbar.

@TobWen wie weit ist den der Wiki-Artikel?

Das würde bestimmt gehen, wenn man das Sandwitch mäßig baut.

Gibt es schon eine Wikiseite TobWen?

Übrigens wurde jetzt die Kinect Bewegungssteuerung von MS gehackt. Die hat auch eine Kamera für Tiefeninformation :slight_smile:
http://www.heise.de/newsticker/meldung/Open-Source-Treiber-fuer-Kinect-veroeffentlicht-1135025.html

Wer also schon immer preiswert Schlaglöcher scannen wollte, hat jetzt die Möglichkeit dazu :smiley:

Ist denn schon was konkretes rausgekommen TobWen?

@!i!: Nein - habe eigentlich gar kein Feedback bekommen… aber ich werde jetzt endlich die Wikiseite fertig machen.

Es ist jetzt übrigens ein Projekt gestartet, was sich hervorragend damit ergänzt:
http://wiki.openstreetmap.org/wiki/OpenDEM

Hi!

Kennt ihr bereits unser Projekt?
http://www.explorerspal.org/

Eventuell kann man den Sensor außen an das serielle Port anschließen und die Daten dann zusammen mit den anderen Informationen einsammeln.
Auf jeden Fall ist bei uns schon einiges an Grundfunktionen zur Bedienung entstanden.

Gruß, Thomas.

Ah ihr seid das :slight_smile: Ne super Sache, auch wenn ich die Entwicklung kompletter Hardware für das loggen ein wenig überdimensioniert empfinde :wink: Das Problem ist glaube ich immernoch der Höhensensor an sich und den permanent zu kalibrieren.

Cool wäre es, wenn OpenDEM mal eine Karte für heightpainting anbieten würde, dann könnte man quasi wie beim Sculping sich langsam aber sicher an das Aussehen ranmachen.

So ein blöder Mist: Meine neue Studienausrichtung verschlingt doch mehr Zeit, als ich gedacht habe. Ohne Scherz: ich habe dieses Projekt total vergessen, obwohl mich Marcus vor einigen Wochen nochmal daran erinnert hat.

Offtopic: Ich finde es beängstigend, wie sehr sich ähnliche Studiengänge an anderen Universitäten unterscheiden. Auch dazu scheint die Verkehrsanbindung der Universität irgendwie mit der Lernmoral der Studierenden zu korrelieren :slight_smile:

Jo das kann ich nur bestätigen Tobias. Aber das ist an einer einzelnen Uni bei unterschiedlichen Profs schon teilweise ziemlich krass. So nun aber genug offtopic :slight_smile: