Jump to content

jgmischke

Members
  • Gesamte Inhalte

    212
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von jgmischke

  1. 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?

     

     

  2. 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?

    brickv_finder.png.1f6e28d23b2fd24ba62d42faf21e68a5.png

  3. @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??

  4. 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??

     

     

     

     

  5. 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.

  6. 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.

×
×
  • Neu erstellen...