Menü
Aktuelles
Von:
Filter

Fehler beim kompilieren

D

dietmar

New member
Ich habe heute mein Board Arduino due von Sainsmart bekommen.

Ich wollte dann probehalber mal den die aktuelle Version V0.9.2.6 15.04.2014 kompilieren und draufspielen,

Leider bekomme ich sofort folgende Fehlermeldung
Code: 
Arduino: 1.5.6-r2 (Windows 8), Board: "Arduino Due (Programming Port)"

ardumower.ino:68: fatal error: EEPROM.h: No such file or directory
compilation terminated.


Für den Due gibt es die EEPROM Library nicht.

Wie soll ich am besten verfahren? Zunächst ein Mega board bestellen und den due für andere Aufgaben zurückstellen?
Oder wird sich der Aufwand und die Geduld lohnen ?
 
Hallo Dietmar,

was hälst Du davon wenn wir zusammen die Portierung vornehmen, d.h. uns die Arbeit aufteilen? Ich denke an C++ Klassen welche die Funktionalität kapseln:

Low-Level
- Klasse für Schleifenempfänger (Perimeter)
- Klasse für Lage-Sensor-Modul (IMU)
- Klasse für Roboter-Sensorik und Aktorik (Sensor) (auslesen mit digitalRead/analogRead und ablegen in Klassen-Variablen), ähnlich zur alten "Roboter-Config" (aml50.h)

High-Level
- Klasse für Roboter-Zustandsautomat und Roboter-Verhalten (FSM)

Hauptprogramm
- ADC-Einlesen und Ablegen in Queues (ADC0..7), welche von verschiedenen Klassen (Schleifenempfänger/Sensorik) ausgwertet werden
- Verwendung der "Low-Level" Objekte (Perimeter, IMU, FSM)


Das ganze könnten wir z.B. als Repository (SVN) für uns beide verfügbar machen...

Wie findest Du die Idee?

PS: Die ADC-Funktionalität habe deswegen erwähnt, da der Schleifenempfänger ständig mit hoher Frequenz darauf zugreifen muss (ADC0 mit 768 Hz), die Sensorik dazwischen aber auch. Evtl. reichen aber auch Timer in denen gesampelt wird.

Gruss,
Alexander
 
Danke für das Angebot......

Aber da ich mit dem Ardurino bisher keine Erfahrung habe, (nicht mal LED blinken) muss ich mich bei 0 einarbeiten. Ich komme aus der gaaaaanz alten Pascal Schiene, später Delphi,C-Unit von conrad, und Neuzeit hab ich ein wenig mit Visual Studio gemacht. Adurino fühlt sich ein wenig wie Back to the roots an. Das eine Programmiersprache keine event handler hat......... :(

Deshalb, lass mir bitte ein wenig Zeit bis du in meinem Projekt Thread die ersten Ergebnisse siehst.

Projekttread

Evtl. können wir ja dann Anfangen Ergebnisse zusammenzuführen.
 
Klingt doch gut - derzeit feilen wir ja noch am alten Code, wenn Du irgendwann fit bist, könnte man dann am neuen zusammenarbeiten :)
 
Hallo allerseits, hi Alexander

> was hälst Du davon wenn wir zusammen die Portierung vornehmen ...

ich würde da sicherlich mitmachen!
Allerdings sollte das vorher umfassend geplant und vor allem
dokumentiert werden. Der aktuelle Code ist in vielerlei Hinsicht
genial, aber bei abweichender Hardware ist er eben auch manchmal
sehr schwierig zu verstehen und anzupassen. Meiner Ansicht
nach sollte er so allgemein verfasst sein, dass er bei entsprechenden
Änderungen auch auf einem Raspberry o.ä. läuft.

Die Idee wäre also die Klassen noch weiter zu verfeinern - eine
Schicht für die eigentliche Funktionalität (wo bin ich, was ist
meine Aufgabe), eine darunter für den Status (Odometrie usw,
Ladezustand, Grashöhe, ...) und noch eine weitere (Treiber-)Schicht
für den Zugang zur Hardware.

Happy mowing, Heiner
 
Hallo Heiner,

gerne können wir auch zu dritt die zukünftige "ultimative" Ardumower Steuerung entwickeln. Bis dahin ist aber noch ein weiter Weg und wir sollten diesen Weg für eine gute Planung nutzen (wie Du auch schreibst). Ich würde dazu gerne auch noch in deine Software schauen, so dass man sich interessante Lösungen aus vielen Ideen zusammensuchen kann.

Ich denke so an die Winterzeit - damit alle gut mitentwickeln können, würde die Hardware beispielsweise in einer weiteren Roboter-Klasse simuliert, d.h. via Anbindung an PC oder Android würde die Aktorik/Sensorik an einen Simulator übermittelt. Einfach eine weitere Roboter-Variante, mit der die komplette Software jederzeit schnell und transparent getestet, demonstriert und ausprobiert werden kann.


Gruss,
Alexander
 
Hallo Alexander,

mit einer "Software"kann ich leider noch nicht dienen. Ich bin noch dabei
meinen Mäher zu bauen. Natürlich habe ich aber schon Test-Code zu allen
Komponenten, die bisher eingetrudelt sind. Außerdem habe ich mich intensiv
mit "maschinellem Sehen" (OpenCV) beschäftigt.

Für OpenCV braucht man einiges an Rechenleistung. Deshalb wird es auf meinem
Mäher vermutlich (auch) einen PC-artigen Rechner (z.B. Raspberry) geben.
Wäre nett, wenn man die oberen Schichten einer neuen Software trotzdem verwenden
könnte.

Deine Idee statt des Mähers einen Simulator anschließen zu können, finde ich
klasse. Das würde die Entwicklung einer intelligenten Navigation sehr vereinfachen.
Dafür müssten alle Sensorenklassen einen Simulationsmodus bieten, der Werte mit
typischen Fehlern liefert.

Liebe Grüße, Heiner
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben