Kommentare

Hallo Searcher,

natürlich habe ich gesehen, woran du bastelst. Ich verfolge deinen Blog genau und mit viel Freude. Es sieht sieht super gut aus, wie dein steppender Linienfolger schön exakt und ohne erkennbare Schwingungen die Linie nachfährt. Ob das bei meinem Butler auch so gut klappen wird, werde ich erst sehen.

Knicke brauche ich deshalb, weil ich die Bahn aus bedruckten DIN A4 Einzelblättern auslegen möchte. Knicke von 90° sind erstmal nicht vorgesehen. Wenn mein Butler 45° schafft ohne das Getränk zu verschütten, bin ich schon zufrieden. Ich werde dann auch ein Video posten, als neuen Blog-Beitrag oder als Kommentar zu dem alten Roboterbeitrag wie ich das bis jetzt gemacht habe. Was würdest du vorschlagen?

Tja, jetzt zu deiner schwierigen warum Frage. Ich habe mehrere Gründe für die verwendung von mehreren µC:
1. I/O Pins des Haupt µC sparen
2. Spaß an Modulen, die ich separat testen kann.
3. Um die PICs zu verbasteln, die ich in 10er Losgrößen in China bestellt habe, als der EUR noch hoch stand

Der Liniensensor hat nur 3 Bits zu melden, da nehme ich einfach HW Verbindung mit TTL Pegeln. Bei größeren Datenbreiten würde ich I2C nehmen.

Gruß
witkatz

Hi,
ich bastele ja an was Ähnlichem. Habe nur zwei Photodioden, die analog an einem ADC ausgewertet werden. Funktioniert sehr gut mit Motoren, die praktisch sofort auf Steuerungsinformationen reagieren können ABER ein rechtwinkliger Knick in der Linie wird einfach nicht wahrgenommen und somit ignoriert außer ich schneide ein kleines Dreieck an der Außenkante des Knicks an der Linie ab. Bin gespannt, ob Dein Sensor bzw die Auswertung das packt. Ich muß vermutlich noch irgendetwas nachrüsten (oder alle 90° Knicke beschneiden )

Warum benutzt Du mehrere µCs und wie werden die beiden verbunden, HW und Protokoll?

Viel Erfolg und
Gruß
Searcher

Das Handling des Abstand- und Kollisionssensors im Haupt µC (PIC18F4520) ist fertig getestet. Ich frage den HC-SR04 in einer 250µs ISR Routine ab, damit komme ich auf eine Genauigkeit von +/- 4cm. Für eine Distanzmessung zwecks Kollisionservermeidung ist es ausreichend.

Code:

volatile struct {
    char LastColSensor:1;
    char NewRawColDistanceAvailable:1;
    char reserve: 6; 
} Flags;

void interrupt isr(void)
{
    // 250 µs Interrupt, oscillator 32MHz, TMR0 prescaler 1:16
    TMR0 -= 125; // Timer Value for next 250µs interrupt
    
    // ...

    // handling collision sensor in 250µs ISR Routine
    Tmr16bit250usColSens++;
    if ((CollisionSensor == 1) && (Flags.LastColSensor == 0)){
        // handle positive trig collision sensor
        Tmr16bit250usColSens = 0; 
        Flags.LastColSensor = 1;
    }
    if ((CollisionSensor == 0) && (Flags.LastColSensor == 1)){
        // handle negative trig collision sensor
        RawDistanceToCollision = Tmr16bit250usColSens;
        Flags.NewRawColDistanceAvailable = 1;
        Flags.LastColSensor = 0;
    }
    
    INTCONbits.T0IF = 0;
}
/* CalcDistanceToCollision should be called in main routine minimum every 30ms
 */
void CalcDistanceToCollision(void){
    if (Flags.NewRawColDistanceAvailable){
        // calculate new distance value
        // distance in cm = 4.5 * Distance in 250µs ticks (ca.); 
        // filtered distance = (3 * filtered distance + new distance) / 4;
        DistanceToCollision = 
                ((DistanceToCollision << 2) - DistanceToCollision // 3 * filtered distance 
                  + (RawDistanceToCollision << 2) + (RawDistanceToCollision >> 1)) // + distance in cm
                >> 2; // / 4
        Flags.NewRawColDistanceAvailable = 0;
    }    
    if(Tmr16bit250usColSens > 600){ // limit max to 150ms
        Tmr16bit250usColSens = 600;
        DistanceToCollision = 0;        
    } 
}

Zum Testen der Auswertung ist es praktisch, den Wert in cm auf Display auszugeben. Im Video sieht man den Signalverlauf des vom PIC12F675 zusammengefassten Signal der 3 HC-SR04 und des Reedsensors und eine Testausgabe der Distanzmessung auf LCD. Dann folgt ein Fahrauftrag "60s gerade aus", der bei gemessenen 40cm Abstand vor einem Hindernis vorzeitig beendet wird.

Mein Roboter bekommt jetzt einen Distanz- und Kollisionssensor. Eine Prallplatte aus einem Kabelkanaldeckel mit 3 HC-SR04 Sensoren und einem Magneten ist schwenkbar aufgehängt. In der Ruhelage wird ein kleiner Reed-Schließer von dem Magneten geschaltet. Wird bei Kollision die Platte frontal oder seitlich berührt, dann wird der Reed-Kontakt frei und der Sensor schaltet. Der Sensor hat eine Anzeige LED zur Schaltkontrolle, damit man die Position schnell nachjustieren kann.

Die drei HC-SR04 werden alle gleichzeitig von einem PIC12F675 getriggert. Der PIC generiert mit Timer0 alle 65ms ein 250µs Puls, einfach Timer0 mit 1:256 Prescaler bei 4MHz internem Takt laufen lassen und Bit 0 des Timer0 auf GP0 ausgegeben. Die drei Echo-Signale der HC-SR04 und das Signal des Reedsensors werden zu einem einzigen Signal verUNDet, und zum haupt-µC gesendet.

Bild hier  
Bild hier  

Zitat von witkatz

Das aktualisierte Video im ersten Blogbeitrag zeigt den Motortest nach Einschalten und eine Testfahrt mit einem (halbvollen ) Glas Apfelsaft.

Sieht gut aus und scheint ja was zu werden. Allerdings passiert mir da zu wenig. Glas ruhig mal randvoll machen
Gruß
Searcher

Der Roboter wird jetzt mit einem PIC18F4520 mit 32MHz internem Oszillator gesteuert. Für die Ansteuerung der Motortreiber habe ich die PWM Frequenz auf ca. 16kHz parametriert:

Code:

    // CCP/PWM 
    PR2 = 0x7F; // 15625Hz, PWM Freq = OscFreq / 4 / (PR2+1) / TMR2_Prescale
    CCPR1L = 0; CCP1CONbits.DC1B = 0; // PWM Duty Cycle
    CCPR2L = 0; CCP2CONbits.DC2B = 0;
    TRISCbits.TRISC2 = 0; // set CCP1 pin to Output
    TRISCbits.TRISC6 = 0; // set Reverse_MotorL pin to Output
    TRISCbits.TRISC1 = 0; // set CCP2 pin to Output
    TRISCbits.TRISC5 = 0; // set Reverse_MotorR pin to Output
    T2CONbits.T2CKPS = 0b01; // TMR2 Prescaler 4
    T2CONbits.TMR2ON = 1; // TMR2 on
    CCP1CONbits.CCP1M = 0b1100; // CCP1 PWM Mode
    CCP1CONbits.P1M = 0b00; // CCP1 Enhanced PWM: Single Output
    CCP2CONbits.CCP2M = 0b1100; // CCP2 PWM Mode

Für sanften Anlauf sorgen 1s Beschleunigungs/Verzögerungsrampen mit 4ms Timervariablen:

Code:

    softtmr_1 = 250;
    while(softtmr_1){
        MotorL_vor(250-softtmr_1); // 1s beschl Rampe
    }
    softtmr_1 = 250;
    while(softtmr_1){
        MotorL_vor(softtmr_1);  // 1s verz Rampe
    }

Das aktualisierte Video im ersten Blogbeitrag zeigt den Motortest nach Einschalten und eine Testfahrt mit einem (halbvollen ) Glas Apfelsaft.

Das Projekt schreitet langsam voran. Die Motortreiberplatine mit Spannungsversorgung und Batterieüberwachung ist soweit auf Rasterloch fertig. Die Motoren können jetzt in beide Richtungen drehen, getestet erstmal nur per manuellem Setzen der Signale. Die µC Platine mit PIC18F4520 ist jetzt im Aufbau.

Bild hier  

Ich habe die Angaben über den Compiler-Vergleich korrigiert, nachdem ich gemrkt habe, dass in dem XC8 File als Überbleibsel von einem Test einige Variablen absolut adressiert waren. Das hat das Ergebnis für den XC8 "geschönt", weil der XC8 bei absoluter Adressierung einige Bankumschaltungen weglässt. Das ist sozusagen eine unbeabsichtigte "Optimierung", die ich nicht benutzen möchte, weil ich absolut adressierte Variablen vermeiden möchte. Jetzt sind die C-Files auf dem gleichen Stand, alle Variablen automatisch adressiert und XC8 Free fügt wie gewohnt seine überflüssigen Bankumschaltungen ein, die erst in den kostenpflichtigen STANDARD oder PRO Versionen wegoptimiert werden. Diese zusätzlichen 15 Assemblerbefehle im Compilat, bzw. 5% mehr Maschinencode sind in dem Fall kein Beinbruch

Ich habe etwas mit dem BoostC Compiler von Sourceboost in der MPLAB Umgebung experimentiert und den Quellcode für dieses Projektchen mal mit BooostC Compiler abgeändert (s. Anhang).

Interessant war für mich der Vergleich der Optimierungen von XC8 im "free mode" also geringer Optimierungsstufe und BoostC im Optimierungslevel "Normal". Für dieses kleine Beispiel optimiert BoostC etwas besser als der XC8 im Free Mode. In diesem Projektchen erstellt XC8(Free mode) 375 Worte und BoostC 350 Programmworte, wobei die Wertetabelle im ROM schon 128 Worte belegt, die nicht wegoptimiert werden können. Dh. BoostC optimiert das Programmcode etwa 10% besser (nach Abzug der Wertetabelle). Diese Optimierungen wirken sich stark auf die Frequenz der Soft PWM aus, die ich trivial mit einer Schleife gelöst habe. Mit BoostC wird die Schleife in ca. 5,5ms durchlaufen, mit XC8 in ca. 6,3ms. Ich habe eine max. SoftPWM-Frequenz von 100Hz auf 4 Ausgangspins angestrebt und das ist mit beiden Compilern locker erreicht. Insgesamt sind die Unterschiede zwischen XC8 free und BoostC bei solch kleinen Projekten nach meiner Meinung nicht wirklich relevant.

Die Schaltung ist auch schon fertig und funktioniert.
Bild hier  

In ein Schaltnetzteil Pollin 94-350324 eingebaut wird die Fernsehhintergrundbeleuchtung jetzt per TV-Fernbedienung von der Couch aus geschaltet.

Jetzt habe ich mal zum Spaß den SIRCS Sniffer mit LCD auf C umgeschrieben, Quellen sind angehängt.
Prozessor ist der gleiche PIC16F876, Compiler ist der kostenlose XC8 von MICROCHIP im Free Mode.

Damit ist dieses Projektchen auch wieder abgeschlossen. Jetzt warte ich darauf dass meine Videorecorder-Fernbedienung wieder mal den spradischen Fehler zeigt, dann kann ich mich mit meinem SIRCS-Sniffer dazwischen hängen.
Und die Bauteile für mein nächstes, darauf basiertes Projektchen werden auch gerade bei Pollin komissioniert ... mit der gelben Taste der TV-FB soll die Fernseh-Lampe ein/ausgeschaltet werden.

Ich habe den ersten Blog-Artikel überarbeitet und den länglichen Quellcode für SIRC-12 gelöscht.

SIRC-12 reichte nicht aus, weil meine Videorecorder-Fernbedienung SIRC-12 und SIRC-15 mischt und die DVD Fernbedienung gar SIRC-20 sendet. Also habe ich das PIC ASM Projekt erweitert, so dass auch die 3bit und 5bit Extensions bei Bedarf angezeigt werden.
Bild hier  

So. Für meine Zwecke reicht es. Ich kann die SIRC Codes detektieren und anzeigen und (vor allem) Fehler erkennen und anzeigen. Mehr wollte ich mit dem Testaufbau zunächst mal nicht erreichen. Auf dem Bild sieht man die Hex-Anzeige eines aufgeschlüsselten SIRC-20 Telegramm der DVD-Fernbedienung mit Play-Command 0x32 + Adresse mit den beiden Extensions für DVD-Player. Das Telegramm wurde 6-mal wiederholt - ein relativ kurzer Tastendruck.

Zitat von witkatz

Damit ist für mich mein erstes Roboter-Projektchen und damit auch dieser projektbegleitende Blog abgeschlossen.

War und ist interessant und ich bin auf den nächsten gespannt.
Gruß
Searcher

Die auf Dual-Komparator aufgebaute IR Reflexlichtschranke (Schaltbild) funktioniert ganz gut. Hier ein Action-Video mit Kollisionserkennung. Die niedrigen Hindernisse werden von der Prallplatte mit Reed-Kontakt erkannt. Die höheren Hindernisse erfasst die IR Lichtschranke. Die Lichtschranke ist verdrahtet auf PortC.RC5 und mit ein paar ms in der Software entprellt.


Damit ist für mich mein erstes Roboter-Projektchen und damit auch dieser projektbegleitende Blog abgeschlossen.

Danke Searcher, der Lob tut gut.
Gut zu wissen, dass hier im Blog überhaupt mal jemand vorbei schaut

Ich bin jetzt dabei, für den WR1 einen LowCost IR Distanzsensor für kollisionsfreie Hinderniserkennung zu entfrickeln. Die Schaltung habe ich auf dem Steckbrett bereits getestet, sie erkennt zuverlässig meine Hand als Hindernis.

• Die Versorgungsspannung (2 Alkaline Zellen) schwankt zw. 3,3V und 2,5V bei Belastung.
• Sendefrequenz (40kHz) und Abtastrate (50%) lassen sich einstellen und bleiben im Spannungsbereich der schwankenden Versorgung stabil. Für die Justierung ist ein DSO mit Frequenz und DutyCycle Anzeige nützlich.
• Das Senden kann von der MCU freigegeben/gesperrt werden. Für meinen langsamen "Traktor" würden 1ms kurze Pulse mit 5-10Hz für die Hinderniserkennung langen

21.05.
Ein einfacherer IR-Distanzsensor mit dem Dual-Komparator-IC MCP6542 auf Steckbrett getestet:
http://www.roboternetz.de/community/...5&d=1400662478
Der einfache Komparator-Kippschwinger lässt die IR Sendedioden mit 7kHz pulsen. Die Photodioden werden von der zweiten hälfte des Dual-Komparators ausgewertet. Mit dem Trimmer lässt sich der Arbeitspunkt und die Empfindlichkeit einstellen.

Hallo witkatz,,
Klasse! Hab Deinen "Traktor" gerade erst entdeckt und mußte beim Anschauen der Videos einfach nur schmunzeln. So ausgefallene Konzepte gefallen mir einfach nur zu gut!

Gruß
Searcher

Ich habe dem WR1 eine Motor-Stromüberwachung verpasst. Damit wird jetzt zuverlässig Überlast und Blockade erkannt und der Motor abgeschaltet, bevor die Batterie leergelutscht ist. Über ein RC-Filter wird der Strom am Shunt über AN0 gemessen und überwacht.

Code:

;=== Stromüberwachung ==========================================================
IsenseMonitor
    btfsc ADCON0,GO             ; if (ADC ready)
    goto IsenseMonitor_e        ; {
    movlw 0x47                  ;   if (ADRESH < 0x46)  // I_Motor < 700mA
    subwf ADRESH, w             ;       // w=ADRESH-0x47
    skpnc                       ;       // C=ADRESH>=47
    goto IsenseMonitor_1        ;   {
    M_MOVLF I_Wacthdg, d'125'   ;       I_Wacthdg=125; // Reset Überstrom 0.5s Überwachungszeit
IsenseMonitor_1                 ;   }
    bsf ADCON0,GO
IsenseMonitor_e                 ; }

Übersteigt der Strom 500ms lang den Grenzwert und die Software-Timer Variable zu Null dekrementiert, schaltet der PIC den Motor aus und der WR1 hupt 4-mal. Die Anzahl der Huptöne dient als Status bzw. Fehlermeldung und macht den Roboter lebendiger.

Das Assembler-Experimentieren mit PICs macht super Spaß. Die gefädelten Testplatinen wurden ständig überarbeitet. Im Startbeitrag habe ich die Schaltpläne für 8/14-polige und 18-polige PIcs aktualisiert. Auf den Testplatinen habe ich jetzt pro Port jeweils: 2 Wannenstecker nach RN-Standard, 1 Buchsenleiste nach Sprut-Standard und eine Klemmleiste WAGO 233-510 mit Öffnungshebel‎ verdrahtet. Somit sind die Testplatinen sehr flexibel für den Anschluss diverser digitaler und analoger Ein/Ausgabe Testplatinchen bzw. Anschlusskabelchen zum Steckbrett u.a.

Nun ist die Steuerung auch lauffähig. Der WR1 fährt selbstständig, erkennt Hindernisse, wendet und hupt. Was will man mehr vom ersten Roboter? Als Kollisionssensor dient eine Prallplatte auf aufgebogenen Büroklammern federnd montiert und mit Magnetband + Reed-Kontakt. Die Steuerung übernimmt ein PIC16F688, programmiert in Assembler.

Bild hier  

Hier ist das Schaltbild der Steuerung.

Was noch fehlt, ist die Überwachung des Motorstroms, um Festfahren zu erkennen.
Als nächstes habe ich vor mit IR Optoelektronik zu experimentieren und eine IR Reflexionslichtschranke zu bauen. Die kann ich am WR1 testen damit er die Hindernisse sieht, bevor er drauf fährt