Projekt_Rasenmäherroboter mit Raspberry/Arduino und C-Sprache

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Naja vielleicht kurz: langes, kurzes, nasses, trockenes Gras, verschiedene "Kräuter" und Moos zwischendrin, Gras unter Sträuchen/Bäumen oder direkt in der Sonne, erster Bodenfrost, ...

    Alles Umweltbedingungen, die da einfliessen. Dazu kommt dann das EIgenleben des Sensors (siehe Bodenfeuchte).

    Ich denke schon, das das eine Herausforderung sein kannn ...

  • Projekt_Rasenmäherroboter mit Raspberry/Arduino und C-Sprache? Schau mal ob du hier fündig wirst!

  • Meinst du sollte ich lieber den rasensensor seien lassen und doch eine grenzschleife einbuddeln? ( und die Zeit in eine andere sinnvollere Feature investieren)

    Manche Redewendungen verstehe ich beim lesen nicht ( wie sie gemeint sind):/

    Grüße aus Berlin,

    Golpe



  • Also für den Anfang würde ich den technisch einfachsten und robustesten Lösungsansatz wählen ...

    Ausfeilen kannst Du das Teil später immer noch.

    Also erst mal fahren und ausweichen sowie zurück zur Ladestation. Damit, denke ich, hast Du Dir erst mal genügend vorgenommen.

    cu,

    -ds-

  • Na das heißt erstmal grenzschleife und nicht rasensensor benutzen, vermute ich mal.

    Gibts hier schon einen Thread bzgl. Selbständig zur Ladestation fahren bzw. Begrenzungschleife oder ein externer link, der hilfreich seien könnte?

    :danke_ATDE::danke_ATDE::danke_ATDE:

    Grüße aus Berlin,

    Golpe



  • Gibts hier schon einen Thread bzgl. Selbständig zur Ladestation fahren bzw. Begrenzungschleife oder ein externer link, der hilfreich seien könnte?

    Hm ... mir ist da jetzt so ad hoc nix bekannt.

    Ladestation würde ich, glaube ich, der Einfachheit halber auch mit einer Art "Leitsystem" z.B. so ähnlich wie die Begrenzung machen. Einmal in der Mitte quer durch den Rasen von einer Begrenzung zur gegenüberliegenden. Dann findest Du immer zurück ins Häuschen ;)

    Viel Spass und Erfolg noch,

    -ds-

  • Moin!

    soooo.

    ich glaube dass ich alle Vorschläge von dreamshader abgearbeitet habe (bestimmt nicht so schick wie man es machen sollte).

    An die Art und Weise, wie ich die Returns der Funktionen abfrage bezweifle ich noch... (bestimmt gibts geschickte Wege oder? und effizienter... und vor allem lesbarer?)

    Jedenfalls laufen nun im End Effekt 2 Programme paralell aber ich habe nur eine Konsole. Gibts einen Weg die printf´s von beide Prozesse auf der Konsole auszudrücken?

    nach die Änderungen bleibt der Ultraschall thread weitherhin in der erste while Schleife hängen (ECHO ändert sich nicht, trotz ich davor einen fallender Flanke erzeuge).

    Wenn ich die Ultraschall Funktion bzw. ihre Aufruf auskommentiere, kriege ich den ursprüngliche Prozess auf die Konsole, nun natürlich schneller, denn ich habe den Delay geändert, aber dadurch, reagiert der Simulationstaster für "enable" nicht ordnungsgemäß.

    D.h. wenn ich einschalte gehts, aber beim ausschalten geht Enable nicht immer auf dem ersten Tastendruck auf 0. Soll ich die Zeit doch höher machen oder liegt es an etwas anderes? hat damit die Pullup oder down Widerstand damit was zu tun?.

    auf dem u.g. Code habe ich ein Paar Fragen als Komentar geschrieben, die ich mir stelle.

    Dazu kommt folgendes:

    1. Da der Code immer länger und unübersichtlicher wird, kann man Funktionen wie bei mir "Initialisierung von GPIO" und "setmode gpio" oder threads wie bei mir die US Messung als Bibliothek oder Block oder sowas in einen extra Datei speichern und auf dem Datei von Main und State Machine als Header einbinden?

    2.Sollte man immer bei der Funktionsabfrage den exit(1) schreiben? bzw. gibts eine andere möglichkeit die Returns abzufragen, so dass, dadurch der Code nicht so lang wird? bzw. lesbarer?

    3. Ich habe gestern angefang, mich mit Theorie von Pointer bzw. Zeiger zu beschäftigen, denn ich sehe das ich überall gebraucht werden. Sollte ich mich mit dem Thema weiter, tiefgründig beschäftigen oder nur so ein paar Anhaltspunkte kennen?

    danke!

    Grüße aus Berlin,

    Golpe



  • Hi Golpe,

    zunächst kurz zu Deinen Punkten:

    1. Da der Code immer länger und unübersichtlicher wird, kann man Funktionen wie bei mir "Initialisierung von GPIO" und "setmode gpio" oder threads wie bei mir die US Messung als Bibliothek oder Block oder sowas in einen extra Datei speichern und auf dem Datei von Main und State Machine als Header einbinden?

    Ja ... das ist nicht nur sinnvoll sondern auch gleich mit eine gute Übung, ob Du Deine Funktionen sauber voneinander getrennt und deklariert hast.

    Das teilt man i.d.R. so auf, dass logisch zusammengehörige Teile in einem Sourcefile stehen, dem man dann natürlich einen sprechenden Namen gibt: us_thread.c/us_thread.h z.B. für den Sourcecode des Ultraschall-Moduls. Im .h File finden sich dann die dem Modul zugehürigen Definitionen und die Funktionsdeklarationen. Das musst in den anderen Modulen natürlich per #include einbinden und das Object-File, das aus dem Source entsteht, dazulinken.

    Due nimmst Geany, oder? Da sollte das kein Problem sein, aber das musst Du notfalls selbst rausfinden, wie das gemacht wird, weil ich eben keine IDE verwende.

    Das Aufteilen ist zu diesem Zeitpunkt auch ganz sinnvoll, denn noch ist das Ganze leicht überschaubar.

    2.Sollte man immer bei der Funktionsabfrage den exit(1) schreiben? bzw. gibts eine andere möglichkeit die Returns abzufragen, so dass, dadurch der Code nicht so lang wird? bzw. lesbarer?

    Das exit(1) habe ich nur gemacht, weil es an dieser stelle keinen Sinn macht, dass das Programm weiterläuft. Man könnte auch return(1) schreiben ... das kommt auf's selbe raus.

    Die 1 ist nur exemplarisch ... da kannst Du einsetzen, was Du möchtest. Das ist der Return-/Exit-Code des Programms, der dann in der bash abgefragt werden kann ($?) ... wichtig ist nur, dass im Fehlerfall ein Wert ungleich 0 zurückgegeben wird, denn 0 wird als erfolgreich interpretiert.

    Du kannst natürlich das Ganze auch in if .... else ... packen, und keinen exit/return an der Stelle machen. Das ist vom Stil sauberer ...

    3. Ich habe gestern angefang, mich mit Theorie von Pointer bzw. Zeiger zu beschäftigen, denn ich sehe das ich überall gebraucht werden. Sollte ich mich mit dem Thema weiter, tiefgründig beschäftigen oder nur so ein paar Anhaltspunkte kennen?

    Auf alle Fälle imho extrem wichtig. Ich für meinen Teil liebe Pointer ...

    Du solltest da aber auf Deine Frustrations-Toleranz-Grenze achten. Pointer sind einfach nur geil ... können anfangs aber auch extrem frustrierend sein. Alles, was über einfache Parameter hinausgeht ist imho schon "höhere Kunst" ...

    Wenn es nur Frust ist, dann verliert man die Lust und es macht keinen Spass mehr. Also ... achtsam dosieren.

    Zum Rest später mehr,

    -ds-

  • Ich würde mir dann erstmal vornehmen, den o.g. Code funktionierend machen ( das der us Sensor funktioniert), danach denn Code so kurz, knackig und lesbar umschreiben ( durch weiteres Belesen und eure Hilfe), und danach das bis nun getan in verschiedene sourcefiles aufteilen und mit includes arbeiten.

    So das ich eine sinnvolles Basis Struktur für künftige Features Implementierungen habe und alles lesbar und übersichtlich für die Menschheit bleibt.

    Nicht dass ich mich überstürzte und dann wird alles nix...

    Dann hätte ich schon mal eine Basis und ein Arbeitssystem.

    Grüße aus Berlin,

    Golpe



  • Ja, aber nicht richtig durchgeguckt, denn ich versuche immer die Sachen mit meinem vorhandenes Wissen zu machen (wenn ich denke, dass dafür mein Wissen und Verständnis reicht). "Schummeln" mag ich zuerst nicht ;).

    Vielleicht sollte ich es aber machen..

    Grüße aus Berlin,

    Golpe



  • ich werde langsam irre.

    Warum funktioniert das

    und das nicht? (restlicher Code in ältere posts..) (bleibt weiterhin in der erste while schleife hängen)

    danke!

    Grüße aus Berlin,

    Golpe



  • Hi,

    hab' ich so ad hoc keine Erklärung ...

    Ich geh' aber gerade mal über den Code von Dir.

    Da hab' ich noch mal was zum Thema returncodes. Da fehlen noch einige Abfragen ...

    Due gibst zwar in z.B. setPinMode() einen Wert zurück, der ist aber immer 0 ... dann kannst Du ihn Dir auch schenken.

    Exemplarisch habe ich mir mal setPinMode() vorgenommen:

    Das könntest Du natürlich auch mit if-Abfragen machen, aber dann hast Du eine ziemlich heftige Schachtelungstiefe.

    Ich finde in solchen Fällen switch eleganter.

    Das müsste jetzt praktisch in die anderen Funktionen auch noch rein.

    Na gut, ich schau' mal weiter ...

    //EDIT: was mir grad noch einfiel ... im obigen Source ist folgende Änderung noch sinnvoll:

    Code
        int IOsSetState=0;
        
        //Sets the GPIO mode, typically input or output. 
        for( int i = 0,IOsSetState = 0; IOsSetState == 0 && i < 9; i++ )
        {

    UPDATE:

    Und noch ein EDIT:

    Du kannst Dir vielleicht ein paar Inspiratiionen von meinem Controller holen, wenn Du Lust und Zeit hast.

    -> Multithreaded "Super-Controller" für den Raspberry Pi

    bis dann,

    -ds-

  • Hi,

    ich hatte da was im Hinterkopf, dass es da wohl was gibt. Hab' ich aber nicht ausprobiert ...

    Könnte etwas einfacher zu handhaben sein, als die "normalen" pthreads ... steckt aber vermutlich nichts anderes dahinter.

    Ich würd's mir an Deiner Stelle mal anschauen ... und. wenn's einfacher und verständlicher ist, die Funktionen der Lib nehmen.

    Du hast ja schon genügend schwierigen Stoff - da kannst Du Dir das Leben auch ein bisschen einfacher machen.

    cu.

    -ds-

  • Ich belese mich auch parallel bzgl. Erstellung von Bibliotheken...

    Ich wollte anfangen langsam die funktionen aufteilen..

    Exemplarisch habe ich mir mal setPinMode() vorgenommen:

    Heute Abend habe ich mich damit beschäftigt.

    Ein Dozent meinte mal zu uns das in der Laufbedingung einer for-schleife sollten wir kein UND oder ODER reinpacken (warum weiß ich nicht mehr, ich soll ihm mal nächste Monat fragen...), aus dem Grund habe deine Verbesserung so geändert:

    so sollte es auch funktionieren oder? bzw. wären alle Fälle der Abfrage berücksichtigt?

    Grüße aus Berlin,

    Golpe



    4 Mal editiert, zuletzt von Golpe (20. August 2018 um 00:34)

  • Moin alle zusammen.

    Nach 3 Tage Kopfbrechen schreibe ich mal wieder hier.


    Ich habe erstmal alle Tipps von dreamshader unter die Lupe genommen und erstmal mich dafür entschiden das Projekt zu modulisieren.

    Erstmal nur mit einem Header, einem Quellsource und einem main Datei.

    Da die Funktion mit dem Thread nicht so gut klappt, habe ich sie erstmal auskommentiert und mich auf eine funktionierende Modalisierung konzentriert.

    Erstmal hat es gut geklappt. Dannach habe ich mich gefreut und versucht mehr Funktionen zu erzeugen, um die main Funktion übersichtlicher zu machen und die ganze Prozedur weiter zu üben.

    Obwohl (meiner Meinung nach) ich die Funktion "initOlivia()" genauso wie die andere geschrieben habe (.h und quellcode neu kompiliert-> main.c neu kompiliert und gebuildet), funktioniert sie nicht wenn ich sie im Quellcode definiere und im .h Datei sie als extern deklariere. (es kommt die Meldung " undefined reference to olivia", obwohl der Linker -lolivia doch kennt).

    Wenn ich die Deklaration in .h lasse und die Definition in main.c schreibe, dann gehts ja.

    olivia.h

    olivia.c:

    main.c:

    Vielleicht hat einer Zeit sich es anzugucken...

    Wenn ich die main.c ausführe so wie ihr den Code sieht, dann werden die erfolgreiche printf Meldungen der Funktionen setpinmode, iosInitialise, pudinitialise und initolivia auf die Konsole gezeigt, dannach wird in die main while-schleife gesprungen und die statemachine wird immer wieder aufgerufen (wie gehabt). Mich irritiert aber, dass die printf Meldungen, die ich in die Funktionen der Statemachine implementiert habe, nicht in die Konsole gezeigt werden, so wie bei setpinmode und die andere Funktionen.

    Habt ihr eine Ahnung warum das seien könnte?

    Danke!

    P.S. Ich hoffe dass ich alles deklariert habe, wo es hingehört, wenn es euch etwas auffällt, sagt bitte Bescheid

    Grüße aus Berlin,

    Golpe



  • Halli Hallo,

    da bei dem Projekt grade sich fast alles um das Programmieren dreht, habe ich hier ein extra Thread erstellt.

    Das lasse ich offen für den Projekt im allgemein bzw. für Sachen die nicht (nur) um das Programmieren geht.

    Macht das Sinn, Foren experten?! dreamshader

    In Forensache habe ich nämlich nicht viel Erfahrung...

    Grüße aus Berlin,

    Golpe



Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!