Hi, ich bin gerade beim Überlegen, wie man am Besten die Arbeit mit Vektoren im 2d Koordinatensystem mit einem µc realisieren könnte. Ich kom aber nicht so wirklich weiter. Man könnte ja zum Beispiel die Koordinaten eines Punkts so angeben: -1. 8 bit x -2. 8 bit y so, aber jetzt weis zwar der µc die Koordinaten von einem Punkt, aber wie kann ich ihm dann sagen, das das ganze ein Vektor sein soll? Das ganze soll dann sozusagen auf eine vektorielle Karte hinauslaufen. Hat jemand noch Ideen wie man das realiseieren könnte oder gibt es da iwo schon ähnliche Beispieleß mfg Achso, was die Sache sicherlich nicht leichter macht ist das ich es in Assembler machen wöllte.
Ob ein beliebiges Zahlenpaar Gewicht und Grösse, Guthaben und Länge, zwei Ordinaten oder zwei Komponenten eines Vektors sind hängt von deren Interpretation ab. Wenn Du damit rechnest, als wenn es Vektoren sind, dann sind es auch welche.
Abgesehen davon macht etwa die Addition zweier Ordinaten keinen Sinn, weil es hiesse zwei Punkte zu irgendwie zu "addieren" obwohl diese Operation mathematisch garnicht definiert ist. während dies bei Vektoren insofern Sinn macht weil eben so die Vektoraddition definiert ist.
Eben, Ahem. Es kommt ganz darauf an wie man die beiden Werte behandelt. Das liegt ganz am Programmierer
Ahem, Vektoren zu addieren ist sehr wohl in der Mathematik definiert. Kräfte ist hierfür ein gutes Beispiel, da macht man das dauernd.
Michael, ich glaube es ist besser wenn wir beide Dich ignorieren.
Du willst doch jetzt nicht behaupten, dass man Vektoren nicht addieren darf?
Ein Zahlenpaar ist aber noch kein Vektor. Dazu gehört dann schon noch ein zweites Zahlenpaar: Anfangs- und Endpunkt oder Punkt und Länge und Richtung. Nice week, Zardoz
>Du willst doch jetzt nicht behaupten, dass man Vektoren nicht addieren >darf? Nein, und wenn Du nochmal mein Post von 21:01 anguckst, dann wirst Du sehen, das ich sogar das Gegenteil behauptet habe. >während dies bei Vektoren insofern Sinn macht weil eben so die >Vektoraddition definiert ist.
@Michael: Hast du den Text von "Ahem" richtig gelesen? Er schreibt doch: Vektoren JA, Ordinaten NEIN... Chris *EDIT*: Mit dem Text von gerade ist mein Post sinnlos geworden... ;)
Man kann auch Koordinaten addieren, das sind dann Vektoren, die auf den Ursprung des Koordiantensystems bezogen sind. Ob das sinnvoll ist hängt natürlich davon ab was die Koordinaten darstellen.
>Ein Zahlenpaar ist aber noch kein Vektor. Nein, ein Zahlenpaar ist ein Zahlenpaar ist ein Zahlenpaar. Es kann als Vektor interpretiert werden. >Dazu gehört dann schon noch ein zweites Zahlenpaar: Anfangs- und Endpunkt >oder Punkt und Länge und Richtung. Nein!
>Man kann auch Koordinaten addieren Nein. Diese Operation ist nicht definiert und gibt auch keinen Sinn. >das sind dann Vektoren Koordinaten sind keine Vektoren sonst hiessen sie ja Koordinaten. >Koordinaten ... sind dann Vektoren, die auf den Ursprung des Koordiantensystems bezogen sind Eben nicht. Das sind diejenigen Faktoren mit den die Einheitsvektoren multpliziert werden müssen... also ehrlich Leute, das ist doch elementare Mathematik. Lest doch selbst nochmal nach.
>>das sind dann Vektoren >Koordinaten sind keine Vektoren sonst hiessen sie ja Koordinaten. muss natürlich heissen >>das sind dann Vektoren >Koordinaten sind keine Vektoren sonst hiessen sie ja Vektoren. Ihr macht mich ganz hungrig. Ich gehe jetzt mal spazieren.
Ahem hat absolut recht ... ein Zahlenpaar reicht. Nice week, Zardoz
Also ich habe gedacht, wenn man jetzt auf ein Hindernis stößt, dann kann man ja den Punkt ins Koordintensystem eintragen. Wenn man dan auf den nächsten stößt, kann man den auch eintragen, und den Verbindungsvektor bilden. Man kann dann berechnen ob ein Punkt auf einem Vektor liegt mit (xQ-xP;yQ-yP) oder anders gesagt mit Vektor PQ+t*(P2;Q2), wobei dann t kleiner als 1 sein muss, damit die punkte dann zwischen P und Q liegen. Nur ist dann das Problem, das ich feststellen muss, wie die Punkte dann richtig verbunden werden.
>>Koordinaten ... sind dann Vektoren, die auf den Ursprung des Koordiantensystems >>bezogen sind >Eben nicht. Das sind diejenigen Faktoren mit den die Einheitsvektoren >multpliziert werden müssen... also ehrlich Leute, das ist doch >elementare Mathematik. Lest doch selbst nochmal nach. Du willst also sage, dass ein Vektor, der vom Ursprung auf eine Koordinate zeigt, kein Vektor ist? Ja, das ist elementare Mathematik.
Liebster Michael >Du willst also sage, dass ein Vektor, der vom Ursprung auf eine >Koordinate zeigt, kein Vektor ist? Nein, das will ich nicht. Ich habe nur sagen wollen, das eine Koordinate nicht das selbe ist wie ein Vektor. Im übrigen ist ein Vektor dessen Ursprung an einen bestimmten Punkt gebunden ist ein sogenannter "gebundener" Vektor. Diesen Unterschied gibt es weil es den Unterschied zu so. "freien Vektoren" gibt. Und von diesen freien Vektoren redet man allgemein als "Vektoren". Von den freien Vektoren gibt es beliebig viele mit dem selben "Zahlenpaar". Das aber impliziert, das "ein" Vektor nicht mit "einer" Koordinate identisch ist, aber auch nicht das sie im weitesten Sinne Analoga sind. Das wird schon daraus ersichtlich das Vektoren, also "freie" Vektoren eine ganze Menge von Richtungs-Länge-Dingen sind und eine Koordinate eben nur ein Ding. Ich glaube wir ignorieren Dich doch lieber.
Aber dieser ganze Streit im Begriffe hilft ja dem armen Martin nicht weiter. >Also ich habe gedacht, wenn man jetzt auf ein Hindernis stößt, dann kann >man ja den Punkt ins Koordinatensystem eintragen. Das kannst Du genau dann, wenn Du alle Ortsveränderungen gemerkt hast. > Wenn man dan auf den nächsten stößt, kann man den auch eintragen, und den >Verbindungsvektor bilden. Ich nehme an, Du meinst das nächste Hindernis? Ja, dann kann man einen Vektor von einem Punkt zu einem anderen berechnen. >Man kann dann berechnen ob ein Punkt auf einem Vektor liegt mit >(xQ-xP;yQ-yP) oder anders gesagt mit Vektor PQ+t*(P2;Q2), wobei dann t >kleiner als 1 sein muss, damit die punkte dann zwischen P und Q liegen. Ich verstehe es nicht ganz, aber es sieht eben richtig nach einer Linearkombination aus. >Nur ist dann das Problem, das ich feststellen muss, wie die Punkte dann >richtig verbunden werden. Was meinst Du mit "zwei Punkte richtig verbinden"? Was heisst es, zwei Punkte zu "verbinden"? Was heisst es sie "richtig" zu verbinden?
Das Problem mit den Punkte verbinden könnte man ja lösen, indem man an
die Seite des Roboters einen Sensor baut, mit dem man registriert, wie
lange sich das Hindernis noch an der Seite befindet und wenn es nicht
mehr da ist, kann man dann den Punkt festlegen.
Dann wäre nun hier das Problem zu lösen, da es ja sinnvoll wäre nur die
Punkt abzuspeichern, welche Punkte wie miteinander verbunden werden
müssen. Wie könnte man soetwas programmiertechnisch am besten lösen?
Weil es kann dann ja auch im Priznip sein, das ein Punkt mit 2 oder
mehren anderen Punkten verbunden werden muss.
Also es ist ja so:
Der Roboter fährt einfach gerade aus.
Dann stößt er auf ein Hindernis, lenkt ab und stößt dann auf ein anderes
Hindernis, welches mit diesem eigentlich nichts zu tun hat:
-----------------
- -
- -
- -
- -
- -
- - -------------------------
-----------------Q - -
- -
- -
P ---------------------------
jetzt längt der Robo von P ab auf Q und schon ist das Hindernis falsch
eingezeichnet, wenn er einfach die beiden Punkt miteinander zu einem
Vektor bildet.
Also Martin, ich denke Du solltest Dir erstmal die Grundlagen aneignen. Dann kann man richtig darüber sprechen. Es scheint, das Du mit einem autonomen Fahrzeug die "Landkarte" einer Umgebung erzeugen willst. Was aber genau Dein Problem ist ist mir immer noch nicht klar. Du willst immer irgendwas "verbinden" ohne zu sagen, was denn diese Operation bewirken soll.
Vergesst den Ahem. Etwas eng dessen Sichtweise. Allenfalls Mathematiker... Ein Vektor und eine Koordinate sind natuerlich dasselbe. Eine Koordinate plus ein Vektor gibt wieder eine Koordinate.
Es sind doch völlig getrennte Probleme. 1. Die Existenz eines Hindernisses zu erkennen 2. Es aus den Daten des Weges und des Fahrzeugs heraus zu beschreiben (das Hinderniss) 3. Und aus den Daten aus 2. eine "Landkarte" zu erzeugen. Verstehst Du das und stimmst Du mir zu?
Also zu: 1. Hindernis wird erkannt und Koordinaten liegen bereit 2. Verstehe ich irgendwie nicht so richtig 3. Genau das ist das eigentliche Problem
@ 1234 >Etwas eng dessen Sichtweise Wofür ist sie zu eng? >Ein Vektor und eine Koordinate sind natuerlich dasselbe. Gib bitte einen Beleg für diese Behauptung an. Ich streite ja garnicht ab, das die Zahlenwerte einer Koordinate und die Zahlenwerte eines Ortsvektors auf die selbe Koordinate gleich sind. Ich räume auch ein, das man unter den genannten (und noch einigen ungenannten) Bedingungen Koordinaten operativ wie Vektoren behandeln kann. Aber das ist eben nicht das selbe wie die Aussage, das diese beiden Dinge identisch oder das selbe sind. Die oft vertretene Meinung das Mathematiker keine praktischen Probleme lösen können, weil sie alles so hypergenau ausdrücken, wird in diesem Forum (und diesem Thread) dadurch konterkariert, das die Praktiker praktische Probleme nicht lösen können weil sie die Begriffe und Zusammenhänge nicht kennen. Etwaige Bemühungen durch eine exakte Darstellung der Zusammenhänge stehen ja einer praktischen Anwendung überhaupt nicht im Wege! Oder wie sollte das zugehen? Man muss meiner Ansicht nach nur eben sagen, das man eine gewisse Analogie herstellt, einen gewissen Unterscheid ignoriert uswusf. Also wofür ist diese Sichtweise zu eng?
@ Martin >1. Hindernis wird erkannt und Koordinaten liegen bereit OK. Das ist doch schon mal was. >2. Verstehe ich irgendwie nicht so richtig Naja, das hängt mit der Art und Weise zusammen wie Du die Position und den Weg des Fahrzeugs feststellst und mitschreibst und in welcher örtlichen Lage relativ zu irgendeinem Koordinatenursprung Dein Sensor sich befindet und ob er eine irgendwie konstruktiv vorgegebene Richtung oder Richtungen hat, in denen er das Hinderniss anzeigt. Z.B. Stell Dir vor Du hast einen Sensor der in genau einer Richtung auf Druck reagiert. Welchen Unterschied machtes wohl die Form des "Bumpers", also desjenigen Bauteils das die Kraft auf den Sensor leitet. +-----------+ | | | | | Sensor +--| also eine gerade Platte oder Stange | | | +-----------+ | oder so +-----------+ | | | | | Sensor +---| also ein Bogen oder irgendwie gekrümmter Rahmen | | | +-----------+ | Und dann: Wie ermittelst Du die Koordinaten? Wegmessung? Ortsbestimmung? >3. Genau das ist das eigentliche Problem Das hängt auch davon ab, was Du mit den Daten eigentlich anfangen willst.
Dann mal als Praktiker gefragt: Wäre es nicht einfacher, der Roboter merkt sich zunächst einfach nur die Koordinaten (Punkte), an denen er auf ein Hindernis gestoßen ist? Mit zunehmender Anzahl gespeicherter Punkte müsste er jeweils entscheiden, ob der Abstand zweier Punkte groß genug ist, um einen Versuch zu machen, es zwischen ihnen erneut zu versuchen. Nice week, Zardoz
Wenn Du aber so kompliziert (also Punkt 2) da nicht heran gehen willst und eben dabei bleibst, das die Koordinaten eben einfach da sind, dann bleibt ja nur noch Punkt 3. OK. Was hindert Dich daran diese Koordinaten einfach in einer Tabelle zu speichern? Es gibt sicherlich andere Wege die Koordinaten zu organisieren, aber das hängt eben davon ab was Du damit machen willst. Lies Dir doch mal die entsprechenden Kapitel "Algorithmen in C" von Sedgewick durch. Da solltest Du ein paar Anregungen finden.
>Wäre es nicht einfacher, der Roboter merkt sich zunächst einfach nur die >Koordinaten (Punkte), an denen er auf ein Hindernis gestoßen ist? Mit >zunehmender Anzahl gespeicherter Punkte müsste er jeweils entscheiden, >ob der Abstand zweier Punkte groß genug ist, um einen Versuch zu machen, >es zwischen ihnen erneut zu versuchen. Meinte er das mit "verbinden"? Hmmm. Naja, zwei Hindernispunkte, die näher zueinander liegen als die Breite des Fahrzeugs in irgendeiner seiner möglichen Bewegungsrichtungen können wohl als "Verbunden" gelten. Das Fahrzeug kann ja nicht zwischen Ihnen hindurch. Aber der umgekehrte Schluss ist nicht so einfach möglich. Wenn zwei Punkte (in einem weiten Abstand) Hindernisse sind, so spielt jedenfalls auch die Bewegungsrichtung eine Rolle. Ich würde das eher als Vektorfeld (Tensor) speichern. Siehe z.B.: +------+ F>| | F>----- +------+ - und + sind Hindernisse F ist das Fahrzeug und > seine Bewegungsrichtung.
>Ich glaube wir ignorieren Dich doch lieber.
Nur weil wir aneinander vorbei reden willst du mich ignorieren? OK,
davon kann ich niemanden abhalten.
Ich denke schon, daß er das mit "verbunden" meint. Die Bewegungsrichtung des Fahrzeugs spielt sicher eine Rolle. Allerdings kann man mit einfachen Mitteln keine "Richtung" eines Hindernisses erkennen. Insofern dürfte es doch auf eine Punkteliste hinauslaufen. Nice week, Zardoz
@ Zardos
>kann man mit einfachen Mitteln keine "Richtung" eines Hindernisses
Ich denke schon. Man kennt ja seine Bewegungsrichtung bzw. die
Bewegungsrichtung des Sensors und seine Geometrie.
Ich finde die ganze Idee eher etwas fraglich, wenn ich sie recht
verstehe. Echte Hindernisse sind nur die Punkte an denen man tatsächlich
auf Hindernisse stiess. Keine dazwischenliegenden aber nicht tatsächlich
berührten Punkte (ausser vielleicht mit der Ausnahem der von uns oben
genannten).
Ich stelle mir das Fahrzeug eher wie eine Lichtquelle vor deren Licht
auf verschiedene Flächen fällt. Was das Fahrzeug erkennen kann sind
Projektionen des Bewegungsvektors auf Flächen deren Ausdehnung, Lage und
Orientierung nicht bekannt sind. Ja, nichteinmal, ob es sich um eine
Fläche handelt kann man ermitteln. Durch die Berührung erhält man nur
Informationen über einen Punkt entlang des Bewegungsvektors (evtl.
modifziert durch die Bumpergeometrie). Nicht mehr.
Alles andere beruht auf Annahmen und ist damit unzuverlässig.
vector.h
1 | typedef struct Vector |
2 | {
|
3 | uint8_t x; |
4 | uint8_t y; |
5 | } Vector; |
6 | |
7 | void initVector(Vector* v, uint8_t X, uint8_t Y); |
8 | Vector addVector(Vector* a, Vector* b); |
9 | // weitere Funktionen
|
vector.c
1 | void initVector(Vector* v, uint8_t X, uint8_t Y) |
2 | {
|
3 | v->x = X; |
4 | v->y = Y; |
5 | }
|
6 | |
7 | Vector addVector(Vector* a, Vector* b) |
8 | {
|
9 | Vector v; |
10 | v.x = a->x + b->x; |
11 | v.y = a->y + b->y; |
12 | return v; |
13 | }
|
14 | // weitere Funktionen
|
@Ahem Du hast wieder einmal Recht - man sollte schon auch die Richtung speichern, in der man auf ein Hindernis getroffen ist. Aber als fragwürdig würde ich das Ganze nicht bezeichnen. Das Bild der Umgebung entspricht eben den Möglichkeiten des "Sinnes", mit dem sie erfasst wird. Könnte der Mensch Einzelheiten auf atomarer Ebene unterscheiden, würde er auch eine ganz andere Welt sehen. >> Ja, nichteinmal, ob es sich um eine Fläche handelt kann man >> ermitteln. Durch die Berührung erhält man nur Informationen >> über einen Punkt entlang des Bewegungsvektors (evtl. >> modifziert durch die Bumpergeometrie). Nicht mehr. Eben. Also macht es auch keinen Sinn, etwas anderes als eben diese Punkte (sowie den Bewegungsvektor) zu speichern. Interessanter würde es mit Entfernungs- und/oder Bewegungssensoren. Die "Welt" würde jedenfalls anders aussehen ... Nice week, Zardoz
@ Zardoz >Aber als fragwürdig würde ich das Ganze nicht bezeichnen. Das Bild der >Umgebung entspricht eben den Möglichkeiten des "Sinnes", mit dem sie >erfasst wird. Könnte der Mensch Einzelheiten auf atomarer Ebene >unterscheiden, würde er auch eine ganz andere Welt sehen. Ich habe ja nicht die Idee der Wahrnehmung an sich in Frage gestellt. Meine Zweifel beziehen sich auch nicht darauf, das das Verfahren nicht hoch genug auflösend wäre. Das käme auf den Einsatzzweck an. Ich habe es vielleicht nicht ausführlich genug beschrieben, aber woran ich Zweifel habe ist, das Verfahren, zwei Punkte, an denen man auf Hindernisse getroffen ist zu "verbinden" in dem Sinne, das man annimmt, das sich dazwischen auch "Hinderniss" befindet. >>> Ja, nichteinmal, ob es sich um eine Fläche handelt kann man >>> ermitteln. Durch die Berührung erhält man nur Informationen >>> über einen Punkt entlang des Bewegungsvektors (evtl. >>> modifziert durch die Bumpergeometrie). Nicht mehr. >Eben. Also macht es auch keinen Sinn, etwas anderes als eben diese >Punkte (sowie den Bewegungsvektor) zu speichern. Was soll diese "Eben" heissen? Es macht eher mehr Sinn die Geometrie des Fahrzeugs und Bumpers zu berücksichtigen, als nur einen Punkt als Hinderniss zu speichern. Das ist nämlich genau die Aussage, die man erhält wenn es "nicht weitergeht". Das das Fahrzeug irgendwo an seiner Aussenkante entlang seiner Bewegungsrichtung anstösst. Das wird also in der Regel eine Fläche sein, nämlich die welche das Fahrzeug in Richtung seiner Bewegung hat. Man weiss ja nicht genau wo an seiner Aussenfläche das Fahrzeug angestossen ist. Nur ist das eine ganz andere Aussage als zu sagen, da "sei" eine Fläche als Hinderniss, was aus dem "verbinden" der Hindernisspunkte folgt. Seien '*' das Hinderniss, '>' die Bewegungsrichtung, 'F' das Fahrzeug sowie '.' die Begrenzung der Welt, so ergibt etwa folgende Situation: .................... . | . . F>|* . . | . . . .................... welches "Weltbild"? .................... . * . . * . . * . . . .................... oder .................... . . . * . . . . . .................... (hier ist nur das originale Hindernis eingezeichnet). ? Ich meine das Weltbild sollte ehr so aussehen: Wobei '?' heisst, dort ist irgendwo ein Hinderniss, aber seine genaue Position ist in dem Bereich der möglichen Anstosslinie unbestimmt. .................... . ? . . ? . . ? . . . .................... Wenn ich nun von verschiedenen Seiten und mit seitlichem Versatz an den ursprünglichen Punkt heranfahre, engt sich das vermutete Hindernis immer mehr ein. Die letzte Frage zielt auf den Einfluss der Fahrzeuggeometrie auf das angenommene Weltbild. Dann aber noch die Ausgangsfrage: Kann ich zwei Punkte, an denen ich angestossen bin, als materiell verbunden annehmen? 1. Anstoss .................... . | . . F>|* . . | . . . . . . * . .................... 2. Anstoss .................... . . . * . . . . | . . F>| . . |* . .................... Sieht die Welt nun so aus?: .................... . * . . * . . * . . * . . * . . * . .................... Beim lesen des Threads, sehe ich aber auch das der Eröffner davon sprach einen "seitlichen" Sensor zu benutzen. (30.03.2009 21:43) Das könnte eine Verbesserung bringen. Mal überlegen. Sind die Hindernisse elastisch? Wie sorge ich dafür das die Auslösekraft seitlich immer hoch genug ist?
Sollte man beim Vektor nicht den Startpunkt festlegen und dessen Länge. Etwas fehlt mir. Ich würde es so machen, um den obigen Code nochmals aufzugreifen. vector.h
1 | typedef struct Vector |
2 | {
|
3 | uint8_t x; |
4 | uint8_t y; |
5 | uint8_t x_length; |
6 | uint8_t y_length; |
7 | } Vector; |
8 | |
9 | void initVector(Vector* v, uint8_t X, uint8_t Y, uint8_t X_length, uint8_t Y_length); |
10 | Vector addVector(Vector* a, Vector* b); |
11 | // weitere Funktionen
|
vector.c
1 | void initVector(Vector* v, uint8_t X, uint8_t Y, uint8_t X_length, uint8_t Y_length) |
2 | {
|
3 | v->x = X; |
4 | v->y = Y; |
5 | v->x_length = X_length; |
6 | v->y_length = Y_length; |
7 | }
|
8 | |
9 | Vector addVector(Vector* a, Vector* b) |
10 | {
|
11 | Vector v; |
12 | v.x = a->x; |
13 | v.y = a->y; |
14 | v.x_length = a->x_length + b->x_length; |
15 | v.y_length = a->y_length + b->y_length; |
16 | return v; |
17 | }
|
18 | // weitere Funktionen
|
@Ahem > Ich habe es vielleicht nicht ausführlich genug beschrieben, > aber woran ich Zweifel habe ist, das Verfahren, zwei Punkte, > an denen man auf Hindernisse getroffen ist zu "verbinden" > in dem Sinne, das man annimmt, das sich dazwischen auch > "Hinderniss" befindet. Da stimme ich absolut zu - haben wir also ein wenig aneinander vorbei diskutiert. Nach dem von Dir beschriebenen Anstossen an ein Hindernis würde ich folgendes "Weltbild" bevorzugen: 1. Anstoss .................... . | . . F>|* . . | . . . . . . * . .................... 2. Anstoss .................... . . . * . . . . | . . F>| . . |* . .................... Ergebnis .................... . . . * . . . . . . . . * . .................... Ist der Abstand der zwei Punkte kleiner als die Breite des Fahrzeugs könnte man einen Weg dazwischen versuchen. Endet auch der an einem Hindernis, hinge das weitere Vorgehen von den sich daraus ergebenden neuen Abständen ab. Verfeinerte Sensoriken des Fahrzeugs würden natürlich zu einem verfeinerten Vorgehen führen. Was die Frage nach dem Sinn des Ganzen betrifft: Möglicherweise geht es einfach nur um Erkenntnisgewinn? Nice week, Zardoz
Benjamin S. wrote:
> Sollte man beim Vektor nicht den Startpunkt festlegen und dessen Länge.
Nein.
Schon alleine deswegen, weil ein Vektor keinen Startpunkt hat.
Ein Vektor hat eine Länge und eine Richtung.
Beides kannst du durch ein einziges Zahlenpaar wunderbar ausdrücken.
Was hier gespeichert wird, sind keine Vektoren, sondern Punkte.
Auch wenn die Unterscheidung zwischen den beiden im voreliegenden Fall
unerheblich scheint, so sind die Dinge doch zu trennen:
Ein Punkt ist eine Koordinate im Raum
Um von einem Punkt zu einem anderen Punkt zu kommen, wird zu dem Punkt
ein Vektor hinzuaddiert. Die Differenz zwischen zwei Punkten ist ein
Vektor.
Wenn man so will, ist die Unterscheidung Vektor-Punkt, gleichbedeutend
mit der Unterscheidung Ort und Distanz. Ein Ort ist keine Distanz und
eine Distanz ist kein Ort. Aber um vernünftig rechnen zu können, braucht
man beides. Und da Vektoren und Punkte gleich gespeichert werden können
(ein Zahlenpaar reicht im 2D) kommt immer wieder diese Konfusion
zustande.
Danke, ich hab mein Problem erkannt. Ich kann ja den Vektor hinschieben wo ich will. Aber am Bildschirm beginnt er immer an einem definiertem Ort. Da lag mein Problem. Ich errinnere mich. Danke für die Hilfe :)
Benjamin S. wrote: > Danke, > ich hab mein Problem erkannt. Ich kann ja den Vektor hinschieben wo ich > will. Aber am Bildschirm beginnt er immer an einem definiertem Ort. Da > lag mein Problem. Ich errinnere mich. > Danke für die Hilfe :) Was du am Bidschirm hast, ist kein Vektor sondern eine Linie. Eine Linie hat Startpunkt und Endpunkt. Die kann man zb speichern, indem man beide Punkte speichert, oder aber in dem man Startpunkt und Vektor speichert. Beides ist möglich (und trivialerweise ineinander überführbar)
@ Zardoz Ich stimme Deiner Ansicht nicht zu, das das von Dir beschrieben Weltbild ein sinnvolles wäre. Es beruht nicht auf Information, sondern darauf was Du Dir "wünschst", wenn ich Deiner Wortwahl mal folge. Vielleicht hast Du aber auch nur übersehen, das ich die '|' als Teil des Bumpers beschrieben habe. Damit kann der Anstosspunkt, das Hindernis, potentiell überall entlang einer Linie liegen, die orthogonal zu Bewegungsrichtung die Kante des Bumpers bildet. Ich habe auch den Sinn des Verfahrens (die Punkte zu verbinden) gemeint; nicht der gesamten Fragestellung im Kontext des Lebens einer Person oder der Anstrengungen einer Gruppe wie dieses Forum.
@Ahem > Ich stimme Deiner Ansicht nicht zu, das das von Dir beschrieben > Weltbild ein sinnvolles wäre. Es beruht nicht auf Information, > sondern darauf was Du Dir "wünschst", wenn ich Deiner Wortwahl > mal folge. Ich vermute mal, das bezieht sich darauf: > Vielleicht hast Du aber auch nur übersehen, das ich die '|' als > Teil des Bumpers beschrieben habe. Damit kann der Anstosspunkt, > das Hindernis, potentiell überall entlang einer Linie liegen, die > orthogonal zu Bewegungsrichtung die Kante des Bumpers bildet. Das stimmt natürlich. Man könnte sagen, die "Auflösung" dieses (primitiven) "Tastsinns" entspricht der Breite des Bumpers. > Ich habe auch den Sinn des Verfahrens (die Punkte zu verbinden) > gemeint; nicht der gesamten Fragestellung im Kontext des Lebens > einer Person oder der Anstrengungen einer Gruppe wie dieses Forum. Eben das meinte ich auch: Erkenntnisgewinn des Fahrzeugs über seine Umgebung. Nice week, Zardoz
Hi, also erstmal vielen Dank für die vielen Antworten. So wie ich es sehe, ist es wohl doch sinnvoller nur die einfachen Punkte zu speichern. Übrigens wollte ich die Hindernisse mit IR-Sensoren messen, nur ist hier dann das Problem, das die Wegmessung genauer ist als die Hindernismessung.
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.