|
|
|
|
egal wie die lösung aussieht: ich will sie kennen
mir würde schon das thema mit dem winkel reichen.
|
|
|
|
|
|
|
N kompass allein hilft mir doch nix
[e] Jonny, aufgegeben hab ich noch lang nich
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von LoneLobo am 20.01.2013 20:25]
|
|
|
|
|
|
Nee, alleine nicht, aber irgendwas in der Form brauchste halt doch.
|
|
|
|
|
|
|
ich auch nicht, aber ich trete irgendwie gerade auf der stelle
die "beschleunigungsachse" bleibt beim drifte ja auch nicht gerade gleich... anstellwinkel der räder geht auch nicht... die bodenkamera haben wird seit langem verworfen...
|
|
|
|
|
|
|
Ich glaube nach wie vor dass was optisches am sinnvollsten ist...
|
|
|
|
|
|
|
| Zitat von LoneLobo
Ich glaube nach wie vor dass was optisches am sinnvollsten ist...
| |
Eine Drohne, die dein Auto von oben filmt?
quake.
|
|
|
|
|
|
|
|
|
|
|
...was meinst du warum ich ganz am Anfang vermutet hab, dass die softwaretechnische auswertung vermutlich etwas aufwändiger ist
| Zitat von dancing_quake
| Zitat von LoneLobo
Ich glaube nach wie vor dass was optisches am sinnvollsten ist...
| |
Eine Drohne, die dein Auto von oben filmt?
quake.
| |
Ein Pinsel am Unterboden der Striche auf den Boden malt - eine Weitwinkelkamera schaut dann einfach, wo der Strich hinterm auto rauskommt /o/
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von LoneLobo am 20.01.2013 20:41]
|
|
|
|
|
|
wobei mir gerade auffällt, dass man bei der optischen variante ja sogar den winkel direkt mitberechnen könnte
der untergrund geht ja dann nicht mehr gerade unter der kamera druch \o/
|
|
|
|
|
|
|
wtf.
Darum gehts doch, kerl
Kasten sauber ausrichten, Geschwindigkeitsvektor anhand der Bilder ausrechnen.
Winkel zwischen y-Komponente und Gesamtvektor und fertig.
|
|
|
|
|
|
|
da kommt aber das nächste wtf:
bei 20km/h sind das schon 5,5m/s die abgebildet werden müssen
wieviel fps das wohl sind, damit das ergebnis halbwegig brauchbar ist
|
|
|
|
|
|
|
Sehr schön, der Herr nähert sich langsam der Grundlage meines ersten Posts hier zu dem Thema, so kanns weitergehn
|
|
|
|
|
|
|
kann ich deine gedankengänge im vorfeld nachvollziehen?
lobo uses math!
ausgehend von 720p bzw. 10,8x6,1cm filmfläche kann man da doch ein nettes rechenbeispiel machen
|
|
|
|
|
|
|
Für den Fluxkompass brauchst du aber auch nen Fluxkompensator, vergiss den nicht!
- Kamera, viele Power-LEDs, kurze Belichtungszeit, kleiner Sensor und mittlere Brennweite (große Fokusebene), ...?
Und irgendwie so ein Laserding, was ein Quadrat oder Gitter projeziert.
Das sieht dann sicher interessant unterm Unterboden aus. Auch für die Cops ...
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 20.01.2013 20:59]
|
|
|
|
|
|
sagt mir lieber, wie ich den scheiß berechne
|
|
|
|
|
|
|
würde vermuten dass die frames eher so schnell sein müssten, dass sich die elemente auf der fläche um max. n zehntel der gesamten achse bewegen dürften um da noch ausreichend material zu haben.
Also bei nem Bild von 10 cm dann max. 1 cm bewegung zwischen frame 1 und 2.
Wenn du da 8 cm bewegung hast, ist das einzige was die software "wiedererkennen" kann, n streifen von 2 cm. Wird nicht genügen, so gleichmäßig wie das ist.
Das mit der prämisse dass es bis ca. 250 km/h funktionieren sollte, liefert dann vermutlich ne FPS zahl die gar nich ma soooo cool is.
Das is ja das problem
|
|
|
|
|
|
|
so ähnlich war mein gedankengang gerade auch. die cam muss ja irgendwo die "muster" wiedererkennen, damit man daraus was errechnen kann. da hilft dir aber mit sicherheit auch keine optische maus was
|
|
|
|
|
|
|
| Zitat von csde_rats
Für den Fluxkompass brauchst du aber auch nen Fluxkompensator, vergiss den nicht!
- Kamera, viele Power-LEDs, kurze Belichtungszeit, kleiner Sensor und mittlere Brennweite (große Fokusebene), ...?
Und irgendwie so ein Laserding, was ein Quadrat oder Gitter projeziert.
Das sieht dann sicher interessant unterm Unterboden aus. Auch für die Cops ...
| |
Genau deshalb die Randbedingung, dass Licht nicht verwendet wird.
N Laserstreifen auf Asphalt unterm Auto dürfte wenig kritisch sein, wenn da allerdings 30 Watt an LEDs rumkacken...
| Zitat von jonny
so ähnlich war mein gedankengang gerade auch. die cam muss ja irgendwo die "muster" wiedererkennen, damit man daraus was errechnen kann. da hilft dir aber mit sicherheit auch keine optische maus was
| |
Macht die das nicht auch so?
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von LoneLobo am 20.01.2013 21:02]
|
|
|
|
|
|
|
Code: |
Max. Geschwindigkeit: bis zu 4,19 m/s
USB-Signalrate: bis 1.000 Signale/Sekunde
|
|
bsp: g500 von logitech
damit wärste dann bei 15,084km/h bei 1000fps /o\
|
|
|
|
|
|
|
...ups
|
|
|
|
|
|
|
du verstehst meine kopfschmerzen inzwischen?
bei dem preis könnte man davon natürlich n-stück nehmen und die asynchron takten
was dahinter dann allerdings für ein quantencomputer sitzen müsste...
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von jonny am 20.01.2013 21:07]
|
|
|
|
|
|
Ich glaube wir einigen uns vorerst mal drauf, dass das augenscheinlich simpel zu lösende problem beim besten willen nicht als "trivial" zu bezeichnen ist
|
|
|
|
|
|
|
|
|
|
|
Ich denk mal, dass du mit einer wesentlich höher aufgelösten Kamera auch wesentlich bessere Recognition machen kannst. Die Sensoren in Mäusen haben so ~16x16 Pixel… zumindest war das State of the Art anno 2009 als ich meine SWX8 gekauft habe.
IR wäre da auch eine Überlegung. Die LED-Beleuchtung könnte man nur sehr kurz einschalten, synchron zum El. Verschluss (ich gehe mal von CCD aus) bzw. rowscan (CMOS). Damit könnte man auch höhere Ströme und Helligkeit fahren; wenn die Blitze kurz genug sind, merkt das Auge vielleicht nichtmal sonderlich viel. Sonst halt rein IR, IR-Laser sind ja kein Problem, IR Beleuchtung eher, aber selbst dafür gibt's Power-LEDs.
Die eigentliche Signalverarbeitung muss halt sehr schnell sein, also FPGA. Oder vll. sogar mehrere in Kombination, wer weiß.
Die reine Bildaufnahme sehe ich also eher unkritisch, Standard-CCD/CMOS Sensoren können recht problemlos 1000 FPS bei entsprechend verringerten Auflösungen liefern; höherwertige auch mit mehr Pixeln.
|
|
|
|
|
|
|
wir reden von geschwindigkeiten bis 250km/h. das sind 69,25m/s.
da wirste mit 1000fps nicht weit kommen (zumindest meiner meinung nach)
|
|
|
|
|
|
|
| Zitat von jonny
wir reden von geschwindigkeiten bis 250km/h. das sind 69,25m/s.
da wirste mit 1000fps nicht weit kommen (zumindest meiner meinung nach)
| |
Das kommt ganz auf den Aufnahmebereich an…
…sagen wir mal wir brauchen 50 % Überlappung und nehmen 30x30cm im Mittel auf, dann benötigen wir 70 m/s / 0.15 m = 467 s^-1…
…das heißt, dass wir bei 1000 FPS und 30x30cm mehr als genug Überlappung haben dürften
|
|
|
|
|
|
|
ich hab vorhin mit 720p bzw. 10,8x6,1cm gerechnet. und ich glaube nicht, dass es mehr als 10% überlappung sein dürfen, wenn man es halbwegig genau haben will
//bei 50% und dazu noch quer dürfte das ein ganz schöner rechenaufwand sein, da noch irgendwas überlappendes zu finden
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von jonny am 20.01.2013 23:22]
|
|
|
|
|
|
90 % fände ich sehr sehr viel. Ne echte feature extraction ála SIFT wäre hier zwar viel zu langsam und würde durch die uniforme Struktur wohl auch nicht viel bringen, aber mit nem gut angepassten Algo sollten 50 % locker langen - mit SIFT und strukturierten Daten kommt der teilweise mit <1 % hin.
Wenn man dazu ein Accelerometer oder ein Kompass oder so nimmt, ist es trivial auszurechnen, was ein ungefährer Erwartungswert ist, also ist der Suchraum selbst auf viele Pixel gesehen recht klein. Das bedeutet aber auch gleichzeitig eine komplexe und gute Implementierung mehrerer nicht trivialer Algos zugleich…
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 20.01.2013 23:24]
|
|
|
|
|
|
bedenke die untergründe, die eben komplett unterschiedlich sein können. gerade bei sand stell ich mir das unglaublich schwer vor
|
|
|
|
|
|
|
Da müsste man mal einen Blick ins Pflichtenheft riskieren.
Auf Asphalt sollte es mit einer bedachtsam gewählten Kameraeinstellung mit COTS-Hardware machbar sein. Die eigentliche Komplexität liegt in der Firmware.
|
|
|
|
|
|
Thema: Der Heim- und Handwerkerthread ( setzkästen, atomare abwehr und die folgen ) |