jgmischke

Gut, hab ich mir so auch gedacht. Danke.

OK, verstanden. Das heisst aber auch, dass der Callback vier mal ausgelöst wird, da ich ihn ja jedesmal mit einer anderen DeviceID angelegt habe? ( Jetzt im Beispiel bei 4 Potis ?? )

Wie sieht es mit folgender Konstruktion aus? Ich habe ein Array aus Bricks/Bricklets. Darin werden alle relevanten Werte zu jedem Brick gespeichert. Als Beispiel : struct MyD { int TinkerDevIDNr; // Das ist die Nummer des Device Identifiers, KEINE laufende NR.!!! char TinkerName[LN]; char TinkerShortName[sN]; char TinkerUID[CL]; // Das ist die UID }; Wenn ich jetzt etwa 4 Linearpotis habe, würden diese alle über die gleiche Funktion eingestellt werden, also etwa : void initPOTI( Device MD ) { POTI_Einstellungen(MD); } void POTI_Einstellungen ( Device MD ) { linear_poti_register_callback(&MD, LINEAR_POTI_CALLBACK_POSITION, POTIDaten, NULL); linear_poti_set_position_callback_period(&MD, 10000); } Da sich unter Device MD immer eine anderes Device verbirgt, wie ,sieht es da mit den Callbacks aus? ( Auch hier gibt es ja das Device ) Werden dann 4 Threads für die 4 Potis gestartet? Dann sollten doch auch die Callbacks völlig getrennt voneinander laufen und unterschiedlichste Ergebnisse liefern oder?

Nein, schon um die tatsächliche Schwerkraft. Hatte beim brickv gesehen, das der Schwerewert mit 9.xx m/s angebeben wurde. Die Frage ist eben dann, wie genau ist das Teil und könnte eine Abweichung ( natürlich wenn der Brick in Ruhe ist ) vom Normwert gemessen werden??

Lässt sich mit dem neuen IMU 2.0 die Änderung des lokalen Schwerefeld messen. Von der Auflösung her müsste es doch gehen oder? Die üblichen Schwankungen liegen so bei 0,01%.

Ja, funktioniert super. Jetzt liegen die Werte so wie sie sollen. Danke fürs schnelle fixen.

Werde ich mal testen und dir berichten.

Habe heute mal ein wenig rumgespielt und dabei ist mir folgendes aufgefallen. 1.) Servobrick mit einem Servo, darauf der Finder. Servo eingeschaltet und dreht sich regelmässig. Die Werte die der Laser dabei ausgibt, schwanken ungemein. Die Entfernungen passen überhaupt nicht. Wo sonst ein paar cm angezeigt werden, kommen hier auch im brickv Werte von mehreren hundert (!) Metern zusammen. 2.) Das gleiche zusätzlich jetzt mit einem Master drunter, den Finder auf dem Master! Alles läuft so wie es soll, die Entfernungen stimmen und schwanken wenn überhaupt im cm Bereich. Brickv ist die neueste Version, A/D Wandler hab ich mit nem Linearpoti kalibriert. Und es ist egal, ob ein Servo dranhängt oder nicht. Mit einem Stepperbrick geht das ganze übrigens auch, da zeigt er aber wie erwartet normale Werte an. Frage: Warum ist das so?

@NIC Sowas versuche ich auch gerade. Allerdings fehlt mir CAD Kenntnis und ein 3D Drucker. Und etwas "billiger" soll das Teil auch werden. Kannst du mehr von deinem Projekt berichten?

Na hoffentlich habt ihr genug auf Lager. Das Teil wird bestimmt ein Renner.

@photron ... So, heute hab ich das ganze mal getestet. Erstaunlicherweise erkennt lsusb und dmesg den Funkstick vom USB Teil als USB reciever, aber irgendwie passiert trotzdem nichts. Ich bekomme von dmesg : [ 99.071977] usb 3-1: new full-speed USB device number 2 using sw-ohci [ 99.326072] logitech-djreceiver 0003:046D:C52B.0003: claimed byneither input, hiddev nor hidraw [ 99.326104] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:hid_hw_start returned error Vielleicht doch ein Treiberproblem??

Ja, das war es schon. Manchmal sieht man den Wald vor lauter Bäumen nicht. Danke für den Tipp.

@NIC. Nein, ist mir schon klar, dass für den Roten ein paar Besonderheiten gelten, zumal das Teil ja noch relativ frisch ist. Es geht ja nur darum, mal zu sehen, was geht und was nicht. Und das ist schon irre was da alles funktioniert, sofern man brav Standard proggt.

Gut, dann warte ich mal auf das neue Image. Kernel 3.4 ist ja schon ein wenig betagt, von daher kann das hut sein. Alle anderen Linuxmaschinen die ich hier habe kommen damit klar, haben aber auch kernel > 3.10.

Habe hier ein kleines Problem bei den callbacks. Vorgabe laut API: ( Hier humidity als Beispiel ) humidity_register_callback(&humidity, HUMIDITY_CALLBACK_EXAMPLE, (void *)my_callback, NULL); Und beim Callback dementsprechend : void my_callback(int p, void *user_data) Jetzt war meine Idee, beim initialisieren der Bricks einen INT Wert mit zu übergeben. Also etwa int t = 999; und humidity_register_callback(... &t). Nun würde ich unter *data einen Wert erwarten. Den bieg ich zurück mit fprintf(stderr,"A=%d",*(int*)data); Krieg aber nun nicht meinen Wert, sondern was mit 32XXX zurück. Ich tippe mal, da wandel ich noch irgendwas nicht um. Als kleines C Programm : void c ( void *data ) { printf("A=%d",*(int*)data); } main() { int a = 999; c(&a); } funktioniert die Dereferenzierung wunderbar. Im Tinkerprogramm nicht. Auch ein callback(..., (void *) &t)); brachte keine Verbesserung. Wahrscheinlich fehlt noch irgendein Zwischenschritt, der Wert mit 32XXX lässt mich mal vermuten, das noch irgendwo eine Bytegrösse per cast angepasst werden muss? Das Ganze läuft auf einem 64 Bit Ubuntu. Irgendeine Idee??

Habe mir gestern eine Funktastatur mit Maus geholt und am Red Brick angeklemmt. Leider funktioniert es dort nicht. Ist da zuwenig Strom am USB Port? ( An anderen Rechnern funktioniert das Teil? )

Hallo baboboy ... gedacht ist das ganze ja so, das über ein IMU Brick die Lage des "Zentrums" des Robot über Servos dem entgegenwirken soll. Wie genau muss ich noch austesten, wichtig ist für mich, das auch Treppen kein Problem sein sollen und dafür war die Idee mit den Potis. So sollte es möglich sein, eine Treppe quasi zu ertasten. Mal schauen, das Ganze wird sicherlich noch was dauern bis es real wird, im Moment programmiere ich erst einmal eine Umgebung für alle Bricks, bei der alle relevanten Daten gesammelt werden. Dann kommen die Servos und die Steurung dran. Dann muss ich mir jemand suchen der sich etwas mit CAD auskennt und die Teile werden dann über einen 3D Drucker erstellt. Wird also noch was dauern, aber ich hab ja Zeit. Da der Robot relativ gross wird, sollte die Grösse der Potis kein Problem sein. Vorlage ist ein Spinnenmodel, wo das Zentrum schön zentral liegt und gut ausbalanciert werden kann. Und 6 Beine sollten da reichen.

Für meinen Roboter überleg ich mir, am Ende der Beine je einen Sensor einzubauen, der für jedes der Beine folgendes anzeigt: Bodenkontakt J/N und ungefähre Belastung des Beines. Gedacht ist folgendes. Das Poti kommt an eine Stange, diese ist quasi das Endstück eines Beines. Eine Feder schafft einen permaneten Druck aufs Bein, d.h. wenn dieses sich in der Luft befindet, ist das Poti auf maximalen Ausschlag und das Bein "hängt" quasi im Nichts.. Geht das Bein auf den Boden, verändert sich durch die Kombination Stange/fetstgemachtes Poti der Wert und ich kann dann darauf reagieren. Blödsinn oder machbar? Da der Robot nicht winzig ist, wäre die Grösse der Linearpotis KEIN Problem.

Wie wäre es denn mit einem Device Array, in das du je nach Bedarf die unterschiedlichen Devices reinpackst. Die Initailisierung würde dann über das Devicearray erfolgen. Also etwa: Device[0] = Bricklet0 Device[1] = MasterBrick Device[2] = uws.

Ups, da dürfte das wohl das teuerste Teil bei TF sein. Aber wenn es so präzise arbeitet, ist das schon ein sehr sehr guter Preis dafür. Bin schon gespannt.

Guter Tipp. Habe meine Idee von heute morgen eingebaut und das ganze fluppt jetzt so, wie ich es brauche. Deine Sachen schau ich mir aber auch mal an. Danke!

Ich dachte auch mehr an den Aspekt "lieber doppelt, einmal Licht und einmal US" aber mal sehen, was "euer" Laser so draufhat. Gibt es schon einen Daumen-mal-pi-Preis was das Teil so kosten soll???

So, die Timer mit ihren Signalen bringen mir zuviel durcheinander. Habe jetzt einen Thread mit einem Sleep in einer Schleife, der tut es auch und kollidiert nicht mit den TF Sachen.

Das Makefile wird generiert. ( Von Anjuta ) Wie geschrieben, das umsetzen per Hand ist kein Aufwand, bzw. das Schreiben in ein dafür erstelltes Verzeichnis. Ist halt nur ein wenig Mehrarbeit.

Danke für den Tipp. Ich werde da mal draufschaune und befürchte, das du da Recht hast.