-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
German B4A & Augmented Reality?
- Thread starter Kiffi
- Start date
- Similar Threads Similar Threads
Hmm..so wie etwa diese Sachen hier?
Ãœberblick: Augmented Reality - Android Forum - AndroidPIT
Die Kernproblematik ist die enorme erforderliche Rechenleistung, falls du mit Bilderkennung arbeiten willst. Selbst ein moderner Mehrkern-PC kommt schnell ins schwitzen bei solchen Dingen. Das Kamerabild kombinieren mit Kompass Angaben ist nicht sooo rechenintensiv, aber wenn du zB noch zusätzliche Sachen willst wie GPS, Geschwindigkeit, Distanzen etc bei 25 FPS mit Analyse des Kamerabild-Inhaltes um bestimmte Sachen am richtigen Ort auf dem Screen zu paltzieren wird's schnell zappenduster (mit dem Akku sowieso
Wie gesagt, es hängt sehr davon ab was du machen willst, sonst sind nur pauschale Aussagen möglich.
Ãœberblick: Augmented Reality - Android Forum - AndroidPIT
Die Kernproblematik ist die enorme erforderliche Rechenleistung, falls du mit Bilderkennung arbeiten willst. Selbst ein moderner Mehrkern-PC kommt schnell ins schwitzen bei solchen Dingen. Das Kamerabild kombinieren mit Kompass Angaben ist nicht sooo rechenintensiv, aber wenn du zB noch zusätzliche Sachen willst wie GPS, Geschwindigkeit, Distanzen etc bei 25 FPS mit Analyse des Kamerabild-Inhaltes um bestimmte Sachen am richtigen Ort auf dem Screen zu paltzieren wird's schnell zappenduster (mit dem Akku sowieso
Wie gesagt, es hängt sehr davon ab was du machen willst, sonst sind nur pauschale Aussagen möglich.
Hallo Roeschti,
danke für Deine Antwort!
über ein Gelände. Auf dem Gelände stehen verschiedene Gebäude.
Nun schaut dieser Jemand durch sein Phone über die Kamera auf ein Gebäude
und jetzt soll 'auf' dem Gebäude eingeblendet wird, um was es sich hierbei
handelt.
So ungefähr wie hier das: http://goo.gl/0XjrY
Spielt hier schon eine Art Bilderkennung mit rein? Oder ist das rein durch
Koordinatenangaben lösbar?
Grüße ... Kiffi
danke für Deine Antwort!
die Idee ist folgende: Jemand spaziert mit seinem Phone oder Tablet
über ein Gelände. Auf dem Gelände stehen verschiedene Gebäude.
Nun schaut dieser Jemand durch sein Phone über die Kamera auf ein Gebäude
und jetzt soll 'auf' dem Gebäude eingeblendet wird, um was es sich hierbei
handelt.
So ungefähr wie hier das: http://goo.gl/0XjrY
Spielt hier schon eine Art Bilderkennung mit rein? Oder ist das rein durch
Koordinatenangaben lösbar?
Grüße ... Kiffi
Naja, es kommt sehr darauf viel man beschei...en kann im Sinne von Vorberechnungen.
Wenn du zB die möglichen Gebäude kennst, deren exakte Standorte/GPS Koordinaten und was du zu einem Gebäude anzeigen willst, das ganze noch in einem definierten Bereich des Displays, dann ist's easy.
Das Prinzip wäre so:
Anhand des GPS weisst du wo du bist, anhand des Kompasses und/oder GPS in welche Richtung du schaust. Anhand deiner Position kannst du ermitteln, ob eines der bekannten Gebäude in Reichweite ist. Ist dem so, kannst du die Distanz berechnen und von dir aus gesehen in welche Richtung das möglich Gebäude steht. Nun definierst du einen Erfassungswinkel und prüfst, ob das Gebäude relativ im Erfassungswinkel liegt. Wenn ja, Daten anzeigen.
Etwas konkreter vielleicht: Du schaust mit dem Gerät nach Süden dh 180 Grad auf'm Kompass. Erfassungswinkel ist +- 40 Grad. Gesucht ist Gebäude A, welches sich berechnet 20m entfernt befindet, aber in Richtung Osten dh also auf 90 Grad. Nun drehst du dich langsam Richtung Osten. Die Kompassgrade wandern also von 180 Grad Stück für Stück runter Richtung 90 Grad. Erfassungswinkel ist 40 Grad dh wenn der Kompass Wert zwischen 110 und 70 Grad liegt, ist das Gebäude mehr oder weniger direkt vor dir sichtbar, somit Treffer, somit Daten zum Gebäude A anzeigen.
Je kleiner der Erfassungswinkel, desto präziser die Unterscheidung von einzelnen Gebäuden, aber umso schwieriger für den User das Gerät ruhig zu halten. Das Kamerabild ist also in diesem Verfahren reiner Gimmick, da damit nichts gemacht werden muss, da alles über Positions-Daten und Winkel berechnet wird. Das ist übrigens praktisch so wie die gute alte VOR Navigation bei den Fliegern ( Drehfunkfeuer – Wikipedia )
Willst du aber etwas in der Art von Google Goggles nachbauen, wird es sehr schwer. Du musst über eine Art Mustererkennung das gesuchte Gebäude mit bekannten Muster vergleichen, um das richtige zu finden. Das ist eben das extrem rechenintensive und wird normalerweise auf einer Serverfarm durchgeführt (wie etwa die Spracherkennung vom neuen Ei-Phoon).
Dann kommt die Schwierigkeit - Echtzeit oder eingefroren? Bedeutet: Muss der Benutzer ein Gebäude anpeilen und einen Auslöser drücken, damit du nur 1 Bild analysieren musst oder soll es kontinuerlich passieren, falls der Benutzer sich bewegt, mit dem Gerät wackelt und ohne Benutzer Interaktion die Erkennung laufen soll. Bei eingefroren = Einzelbildanalyse musst du eine Rückmeldung an den Benutzer liefern, damit er weiss dass sich etwas tut und wie lange es noch dauert.
Bei Echzeit (oder halt so schnell wie möglich) musst du einen Taktgenerator haben um auf flüssige Bewegungen zu kommen, idealerweise also ab etwa 24 Bilder pro Sekunde(!) (btw: wäre ideal um Multithreading zu üben ;-) sollte dies so gemacht werden, musst du dir die Abbruch Bedingungen überlegen..dh also im 12. von sagen wir 24 Bildern pro Sekunde wurde das Gebäude erkannt, also Prüfung stoppen und Daten anzeigen. Oder wenn der Benutzer während der Prüfung weiterschwenkt zum nächsten Gebäude, soll das alte weitergesucht werden oder das neue? Und wann ist "neues Gebäude"?? Wieviel Bildunterschiede zum vorherigen sollen also zum Abbruch der Prüfung führen und neue Prüfung gestartet werden? Und wann soll generell überhaupt eine Erkennung/Prüfung gestartet werden und und und.
Hoffe dies hilft dir ein wenig weiter, ist auf jedenfall ein spannendes Betätigungsfeld :sign0089:
Wenn du zB die möglichen Gebäude kennst, deren exakte Standorte/GPS Koordinaten und was du zu einem Gebäude anzeigen willst, das ganze noch in einem definierten Bereich des Displays, dann ist's easy.
Das Prinzip wäre so:
Anhand des GPS weisst du wo du bist, anhand des Kompasses und/oder GPS in welche Richtung du schaust. Anhand deiner Position kannst du ermitteln, ob eines der bekannten Gebäude in Reichweite ist. Ist dem so, kannst du die Distanz berechnen und von dir aus gesehen in welche Richtung das möglich Gebäude steht. Nun definierst du einen Erfassungswinkel und prüfst, ob das Gebäude relativ im Erfassungswinkel liegt. Wenn ja, Daten anzeigen.
Etwas konkreter vielleicht: Du schaust mit dem Gerät nach Süden dh 180 Grad auf'm Kompass. Erfassungswinkel ist +- 40 Grad. Gesucht ist Gebäude A, welches sich berechnet 20m entfernt befindet, aber in Richtung Osten dh also auf 90 Grad. Nun drehst du dich langsam Richtung Osten. Die Kompassgrade wandern also von 180 Grad Stück für Stück runter Richtung 90 Grad. Erfassungswinkel ist 40 Grad dh wenn der Kompass Wert zwischen 110 und 70 Grad liegt, ist das Gebäude mehr oder weniger direkt vor dir sichtbar, somit Treffer, somit Daten zum Gebäude A anzeigen.
Je kleiner der Erfassungswinkel, desto präziser die Unterscheidung von einzelnen Gebäuden, aber umso schwieriger für den User das Gerät ruhig zu halten. Das Kamerabild ist also in diesem Verfahren reiner Gimmick, da damit nichts gemacht werden muss, da alles über Positions-Daten und Winkel berechnet wird. Das ist übrigens praktisch so wie die gute alte VOR Navigation bei den Fliegern ( Drehfunkfeuer – Wikipedia )
Willst du aber etwas in der Art von Google Goggles nachbauen, wird es sehr schwer. Du musst über eine Art Mustererkennung das gesuchte Gebäude mit bekannten Muster vergleichen, um das richtige zu finden. Das ist eben das extrem rechenintensive und wird normalerweise auf einer Serverfarm durchgeführt (wie etwa die Spracherkennung vom neuen Ei-Phoon).
Dann kommt die Schwierigkeit - Echtzeit oder eingefroren? Bedeutet: Muss der Benutzer ein Gebäude anpeilen und einen Auslöser drücken, damit du nur 1 Bild analysieren musst oder soll es kontinuerlich passieren, falls der Benutzer sich bewegt, mit dem Gerät wackelt und ohne Benutzer Interaktion die Erkennung laufen soll. Bei eingefroren = Einzelbildanalyse musst du eine Rückmeldung an den Benutzer liefern, damit er weiss dass sich etwas tut und wie lange es noch dauert.
Bei Echzeit (oder halt so schnell wie möglich) musst du einen Taktgenerator haben um auf flüssige Bewegungen zu kommen, idealerweise also ab etwa 24 Bilder pro Sekunde(!) (btw: wäre ideal um Multithreading zu üben ;-) sollte dies so gemacht werden, musst du dir die Abbruch Bedingungen überlegen..dh also im 12. von sagen wir 24 Bildern pro Sekunde wurde das Gebäude erkannt, also Prüfung stoppen und Daten anzeigen. Oder wenn der Benutzer während der Prüfung weiterschwenkt zum nächsten Gebäude, soll das alte weitergesucht werden oder das neue? Und wann ist "neues Gebäude"?? Wieviel Bildunterschiede zum vorherigen sollen also zum Abbruch der Prüfung führen und neue Prüfung gestartet werden? Und wann soll generell überhaupt eine Erkennung/Prüfung gestartet werden und und und.
Hoffe dies hilft dir ein wenig weiter, ist auf jedenfall ein spannendes Betätigungsfeld :sign0089:
Hallo Roeschti,
vielen lieben Dank für Deine ausführlichen Infos! :sign0098:
Einiges in Deinen Ausführungen liest sich sehr
interessant und machbar. Die Anzeige der Daten
anhand bekannter Koordinaten sollte möglich sein.
Werde unseren Praktikanten mal die Tage auf unserem
Firmengelände umherschicken, damit der 'Feld'-Versuche
durchführen kann.
Nochmals Danke & Grüße ... Kiffi
vielen lieben Dank für Deine ausführlichen Infos! :sign0098:
Einiges in Deinen Ausführungen liest sich sehr
interessant und machbar. Die Anzeige der Daten
anhand bekannter Koordinaten sollte möglich sein.
Werde unseren Praktikanten mal die Tage auf unserem
Firmengelände umherschicken, damit der 'Feld'-Versuche
durchführen kann.
Nochmals Danke & Grüße ... Kiffi