- 12V Akku mit 280 Ah bauen         
Seite 4 von 4 ErsteErste ... 234
Ergebnis 31 bis 38 von 38

Thema: Vorgehensweise für Programmaufbau?

  1. #31
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.653
    Anzeige

    LiFePo4 Akku selber bauen - Video
    Danke Bessewessi!

    Das bedeutet wohl, dass in diesem Code
    (((ADDRESS) & (1<<BIT))?1:0)
    die IF ... Then ... Else Lösung ziemlich überflüssig ist, oder verstehe ich das falsch? Wenn ((ADDRESS) & (1<<BIT)) falsch ist - dann ist es doch Null - bekommt aber trotzdem die Null von ?1:0 - und wenn es richtig ist - also 1 - dann bekommt es doch überflüssigerweise die 1 von ?1:0.
    Ich fürchte, das verstehe ich noch nicht.

    Bleibt noch die Frage offen nach der Bedeutung des "((!(..."
    Ciao sagt der JoeamBerg

  2. #32
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    20.08.2008
    Ort
    Karlsruhe
    Alter
    36
    Beiträge
    1.225
    Richtig, das erste der beiden Makros begrenzt den Wert des "herausfallenden" Wahrheitswertes einfach nur auf die Werte 1 bzw. 0.
    Wenn beim Zweiten das Ausrufezeichen ein Zeichen weiter links stehen würde, würde das ganze für mich Sinn ergeben, so kann ich nicht viel damit anfangen ...
    In diesem Falle würde es übrigens ein bestimmtes Bit ausmaskieren/löschen.

    mfG
    Markus

  3. #33
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    20.07.2006
    Alter
    43
    Beiträge
    2.474
    Das ist peinlich, der Thread ist bei mir total untergegangen, danke für die Antworten, wird hilft mir schon ungemein

  4. #34
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.653
    Hallo,

    die hübschen Makro-Codeschnippsel von askazo gibts hier auch (klick). Damit will ich keinesfalls etwas gegen seine Kreativität sagen, im Gegenteil. Mittlerweile verwende ich askazos Makros recht häufig - danke askazo!
    Ciao sagt der JoeamBerg

  5. #35
    Hallo,

    eine Software solle (muss aber nicht) von der Struktur her in Schichten unterteilt sein.
    Jede dieser Schichten greift auf die darunterliegende zu, "weiss" aber nichts von der darüberliegenden. In C manfistiert sich das daraus, das "übergeordnete" Schichten immer nur Header (.h) Files von untergeordneten oder soche aus der eigenen Schicht inkludieren.

    Es hilft ungemein, wenn man die Source-Dateien diese Schichten in eigene Verzeichnisse packt. So sieht man an den Pfadnamen gleich, wenn eine Schicht auf eine andere zugreift.

    Ein Vorschlag aus der Business Entwicklung wäre, folgenden Schichtenaufbau zu verwenden (von "unten" nach "oben"):
    • Access: Zugriff auf die Hardware (und, streng genommen, auch auf den dynamischen Speicher, da dieser die "Datenbank" des Roboters ist). Also alles was Actoren und Sensoren betrifft.

    • Service: Logik der Steuerung, also Funktionen die "Highlevel" ablaufen sollen, wie "fahre eine x cm geradeaus", "fahre eine Kurve mit einem Radius von x cm und y Grad", "folge x cm einer Wand", usw. Dabei werden Funktionen der Acess-Schicht aufgerufen.

    • Controller: Darüberliegende "Intelligenz" die, Aufgrund der Service-Schicht, Aktionen ausführt. Diese können sein: "Fahre Aufgrund einen abgelegten Pfades zu dem Punkt XY im Raum", "Weiche einem Hindernis mit den folgenden Aktionen aus", usw.


    Dieses, recht einfache Modell, kommt aus der Entwicklung von Dialog geführten Anwendungsprogrammen und geht davon aus, das auf eine bestimmte Eingabe ein bestimmtes Ergebnis berechenbar ist. Wenn die Eingabe fehlerhaft ist, tritt ein "Fehler" auf, auf den die Software entsprechend reagiert und dies zurückmeldet.

    In der Robotik treten allerdings zum einen recht komplexe Eingaben auf, da zum einen die Sensoren nie die immer gleichen Egebnisse liefern (Messfehler, Ansteuerungsfehler, ...), zum anderen unvorhergesehende Ereignisse auftreten (Hindernisse, unbekanntes Retrain, ...). Hier hilft es, anlehnen an der Biologie zu nehmen und seinen Roboter mit einer weietren Schicht auszustatten, den "Verhaltensweisen" (Behaviours).
    Diese sitzen auf einer weiteren Schicht zwischen den Services und dem Controller und fahren eine bestimmte Verhaltenweise ab, bis diese von einer anderen unterrochen, oder "überlagert" wird. Diese werden in einer bestimmten Priorität abgearbeitet, die sich, gesteuert durch den Controller, ändern kann.

    Beispiel: Eine Fliege ist "schwanger" und sucht einen Platz, um ihre Eier abzuladen. Deshalb fiegt diese Fliege zu einem herrlich duftendem Kothaufen. Wenn ich nun zwischendurch mit meiner Hand nach ihr schlagen, wird dem Hinderniss durch bestimmte Verhaltenweisen ausweichen, ohne ihr eigentliches "Meta"-Ziel aus den Rezeptoren zu lassen - den Scheißehaufen zu finden. Der Controller stuert nur, das dem übergeordetem Ziel folgt. Wird sie durch das Ausweichmanöver von den Düften des einen, superfrischen Kothaufens abgelenkt, folgt sie evetuell einem anderen Duft, der meines super abgelagerten Steaks, das ich gerade grillen will.

    Na ja, usw., weitere Schichten sind denkbar und evtl. auch sinnvoll. Weiteres in dem Thread zu, Meta-Controller, in dem ich dieses gerade einem Rp6 beizubrigen Versuche https://www.roboternetz.de/phpBB2/vi...c.php?p=478404

    Ein weiteres Stichwort sind "Zustandsautomaten", wie in dem Examples zum RP6 (Example_05_Move_05) gezeigt, auf denen mein Versuch aufsetzt. Zustandsautomaten sind eine Technik der Softwareentwicklung in der davon ausgegangen wirde, das das Verhalten einer "Schicht" immer von dem Zustand (im Idealfall einer Variablen) abhängt. Eine Änderung des Zustandes hängt immer von dem vorherigen und sonstigen Einflüssen ab.

    Damit kommen wir zu den Techniken in der Softwareentwicklung zurück, mit der sich die Schichten trennen lassen. Wenn sich in einer "Unteren" Schicht ein Zustand ändert, an dem eine "obere" unmittelbar interessiert ist, kann sie dies durch ein "Callback"-Interface einem "Listener" mitteilen. Wenn diese nicht unmittelbar davon Erfahren müssen (also zeitgleich), reicht es, wenn sie die Schicht mit einem Getter (getXY()) beobachten.

    Realisiert wird das durch eine Programm-Schleife in der oberen Schicht, die regelmässig die run()-Funktionen der unteren Schicht (und so weiter) aufruft. Ideal wäre hier natürlich Multitasking, aber jetzt träume ich zu sehr....

    Grüße,
    smk

  6. #36
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    20.07.2006
    Alter
    43
    Beiträge
    2.474
    Hey @ all , hab gar keine Mail bekommen, dass wieder geantwortet wurde

    Vielen Dank für eure ausführliche Beschreibung bzw. Erklärung \/

    Ich hoffe, dass ich mich beizeiten mal wieder mit der Materie beschäftigen kann, irgendwie kommt es immer anders.

    Gruss copi

  7. #37
    Hi,

    schön wenn is irgendwie hilfreich ist, ich bin mal wieder in's schwafeln geraten, sorry

    Bei mir hat die Benachrichtigung funktioniert,
    Gruß, smk

  8. #38
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    20.07.2006
    Alter
    43
    Beiträge
    2.474
    Zitat Zitat von schmiereck
    Hi,

    schön wenn is irgendwie hilfreich ist, ich bin mal wieder in's schwafeln geraten, sorry

    Bei mir hat die Benachrichtigung funktioniert,
    Gruß, smk
    Find ich nicht schlimm, eher von Vorteil, dem kann man jedenfalls noch folgen \/
    Bei mir / uns steht die nächste Zeit einiges an, dass ich einfach keine Zeit finde, mich intensiv weiter mit Programmierung beschäftigen kann, danach hoffe ich dann aber doch

Seite 4 von 4 ErsteErste ... 234

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

12V Akku bauen