Hallo
Im Rahmen einer Abschlussarbeit in der Schule bauen wir einen Roboter,
der selbsständig einen Tisch reinigen soll.
Das Ganze wird mit einem ATMEGA8L (myAVR) gesteuert. Der Roboter erkennt
den Tischrand und Gegenstände automatisch und weicht ihnen aus.
Leider stehen wir bei der Programmierung an, da wir noch nie einen
Microcontroller programmiert haben und uns die Lehrer auch nicht
weiterhelfen können.
Ich wollte fragen, ob hier eventuell einer Lust und Zeit hätte uns Teile
des Programms zu schreiben. Wir sind für jede Hilfe dankbar.
Für nähere Infos bitte melden unter: moritz.spiess@gmx.net
Im Anhang befindet sich der ungefähre Ablauf des Programms.
Mit freundliche Grüssen
Moritz
Hilfe von extern ist erlaubt! Es soll sich ja auch um ein Projekt
handeln, wie man es bei der Arbeit antreffen kann. Dort kann man auch
nicht alles alleine machen.
In so einem Projekt, wie man es bei der Arbeit antreffen kann wird der
Programmierer das Pflichtenheft durchlesen und seinen Preis nennen,
Könnt Ihr Den auch bezahlen? Soll ja schliesslich ein realistisches
Projekt werden! Ich glaub kaum das Jemand seine Zeit dafür umsonst
opfern wird einigen Faulis ein Projekt zu programmieren.
bye
Frank
>Im Rahmen einer Abschlussarbeit in der Schule bauen wir einen Roboter,>der selbsständig einen Tisch reinigen soll.
Warum nicht.
>Leider stehen wir bei der Programmierung an, da wir noch nie einen>Microcontroller programmiert haben und uns die Lehrer auch nicht>weiterhelfen können.
Jetzt wirds vollkommen unglaubwürdig.
jack wrote:
>>Im Rahmen einer Abschlussarbeit in der Schule bauen wir einen Roboter,>>der selbsständig einen Tisch reinigen soll.>> Warum nicht.>>>Leider stehen wir bei der Programmierung an, da wir noch nie einen>>Microcontroller programmiert haben und uns die Lehrer auch nicht>>weiterhelfen können.>> Jetzt wirds vollkommen unglaubwürdig.
ist leider so. ich erlenne den beruf automatiker und die haben
normalerweise nicht viel mit mikrocontrollen am hut. desshalb haben auch
die lehrer keinen plan.
kann man sich das ganze in 2 wochen aneignen?
Naja, man könnte ja mal wenigstens kurz die Anleitung lesen. Soweit ich
das gesehen habe, hat das Teil UML Unterstützung und man kann so nen
Plan direkt eingeben....
Hallo,
nur mal so als Anmerkung:
ein üblicher µC kann nur eine Sache zur gleichen Zeit erledigen.
Ein Ablauf, der sich z.B. nach "Einschalten" in 3 parallele Zweige
teilt, kann nicht programmiert werden.
Er kann den Kram nur nacheiander erledigen und an einer Bedingung
verzweigen.
"Kante erreicht" wäre solch eine Bedingung. Da kann nur "ja" (also drauf
reagieren) und "nein" (also weitermachen, womit???) folgen.
Gruß aus Berlin
Michael
Michael U. wrote:
> Hallo,>> nur mal so als Anmerkung:> ein üblicher µC kann nur eine Sache zur gleichen Zeit erledigen.>
Naja vielleicht verwenden sie einen Dual-Core-DSP... BF561 z.B.
> Ein Ablauf, der sich z.B. nach "Einschalten" in 3 parallele Zweige> teilt, kann nicht programmiert werden.
Mit Betriebssystem würd ich das Diagramm durchgehen lassen, obwohl es in
diesem Fall auch nicht parallel abgearbeitet werden würde...
Was ist ein Automatiker? So etwas wie Automatisierungstechniker?
Michael U. wrote:
> nur mal so als Anmerkung:> ein üblicher µC kann nur eine Sache zur gleichen Zeit erledigen.>> Ein Ablauf, der sich z.B. nach "Einschalten" in 3 parallele Zweige> teilt, kann nicht programmiert werden.
Das ist überhaupt kein Problem.
Man kann ja mehrere FSM's nacheinander durchlaufen. Wenn ein
Gesamt-Durchgang durch alle FSM's im Millisekunden-Bereich ist,
erscheint das immer noch als "gleichzeitig" aus Sicht des Roboters.
Es muss nur definiert werden, innerhalb welcher Zeit welche Aktionen
durchgeführt werden müssen. -> Realtime-Anforderung.
Auch ein normaler PC mit 1-Kern Prozessor tut nichts "gleichzeitig", das
erscheint nur so, weil es schnell genug nacheinander gemacht wird.
Ich nehme an Michael ist es nur darum gegangen, dass das Diagramm
falsche Eindrücke vermittelt, die zu flaschen Schlussfolgerungen führen
können.
Auch wenn die Abarbeitung der einzelnen Funktionen im
Millisekunden-Bereich erfolgt, werden Funktionen sequentiell ausgeführt.
Dies sollte natürlich auch im Diagramm ersichtlich sein, ansonsten hätte
ein Diagramm absolut keine Aussagekraft.
Kann es sein, dass das ganze "leicht" aufwaendig ist? Sollt Ihr den
kompletten Roboter mit Peripherie und allem drum und dran bauen?! Schau
Dir mal den c't-Bot an (www.segor.de).
Ausserdem: Wenn man das Ablaufdiagramm als nichtdeterministischen
Automaten betrachtet, kann man diesen auch in einen Deterministischen
umwandeln => Der Automat hat dann keine multiplen Instanzen mehr und
befindet sich immer nur in einem Zustand. Davon abgesehen, das muss man
nur richtig programmieren, auch Interrupts und Timer usw. nutzen dann
ist das alles kein Problem. Gewusst wie.
Condi wrote:
> Naja, man könnte ja mal wenigstens kurz die Anleitung lesen. Soweit ich> das gesehen habe, hat das Teil UML Unterstützung und man kann so nen> Plan direkt eingeben....
kann mir jemand vielleicht ein gutes freeware uml programm empfehlen?
Hy Mortiz,
schau Dir mal ArgoUML an. Der "Hit" isses nicht aber es ist eigentlich
recht brauchbar.
Kannst Dich ja mal melden wenn Du willst: ICQ 307682079. Kann Dir ja ein
paar Anregungen geben.
lg,
Michael
Hallo Moritz.
Was habt ihr denn für Peripherie dran?
Sensoren (optisch, mechanische) ?
Wäre wichtig, da die entsprechend ausgewertet werden müssen. Erst nach
einer Auswertung kann eine Aktion folgen.
Hallo,
@Rooney Bob: genau darum ging es mir. Gerade ein Einsteiger sollte sich
über solche Dinge klarwerden und einen machbaren Ablaufplan
zusammenbasteln.
Gruß aus Berlin
Michael
Was habt ihr denn in der Ausbildung gelernt, wie ihr bei einem solchen
Problem vorgehen solltet?
Dass ihr ein Ablaufdiagramm habt ist ja schonmal die halbe Miete. Das
Serialisieren der parallelen Prozesse könnt ihr erreichen, indem ihr
einfach versuch ein Struktogramm daraus zu zeichnen oder das ganze in
Pseudocode umformuliert - ich nehme mal stark an, dass ihr in der
Richtung schonmal was gemacht habt.
Der Pseudocode muss dann eigentlich nur noch in eine µC-kompatible
Sprache eurer Wahl (BASCOM, C, AVR-Assembler) übersetzt werden und
fertig ist.
Gibt es den Roboter schon? Wie ist die Beschaltung der I/Os? Welche
Sensoren verwendet ihr? Habt ihr alle Datenblätter der Sensoren
vorliegen und wisst, wie die Kommunikation ablaufen soll? Habt ihr alle
Entwicklerwerkzeuge da?
Ich denke schon, dass dieser einfache Ablauf (sofern er denn stimmt)
innerhalb von 2 Wochen zu schaffen ist, wenn euer Problem nur darin
besteht euer Gedankengut in einen Controller zu schrumfen, aber sonst
alles schon geht.
Beschreib mal genauer, wo das eigentliche Problem ist. Fertigen Code
schreibt euch hier keiner (wie du sicherlich schon rauslesen konntest).
Aber helfen werden euch viele wenn man sieht, dass ihr euch bemüht und
klar fomulieren könnt, woran es mangelt.
Gruß
Kai
Ach ja:
>kann mir jemand vielleicht ein gutes freeware uml programm empfehlen?
- ArgoUML
- StarUML
- Poseidon (von Gentleware)
- MS-Visio mit MSDNAA-Lizenz (müsst ihr eure Schule fragen)
Sollte alles für eure Zwecke reichen.
Poseidon hat eine Personal Edition und wäre meine eheste Empfehlung.
Da die Implementierung allerdings nicht objektorientiert sondern eher
prozedural erfolgt, empfehle ich nach der strukturierten Analyse
vorzugehen - es sei denn, ihr findet Entwickler-Tools, die die
Transformation für die Zielarchitektur hinbekommen. Daher mein Tipp auf
ein Struktogramm auszuweichen.
Naja, seid mal nicht zu optimistisch. Klar ist ein Ablaufplan schon mal
etwas. Aber wer noch nie programmiert hat, geschweige denn auf einem
Mikrocontroller - der wird allergrösste Mühe haben, dieses Schema
umzusetzen und zu debuggen.
Also Leute, es gibt nichts anderes als sich beinhart in die Materie
reinknien. Bastelt euch ein Demoboard und einen ISP, holt euch ne
passende IDE (z.B. AVRStudio) und dann los. Wenn ihr noch nicht
programmieren könnt, würde ich mal sämtliche Wochenenden bis Mitte
Sommer für die einplanenen, wenn ihr den Roboter so wirklich durchziehen
wollt, noch etwas mehr.
Entweder knallhart reinknien, Projekt massiv redimensionieren oder aber
gnadenlos scheitern.