mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Roboter-Linienverfolgung mit P-Regler und Ausweichmodus


Autor: Brocken Sei (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun mein Programm soweit, dass es prinzipiell funktionieren 
sollte, ich lann es aber leider nicht austesten, da einige der 
Hardwareteile noch nicht da sind.
Deswegen bitte ich euch das einmal anzusehen und eure Meinung zu sagen 
oder mir zu sagen ob es eventuell jetzt schon Bugs in meinem Programm zu 
erkennen sind, die ich übersehen habe.

Eins noch: Der Ausweichmodus wurde noch nicht programmiert. Es geht ums 
Prinzip und um eventuelle Fehler die jetzt schon drinnen sind.

Danke schon im Voraus.

Gruß Bro

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Deswegen bitte ich euch das einmal anzusehen und eure Meinung zu sagen
>oder mir zu sagen ob es eventuell jetzt schon Bugs in meinem Programm zu
>erkennen sind, die ich übersehen habe.

Programmteile in eine Header Datei zu legen ist schon mal
grundsätzlich falsch.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Coding Technik

Welchen Sinn soll es haben, alle Unterprogramme in ein Header File zu 
quetschen. So ist das nicht gedacht!
In einem Header File stehen die Funktionsprototypen und was sonst noch 
so ein Verwender wissen muss. Der eigentliche Quellcode der Funktionen, 
solange er nicht geinlined werden soll, steht immer in *.c Files
http://www.mikrocontroller.net/articles/FAQ#Ich_ha...

//Starte Ultraschall:
extern inline void ultraschall_StarteMessungSRF05(volatile uint8_t *Port, volatile uint8_t TriggerPulse_PIN, volatile uint8_t delayTime_tillSTART_us)
{
  *Port |= (1<<TriggerPulse_PIN);
  _delay_us(delayTime_tillSTART_us);
  *Port &=~ (1<<TriggerPulse_PIN);
}
Das ist zwar jetzt wahrscheinlich nicht wirklich wichtig, aber das
  _delay_us(delayTime_tillSTART_us);
geht gar nicht.
Die _delay_xx Funktionen können nur mit konstanten Zahlenwerten benutzt 
werden. Ansonsten stimmen die Zeiten nicht.

//MesseLinie***************************************************
extern uint16_t messeSollwert()
{
  uint16_t sollwert;
    /*Sollwert messen:*/
        sollwert = GetADC_8bit(2);
  lcd_setcursor(0, 1);
  lcd_string("Sollwert = "); lcd_string(itoa(sollwert, buffer, 15)); //Zeige Messwert an
Du willst wirklich eine Zahlenausgabe im Zahlensystem zur Basis 15?
itoa macht dir das schon, nur ist es .... ungewöhnlich.


Weiter hab ich noch nicht geschaut

Autor: Gregor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P-Regler... ich stells mir grad schon vor wie das ding zittert...

So wie ich das seh hast du 3 Sensoren, die du alle per ADC abfragst, 
dann bildet du aber einen Mittelwert! Du hast also den verwertbaren 
Informationsgehalt tatsächlich gedrittelt!!!!

Bei sowas würd ich ein ganz anderen Ansatz verwenden:
Neuronales Netz: 3 Eingang-Nodes (deine 3 Sensoren) 2 Ausgangs-Nodes 
(Die Motoren) Keine Zwischenebene erforderlich! Jetzt kann man 
wunderschön die 6 Verbindungen gewichten und siehe da man hat ein 
wunderbaren Linienverfolger!

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Programmteile in eine Header Datei zu legen ist schon mal
> grundsätzlich falsch.

Wenn ich sie im Hauptprogramm anlege, dann wird das ganze 
unübersichtlich.
Und wenn ich sie am ende als *. inkludiere, da wurde mir gesagt dass man 
*.c Datein nicht inkludieren sollte.

Was habe ich denn sonst für alternativen?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> holger schrieb:
>> Programmteile in eine Header Datei zu legen ist schon mal
>> grundsätzlich falsch.
>
> Wenn ich sie im Hauptprogramm anlege, dann wird das ganze
> unübersichtlich.
> Und wenn ich sie am ende als *. inkludiere, da wurde mir gesagt dass man
> *.c Datein nicht inkludieren sollte.
>
> Was habe ich denn sonst für alternativen?



main.c
*******
#include "lcd.h"

int main()
{
  lcd_init();

  ....
}

lcd.h
*****
#ifndef LCD_H
#define LCD_H

void lcd_init( void );

#endif

lcd.c
*****
#include "lcd.h"

void lcd_init()
{
  hier die Imlpementierung von lcd_init
}


main.c und lcd.c werden im AVR-Studio unter Source Files hinzugefügt. 
lcd.h wird unter Header Files hinzugefügt.

Compilieren:
lcd.c wird compiliert
main.c wird compiliert

Linken:
lcd.o und main.o werden zum kompletten brennbaren Programm 
zusammengelinkt.

Um Compilieren bzw. Linken brauchst du dich nicht kümmern. Dadurch dass 
man die einzelnen Dateien im AVR-Studio zum Projekt hinzugefügt hat, 
weiß AVR-Studio schon, was es zu machen hat.

Bei Änderungen in main.c wird nur, und tatsächlich nur, main.c neu 
compiliert. Bei Änderungen in lcd.c wird nur, und tatsächlich nur, lcd.c 
neu compiliert und ein neues Programm gelinkt.


(Sinngenmäß natürlich für alle anderen Funktionen genauso. Aufgeteilt 
nach Themenkreisen, d.h. alle LCD Funktionen in 1 Header File bzw 1 
C-File. Für andere Themenkreise genauso. Und natürlich überall alle 
anderen includes die dort noch gebraucht werden. So wird lcd.c natürlich 
auch avr/io.h includieren.)

Aber speziell die LCD Routinen sind im Tutorial bereits nach Header File 
und Source Code File entsprechend aufgeteilt gewesen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
y und differenz sind beides unsigned long und werden in main und der ISR 
verwendet.
Auf der Suche nach atomarer Absicherung beim Zugriff: Fehlanzeige

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damit bin ich konzeptionell nicht einverstanden
      summe = (sensorL1 - sensorR0) + sollwert;  //sensorL1 - sensorR0 ergibt einen Bereich von -235 ... +235 und
                            //addiert mit 235 einen bereich von 0 ... 570 (für PID Algo)
                            //und Sollwert ist dann genau in der Mitte, da sensorM = sollwert

      if((summe > (sollwert - 5)) && (summe < (sollwert + 5)))  //Wenn Sollwert, dann Motoren beide voll
      {
        PWMleft = ON;
        PWMright = ON;
      }
      else if(summe < (sollwert - 5)) //ansonsten mehr links
      {
        differenz = (summe - sollwert) * (-1); //errechne Abweichung
        PWMright += y;   //PWM-Wert für Motor rechts
        PWMleft = OFF;  //MotorRechts = 0
      }
      else if (summe > (sollwert + 5)) //oder mehr rechts
      {
        differenz = summe - sollwert; //errechne Abweichung
        PWMleft += y;   //PWM-Wert für Motor links
        PWMright = OFF;  //MotorRechts = 0
      }



      summe = (sensorL1 - sensorR0) + sollwert;  //sensorL1 - sensorR0

wenn du das einfach signed rechnen würdest, würde isch deine Summe auch 
im signed Bereich bewegen. Kein Grund da mit offsets rumzumachen.



      if((summe > (sollwert - 5)) && (summe < (sollwert + 5)))  //Wenn 
Sollwert, dann Motoren beide voll

Ob du Gas geben kannst sagt dir der Regler und nicht die Sensoren


      else if(summe < (sollwert - 5)) //ansonsten mehr links
      ....
      else if (summe > (sollwert + 5)) //oder mehr rechts
      ....

Ob es links rum oder rechts rum geht, sagt dir der Regler mit seinem y 
und nicht die Sensorwerte.
Wenn du schon einen Regler hast, dann musst du den auch machen lassen! 
Entweder der Regler hat das Kommando oder er hat es nicht. WEnn er es 
aber hat, dann muss er es vollständig haben.

So in etwa
      if( y > -5 && y < 5 )
      {
         PWMleft = FullSpeed;
         PWMRight = FullSpeed;
      }

      else
      {
         PWMleft  = HalfSpeed + y;
         PWMRight = HalfSpeed - y;
      }

Aufgabe des PID Reglers ist es, dir ein y zu geben, so dass dein Wert 
Summe möglichst bei 0 (dem Sollwert) bleibt.
(Ob man jetzt y links oder rechts addiert musst du im einfachsten Fall 
einfach ausprobieren. Zahlenwerte ausgeben lassen und ansehen!)

(Und das FullSpeed würde ich fürs erste beiseite legen. Erst muss der 
Regler funktionieren)

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also entschuldige, dass ich gerade nicht mit euch mitkomme, aber das mit 
den 2 c Files hat gerade mein ganzes Projekt zerstört.
Hab jetzt über15 Fehlermeldungen (die ich auch analysiere) und8 
Warnings.

Ist ziemlich schwer das zurecht zu biegen.

da hilft nicht einmal das
http://www.mikrocontroller.net/articles/FAQ#Ich_ha...
Habs schon gelesen, aber ihr kennt doch Eclipse, die IDE will manchmal 
nicht^^.

Danke für die Geduld!

Gruß Bro

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst das Projekt ja mal anhängen. Ansonsten benutze ich seit Jahren 
AVR-Eclipse und habe jetzt noch nicht festgestellt, dass die manchmal 
"nicht will".

Autor: Brocken Sei (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So!, hab das jetzt so gelassen wie es war. Denn die Deklarationen und 
Definitionen von mir waren nicht falsch und funktioniert wird es nach 
reichlicher Überlegung genau so gut.
Anstatt mich jetzt 2 Stunden mit Files erstellen, kopieren, includes 
einfüge, bleibe ich lieber beim Thema.

Gregor schrieb:
> So wie ich das seh hast du 3 Sensoren, die du alle per ADC abfragst,
> dann bildet du aber einen Mittelwert! Du hast also den verwertbaren
> Informationsgehalt tatsächlich gedrittelt!!!!

Also ich nutze schon den gesamten Bereich aus, wo bilde ich da einen 
Mittelwert`?

Karl heinz Buchegger schrieb:
> Die _delay_xx Funktionen können nur mit konstanten Zahlenwerten benutzt
> werden. Ansonsten stimmen die Zeiten nicht.

ok danke Karl, daswär sicher ne Fehlerquelle!

Karl heinz Buchegger schrieb:
> y und differenz sind beides unsigned long und werden in main und der ISR
> verwendet.

ja

Karl heinz Buchegger schrieb:
> Auf der Suche nach atomarer Absicherung beim Zugriff: Fehlanzeige
Sry, kann dir nicht folgen.

Karl heinz Buchegger schrieb:
> wenn du das einfach signed rechnen würdest, würde isch deine Summe auch
> im signed Bereich bewegen. Kein Grund da mit offsets rumzumachen.

du sagtest doch, dass ich einen Wertebereich von
kleiner Wertigkeit ... großer Wertigkeit brauche, deswegen die 
Rechnerei.

Karl heinz Buchegger schrieb:
> Ob du Gas geben kannst sagt dir der Regler und nicht die Sensoren

ok, da hast du nicht unrecht, da hab ich übertrieben.

@Karl: Die Idee mit Full und Halfspeed find ich klasse, da wär ich nicht 
draufkommen meinen Code so kurz und effizient zu schreiben wie du.
Irgendwie enttäuschend, aber was solls, ich lerne ja daraus.
Habs so übernommen wenns dich nicht stört.

Frage noch: Stört die negative Differenz beim D-Anteil dann nicht?
-->(Kd*((differenz-ealt)/Ta))

Aktuelles Programm im Anhang

Grus Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:

> So!, hab das jetzt so gelassen wie es war.

Das gibt Punkteabzüge. Und zwar massenhaft.
Wie willst du was lernen, wenn du alles gleich liegen lässt, sobald du 
dich verlaufen hast.

Du hast das Chaos angerichtet, also sortier es wieder auseinander.

> Anstatt mich jetzt 2 Stunden mit Files erstellen, kopieren,
> includes einfüge

Geh komm.
LCD und UART waren doch schon richtig aufgeteilt!
Die sind in 5 Minuten wieder auseinanderkopiert, in Files abgelegt und 
dem Eclipse klar gemacht, dass die auch zum Projekt gehören. Und wenn 
alle Stricke reißen, holst du dir halt noch mal die Originale und 
konfigurierst sie noch mal.

>> wenn du das einfach signed rechnen würdest, würde isch deine Summe auch
>> im signed Bereich bewegen. Kein Grund da mit offsets rumzumachen.
>
> du sagtest doch, dass ich einen Wertebereich von
> kleiner Wertigkeit ... großer Wertigkeit brauche, deswegen die
> Rechnerei.

Was spricht gegen -256 .. +256

Ist ein perfekter Wertebereich von ganz links bis ganz rechts :-)

> Frage noch: Stört die negative Differenz beim D-Anteil dann nicht?
> -->(Kd*((differenz-ealt)/Ta))

Das Kd hat ja auch noch ein Vorzeichen :-)

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird sowieso nicht auf Anhieb laufen.

Kenn das von meinen Kiddies, da wird ein "riesiges" Programm komplett 
geschrieben, ohne ein einziges Mal zwischendrin am Roboter zu testen. 
Ergebnis:
Die Kinder wissen nicht, wo sie bei der Fehlersuche anfangen sollen, da 
sie noch nicht mal getestet haben, ob der Motor mit ner positiven 
Geschwindigkeit auch nach vorne fährt.

Daher testen, testen, ...
:-)

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Das gibt Punkteabzüge. Und zwar massenhaft.
> Wie willst du was lernen, wenn du alles gleich liegen lässt, sobald du
> dich verlaufen hast.

Verdammte scheiße, ich wusste es doch das sowas kommt, ich weiß ich 
weiß. Aber kaum beschäftige ich mich mit dem geht der Thread schon unter 
und ich muss mir wieder einen neuen Thread überlegen, langsam gehn mir 
die Titeln aus.

Karl heinz Buchegger schrieb:
> Das Kd hat ja auch noch ein Vorzeichen

stimmt, das gleichsts aus, aber Kd lege doch ich fest, könnte ja 
trotzdem sein, dass es Probleme gibt.

Also ich werd dann meine Files studieren und richtig stellen^^

Gruß Bro

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Floh schrieb:
> Wird sowieso nicht auf Anhieb laufen.

Das ist klar, damit wäre bei keinem grßeren Projekt zu rechnen.

Floh schrieb:
> da wird ein "riesiges" Programm komplett
> geschrieben, ohne ein einziges Mal zwischendrin am Roboter zu testen.
> Ergebnis:

Nein nein, ich teste zwischendurch Sensorik und zeige auf Display an obs 
passt.

Floh schrieb:
> ob der Motor mit ner positiven
> Geschwindigkeit auch nach vorne fährt.

Tja also mein Motor fährt schon ohne dass ich ihm den Befehl gebe, den 
Fehler da zu finden ist zwar möglich aber nicht notwendig da ich die 
Hardware nicht aufkriege ohne sie zu beschädigen.
Daher arbeite ich gerade an einer neueren zuverlässigeren und stabileren 
Hardware.

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
> Karl heinz Buchegger schrieb:
>> Das gibt Punkteabzüge. Und zwar massenhaft.
>> Wie willst du was lernen, wenn du alles gleich liegen lässt, sobald du
>> dich verlaufen hast.
>
> Verdammte scheiße, ich wusste es doch das sowas kommt, ich weiß ich
> weiß. Aber kaum beschäftige ich mich mit dem geht der Thread schon unter
> und ich muss mir wieder einen neuen Thread überlegen, langsam gehn mir
> die Titeln aus.

D a n n   m a c h   d i e   D i n g e   g l e i c h    r i c h t i g  !

Ist ja nicht so, dass die Einzelteile die du dir aus dem Web 
zusammengesucht hattest, nicht dafür vorbereitet gewesen wären. Das hat 
schon seinen Grund, dass man überall ein Header File UND ein C-File 
bekommt. Das C-File kommt zum Projekt dazu und wird compiliert. Das 
Header File wird in meinem eigenen Source-File #includiert und 
informiert den Compiler, wenn er meinen Source Code compiliert, was im 
anderen (dem downgeloadeten) Source Code File enthalten ist, welche 
Funktionen es dort gibt, wie sie heissen und welche Argumente die 
Funktionen nehmen.

Autor: Brocken Sei (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Programmteile in eine Header Datei zu legen ist schon mal
> grundsätzlich falsch.

Ok, habe es jetzt richtig gemacht.

Danke bis dahin!

Habe ich sonst wo Fehlerhafte Quellen drinnen?
Mich würde der Teil mit dem Ultraschall interessieren.
Den habe ich mir heute neu überlegt.
Ob da vielleicht noch ein Bug drinnt ist?


Gruß Bro

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Warnung kriege ich noch:

inline function 'ultraschall_StarteMessungSRF05' declared but never 
defined  Unterprogramme.h

definiert ist sie aber in Unterprogramme.c

Diese Meldung wird in Unterprogramme.h angezeigt.

Kann mir wer helfen?

Gruß Bro

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Häng das Projekt an, wir können doch nicht hellsehen!

Autor: Brocken Sei (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Häng das Projekt an, wir können doch nicht hellsehen!

Hab gedacht die Files reichen, sry.
Gemacht!

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nimm das inline raus.
Wie soll den der Compiler inlinen, wenn er den Code nicht zur Verfügung 
hat?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm das "inline" weg. "extern inline" macht AFAIK eh keinen Sinn. 
Inline solltest du erst mal meiden.

Übrigens gibt es noch eine Warnung, weil du die Optimierungen 
ausgestellt hat.

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, recht habt ihr, sehe es auch gerade.

Simon K. schrieb:
> Übrigens gibt es noch eine Warnung, weil du die Optimierungen
> ausgestellt hat.

Bei mir nicht, habs es auch eingeschalten.

Ok, danke allen hier.

Geh jetzt mal schlafen.

Nacht, Bro

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.