Hallo, für eine aktuelles Projekt, indem es vorallem um die Automatiesierung von Schiffsmodellen geht, wollen wir eine art virtuelle Map programmieren. In der Map gehts eig. nur darum, Wasser von Land zu unterscheiden. Doch wie kann man sowas verwirklichen? Ich habe mir gedacht, dass man entweder das Land, oder das Wasser markieren muss, damit das Boot errechnen kann, wohin seine aktuelle Route es führt. Meine erste Idee wars, das Land einfach mit Quadraten einzukreisen, da Land nicht Quadratisch ist, könnte man einfach mehrer verschieden große Quadrate nehmen. Das Boot geht dann einfach die Liste der Quadrate durch und guckt ob die jeweilige Position kleiner/größer als die Eckpunte sind. Desweiteren würde ich noch eine "Sicherheitszone" markieren, auch wieder mit Quadraten. Wenn das Boot in einem dieser Quadrate ist, bekommt der "Hobby-Kapitän" eine Warnmeldung, dass das Boot aufgrund von GPS Ungenauigkeiten ans Ufer knallen könnte. Wenn man das relativ genau macht, würde ich bei meinen heimischen Gewässern ca. auf 50 Quadrate kommen, die alle Geprüft werden. Meine andere Idee war, Polygone um die Inseln/Land zu erstellen und dann wie beim http://de.wikipedia.org/wiki/Punkt-in-Polygon-Test_nach_Jordan die Schnittpunkte mit den einzelnen Polygonen überprüfen. Mit Quadraten/Polygonen, könnte man aber auch den Fahrbereich markieren und dann überprüfen, ob das Boot in den Quadraten/Polygonen ist. Die Berechnungen werden mit einem Stm32F4 mit FPU durchgeführt. Habt ihr Tipps, oder noch bessere Lösungen? Hat vielleicht irgendjemand ne Vorstellung, wie lange es dauern würde ca. 50 Quadrate über IF Abfragen mit einer Referenz Position zu vergleichen? MfG Philipp
:
Verschoben durch Moderator
>Die Berechnungen werden mit einem Stm32F4 mit FPU durchgeführt. >Hat vielleicht irgendjemand ne Vorstellung, wie lange es dauern würde >ca. 50 Quadrate über IF Abfragen mit einer Referenz Position zu >vergleichen? Bei der CPU ein paar Microsekunden.
holger schrieb: >>Die Berechnungen werden mit einem Stm32F4 mit FPU durchgeführt. > >>Hat vielleicht irgendjemand ne Vorstellung, wie lange es dauern würde >>ca. 50 Quadrate über IF Abfragen mit einer Referenz Position zu >>vergleichen? > > Bei der CPU ein paar Microsekunden. Doch so lange? Dann muss ich mir mal was überlegen, oder am besten wäre es wohl, beim Upload der Route alles zu prüfen, dann die Route zu koorregieren, und während der Fahrt nichts mehr zu machen. Oder alle 10sek oder so eine Prüfung. Philipp
Philipp Maricek schrieb: > holger schrieb: >>>Die Berechnungen werden mit einem Stm32F4 mit FPU durchgeführt. >> >>>Hat vielleicht irgendjemand ne Vorstellung, wie lange es dauern würde >>>ca. 50 Quadrate über IF Abfragen mit einer Referenz Position zu >>>vergleichen? >> >> Bei der CPU ein paar Microsekunden. > > Doch so lange? Micro, nicht Milli Micro = Millionstel Kannst dir ja mal ausrechnen, wie weit dein Schiff in der Zeit kommt.
Karl Heinz Buchegger schrieb: > Philipp Maricek schrieb: >> holger schrieb: >>>>Die Berechnungen werden mit einem Stm32F4 mit FPU durchgeführt. >>> >>>>Hat vielleicht irgendjemand ne Vorstellung, wie lange es dauern würde >>>>ca. 50 Quadrate über IF Abfragen mit einer Referenz Position zu >>>>vergleichen? >>> >>> Bei der CPU ein paar Microsekunden. >> >> Doch so lange? > > Micro, nicht Milli > > Micro = Millionstel > > Kannst dir ja mal ausrechnen, wie weit dein Schiff in der Zeit kommt. Ach verdammt, ja klar. Ich hatte mich schon gewundert, dass da irgendwas nicht stimmen kann. Wenn ich das ganze mit Polynomen machen sollte, hätte ich zwar weniger "markierte" Flächen, allerdings wäre die Berechnung etwas Zeitraumbender, meiner Einschätzung nach. MfG Philipp
>Wenn ich das ganze mit Polynomen machen sollte, hätte ich zwar weniger >"markierte" Flächen, allerdings wäre die Berechnung etwas >Zeitraumbender, meiner Einschätzung nach. Auch dann langweilt der STM32F4 sich. Selbst wenn dein Boot mit Schallgeschwindigkeit fährt hat der kaum was zu tun;)
Philipp Maricek schrieb: > Wenn ich das ganze mit Polynomen machen sollte, hätte ich zwar weniger > "markierte" Flächen, allerdings wäre die Berechnung etwas > Zeitraumbender, meiner Einschätzung nach. nicht wirklich.
holger schrieb: > Auch dann langweilt der STM32F4 sich. Selbst wenn dein Boot > mit Schallgeschwindigkeit fährt hat der kaum was zu tun;) Also es ist ja nicht so, als würde ich für alles im Boot einen eigenen Controller nehmen. ;) Der Stm32f4 wird noch viel mehr zu rechnen bekommen, z.b. PPM Decoding (ok, das langweilt sogar nen Atmega), aber es wird noch sehr viel Sensorik mit Filter, Fusion usw. hinzubekommen. Wo wir grad schon beim langweilen sind: Ich habe 2 AHRS, jeweils mit Gyro, Acc und Mag. Der Daten werden mit 8kHz (Gyro), und 3,2kHz (Acc) fusioniert. Beide AHRS Boards werden einzeln fusioniert und später nmoch weiter verrechnet. Bekommt das Stm32f4 auch noch hin, mit I2C als Schnittstelle? Hinzukommen werden dann noch PID Regler und eine sehr umfangreiche Kommunikation über Xbee Pro Funkmodule. Obwohl der STM32 da auch wieder vom DMA entlastet wird. Philipp
>Bekommt das Stm32f4 auch noch hin, mit I2C als Schnittstelle?
Der Radio und Fernseher Bus wird das ganze ordentlich ausbremsen.
Besorg dir mal Sensoren die per SPI arbeiten.
I2C macht auf solchen CPUs einfach keinen Spass und keinen Sinn.
Ok, klingt logisch. Aber rein vom rechnerischen müsste der stm32 es locker schaffen, mit spi?
Philipp Maricek schrieb: > Ok, klingt logisch. Aber rein vom rechnerischen müsste der stm32 es > locker schaffen, mit spi? Bis jetzt hab ich da noch nicht wirklich was gesehen, was mir Bauchweh machen würde.
Ich bin am überlegen, das die Sensorauswertung auf einen eigenen STM32F4 auszulagern. 2 x AHRS Fusion und der ganze Rest sollte zwar auf einen Chip passen, aber ich möchte Spielraum nach oben lassen, da wir noch Experiemente wie GPS Korrigieren durch das IMU und noch andere Spielerein mit Sensoren vorhaben. Außerdem soll noch ein Audio System für Motoren usw. mit integriert werden, vielleicht könnte man die Sensorik und das I2S Interface auf dem einen Chip nutzen und der andere Chip macht den ganzen rest, was auch nicht umbedingt wenig ist. MfG Philipp
Philipp Maricek schrieb: > Ich bin am überlegen, das die Sensorauswertung auf einen eigenen STM32F4 > auszulagern. Was genau verstehst du unter "Sensorauswertung". Die Sache ist die: die Dinge werden meistens nicht einfacher, wenn man 2 µC an eine Aufgabe setzt, die einer alleine schafft. Ganz im Gegenteil, ganz im Gegenteil. Mit scheint, dir ist nicht wirklich klar, was für einen Boliden du da am Start hast und was der an Rechenpower mitbringt. Rechenzentren der 80-er Jahre, die komplette Firmen gemanaged haben, hatten weniger Power als dein DSP, den du da hast.
Was verbirgt sich hinter AHRS? AbKüFi? Hauptsache coole Abkürzungen und ganz viele Mikrocontroller drin ;-) Das, was du aufzählst ist alles nur "einfache" Mathematik (4 Grundrechenarten). Wenn du nicht gerade PC-Programmierung mit Double und Float gewöhnt bist, dann schaffen das auch kleine Prozessoren entsprechend schnell. Mehrere Mikrocontroller in einem Design lohnt sich nur mit speziellen Anforderungen, da wesentlich mehr Entwicklungsoverhead. Ein gescheites Schnittstellenprotokoll zu erfinden, was performant und robust genug ist, ist nicht gerade einfach. Ein "kleiner" 32 Bit ARM Core reicht da vermutlich schon gut aus.
Simon K. schrieb: > Das, was du aufzählst ist alles nur "einfache" Mathematik (4 > Grundrechenarten). Wenn du nicht gerade PC-Programmierung mit Double und > Float gewöhnt bist, dann schaffen das auch kleine Prozessoren > entsprechend schnell. War auch mein erster Gedanke. Aber noch nicht mal dieses Argument zieht. Das Ding hat eine FPU on bord.
Hi, AHRS = "Attitude and Heading Reference System" (Lage und Richtungs Referenz System) Da müssen die Gyro, Acc und Mag Werte mit einem Filter bearbeitet werden und dann Fusioniert werden um eine genaue Lage im Raum zu erhalten. Dazu müssen z.b. Gyro Daten aufintegriert werden, was schätzungsweise mit 8kHz passieren wird. Der Acc wird wahrscheinlich mit etwa 3,2kHz mit eingerechnet. Das ganze passiert 2 mal, da wir 2 Sensoreinheiten haben. Dann brauchen wir für unser Schiff, die genauen Bechleunigungs/Bewegungsdaten im 2D Raum, also nur die wahren Werte überm Wasser. Dazu drehen wir den Acc Vektor mit einer Rotationsmatrix, damit die Achsen wieder parallel zum Wasser liegen und dann errechnen wir die Beschleuningung auf der X/Y Achse, um z.b. Wellen zu kompensieren. Diese Werte müssen ebenfalls wieder aufintegriert werden, damit wir über einen Zeitraum hinweg, die relativ genaue Abweichung der vorherigen Position errechnen können, um gegen zusteuern. Da wir da sehr genaue Daten benötigen werden alle diese Berechnungen wohl mit double ausgeführt. (beim ARM 64bit und 15 Nachkommastellen?). Desweiteren soll für die Zukunft durch die Lage und Beschleunigungsdaten eine GPS Korrektur mit eingebaut werden. Für den Autopiloten müssen noch mit ca. 2-5Hz Entfernung und Heading zum Ziel errechnet werden. Da wir uns in relativ kleinen Entfernungen bewegen wird das mindestens mit Float passieren müssen. Als nächstes kommen alle 2-5 Sekunden Berechnungen um zu Prüfen, ob und in welchem Polygone sich das Boot gerade befindet. Es sind auch noch mehrere PID Regler notwendig, die auf Grund der Daten der Beschleunigungsdaten Korrekturen an den Steuerorganen wie Rudern, Motoren usw. vornehmen. Für die Steuerung ist noch eine PPM Auswertung und eine PWM Generation notwendig. Sollte ich mit einem Schieberegister das PWM Signal ausgeben? Als letztes kommt noch ein großes Protokoll mit Abo-System("an-abbestellung" von Daten, wie Sensordaten) und Empfangsbestätigung. Außerdem wird mit ca. 4Hz eine "Heartbeate Meassge" übertragen, die alle wichtigen Status Infos zu Boot, Autopilot usw. enthält. Naja, dann kommt noch das I2S Audiointerface dazu, dass die Daten zwar mittles DMA beziehen wird, die Audio Daten müssen allerdings noch nach den Steuerdaten verändert werden, um z.b. Motorengeräusch und Horn parallel laufen zu lassen und ein verändern der Motorengeschwindigkeit Auditiv darstellen zu lassen. Kann der STM32F4 das alles erledigen, ohne Verzögerungen? Wenn ich 2 Stm32f4 nutzen sollte, würde das Schnitstelleprotokol nicht allzu groß ausfallen, da nur die Sensordaten in eine Richtung und Steuerdaten für I2S in die andere Richtung übertragen werden würden. MfG Philipp
Tut mir leid das sagen zu müssen, aber das ist immer noch nix, was mir groß Bauchschmerzen bereiten müsste. Wenn ein (im Vergleich zu deinem Boliden) popeliger AVR es schafft einen Quadrokopter in der Luft zu halten, und der MUSS ständig gesteuert werden, dann schafft das dein Bolide schon lange ein Schiff auf Kurs zu halten. Dein µC macht (laut Hersteller) 210 MILLIONEN Rechnungen pro Sekunde. Was glaubst du wieviele du für einen Durchgang durch den PID Regler brauchst? So ungefähr 20 bis 30. Und da war ich schon großzügig. Deine Updatefrequenzen von unter 10Hz sind lachhaft. Da rechnet der µC als Zugabe noch ein paar 'teuflisch schwierige quadratische Gleichungen' (tm Douglas Adams) nur damit ihm nicht fad wird. Du unterschätzt die Power die du da hast. Und zwar ganz gewaltig.
>Da wir da sehr genaue Daten benötigen werden alle diese Berechnungen >wohl mit double ausgeführt. (beim ARM 64bit und 15 Nachkommastellen?). Die FPU macht nur Single Precision. Sprich float (32Bit), aber kein double. Double müsste die CPU dann wieder in Software machen. Aber auch da bekomme ich noch keine Bauchschmerzen;)
holger schrieb: >>Da wir da sehr genaue Daten benötigen werden alle diese Berechnungen >>wohl mit double ausgeführt. (beim ARM 64bit und 15 Nachkommastellen?). > > Die FPU macht nur Single Precision. Sprich float (32Bit), aber kein > double. OK. Ich geb zu, ich hab nicht weiter nachgeforscht. Als ich FPU gelesen habe, war die Sache gegessen. Und die Demo, die ich gefunden habe, war beeindruckend.
Karl Heinz Buchegger schrieb: > Tut mir leid das sagen zu müssen, aber das ist immer noch nix, was mir > groß Bauchschmerzen bereiten müsste. > > Wenn ein (im Vergleich zu deinem Boliden) popeliger AVR es schafft einen > Quadrokopter in der Luft zu halten, und der MUSS ständig gesteuert > werden, dann schafft das dein Bolide schon lange ein Schiff auf Kurs zu > halten. > > Dein µC macht (laut Hersteller) 210 MILLIONEN Rechnungen pro Sekunde. > Was glaubst du wieviele du für einen Durchgang durch den PID Regler > brauchst? So ungefähr 20 bis 30. > > Deine Updatefrequenzen von unter 10Hz sind lachhaft. Da rechnet der µC > als Zugabe noch ein paar 'teuflisch schwierige quadratische Gleichungen' > (tm Douglas Adams) nur damit ihm nicht fad wird. Hi, ok danke soweit, ich konnte mir das ganze halt nicht so richtig vorstellen. Wenn ich die Sensoren mit max. 8kHz update, hat man reintheoretisch pro Herz 26250 Rechenoperationen zur Verfügung stehen, das sollte locker reichen. "Sparsame Programmierung" bin ich ja sowieso von meinem letzten Großen Projekt mit einem Atmega644p gewöhnt.
>> Die FPU macht nur Single Precision. Sprich float (32Bit), aber kein >> double. >OK. Ich geb zu, ich hab nicht weiter nachgeforscht. Als ich FPU gelesen >habe, war die Sache gegessen. Und die Demo, die ich gefunden habe, war >beeindruckend. Eine 2048 Punkte FFT macht das Ding in 3ms mit FPU, ohne FPU in 17ms. Selbst ausprobiert;)
Ich hab grad mal in die AN4044 reingeschaut. http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/DM00047230.pdf Laut der macht die FPU auch double, aber dauert halt länger, weils irgentwie aufgeteilt wird. Wenn ich nichts falsch verstanden habe.
Hi, sorry dass ich nochmal aufwärme, aber ich hätte nochmal ne Frage. Ich bin jetzt überlegen ob man für das Projekt vielleicht Freertos nehmen könnten. Würde uns das Vorteile in Sachen Performance bringen?, oder was hätte das sonst noch für Vorteile? MfG Philipp
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.