RoboterCC - Robotic Code Compiler
Forum Robot Kits NIBO burger Hindernisvermeidung und Nibo blue als Datensender

Welcome

Nachrichten

Sie sind nicht eingeloggt.

Werbung

Banner

Letzte Themen

Site-Statistic

  • 7416 private projects
  • 378 public projects
  • 16172649 lines compiled
  • 58122 builds
NIBO @ facebook YouTube Twitter
Willkommen, Gast
Benutzername: Passwort: Angemeldet bleiben:
  • Seite:
  • 1

THEMA: Hindernisvermeidung und Nibo blue als Datensender

Hindernisvermeidung und Nibo blue als Datensender 4 Jahre 11 Monate her #4377

  • boson
  • bosons Avatar
  • OFFLINE
  • Senior Boarder
  • Beiträge: 38
Nibo Burger mit Hindernisvermeidung und Nibo blue als Datensender im Atmel Studio 7

Wie man den Burger in Atmel Studio 7 programmiert hat „AitanaAlmaguer“ unter diesem Link prima beschrieben. Mit ATmega16 und 15MHz

Hier habe ich eine Vorlage beschrieben und angehängt für den Burger mit ATMega1284p mit 20MHz.

Dafür müssen u.a. in Toolchain ein paar Dinge geändert werden. Da der Code von Nils Springob bedingte Programmierung einsetzt und sonst möglicherweise falsch compiliert wird. Zu anderen Abweichungen vom Originalcode komme ich später. Wer sich im Atmel Studio die Vorlage lädt braucht das nicht.


Symbols.PNG


In diesem Artikel:

www.roboter.cc/index.php?option=com_kunena&view=topic&catid=19&id=2698&Itemid=20

beschreibe ich wie man eine sicheren 20MHz Takt mit ein paar kleinen Modifikationen hinbekommt. Es ist dafür nicht der volle Umfang notwendig. Die Aufstockung und die AA Batterien kann man sich sparen, wenn es einem nur um die 20Mhz ankommt. Dann sollte man aber statt der ISP Buchse auf der Platine ein Kabel verwenden um einen Programmer anzuschließen.

-

Wieso Nibo blue beim Hindernis einsetzen?

Beim Experimentieren mit dem Burger hatte ich immer ein Problem: Wie komme ich an Sensormesswerte die der Burger gerade misst. Das Maroon Shield ist dafür nicht wirklich geeignet. Warum also nicht einfach die Daten zu einem Terminalprogramm auf dem PC senden?

Den Code im Programm von Nibo blue (Niboprot Libs) bedarf es gar nicht. Es ist vor allem ein Parser der auf Kommandos antwortet. Um über Bluetooth zum PC Daten zu senden brauchen wir nur die USART Befehle. Vielleicht um ein paar Kommandos ergänzt. Den Rest macht der Nibo blue alleine. Mit einem Bluetooth Stick am PC kann man eine Verbindung von einem Terminal Programm zum Nibo blue aufbauen. Ich mache das über Tera Term (frei erhältlich). Mein USB Stick stellt mir dabei 4 COM Verbindungen zur Verfügung. In meinem Fall (!) ist es COM14 die Baudrate ist 9600 Baud. In diesem Beispiel lese ich die Odometriedaten aus.


TeraTerm.PNG



So wie ich das hier in der main Loop mache ist es nicht nur ein Beispiel und nicht unbedingt sinnvoll, da die Übertragung zuviel Zeit braucht. Die Motor-Steuerung arbeitet mit Interrupts, die beim USART - Senden aber ausgeschaltet werden.


OdometryDaten.PNG



Eine höhere Baudrate und ein timergesteuertes Senden wäre sinnvoll. Messwerte sollten in einen Puffer geschrieben werden. Der dann Timer- Interrupt gesteuert alle 1s oder 500ms ausgegeben wird. In der übrigen Zeit kann die Motorsteuerung unbehelligt arbeiten. So weit bin ich aber noch nicht.

Eine Beschreibung meiner Abweichungen original Quellcode beschreibe ich im Nachtrag.
Anhang:
Letzte Änderung: 4 Jahre 11 Monate her von boson.
Der Administrator hat öffentliche Schreibrechte deaktiviert.

Hindernisvermeidung und Nibo blue als Datensender 4 Jahre 11 Monate her #4378

  • boson
  • bosons Avatar
  • OFFLINE
  • Senior Boarder
  • Beiträge: 38
Nachtrag:

Im Anhang desletzten Posts ist eine Vorlage für Atmel Studio 7 angefügt. Ist das Atmel Studio normal installiert, befindet sich das Vorlagenverzeichnis in: ...\Documents\Atmel Studio\Templates. Die Zip File einfach da hinein kopieren und man kann wenn man ein neues Projekt anlegt dieses auswählen:

NeuesProjekt.PNG


Ich mache hier einiges anders (das heißt nicht besser, aber es eben meine Art) Zunächst fällt auf es gibt keine Robomain nur eine main.c und eine main.h in der main.c gibt es zwar noch eine Setup aber die Loop habe ich mir geschenkt. Ich habe es für unsinnig gehalten in der robomain in einer mini int main setup und loop aufzurufen.

IntMain.PNG


Der eigentliche Unterschied ist aber die main.h. Alle Includes werden dort gemacht.

mainh.PNG


der include "Kopf" jeder C - File sieht dann so aus:

includemainh.PNG


Es muss die main.h eingebunden werden, die anderen müssen auskommentiert oder gelöscht werden.

Was soll das?

Zum einen habe ich einen Ort für alle Includes und nicht ein Wirrwarr von Includes in jeder File. Im Atmel Studio wird mir aber immer gesagt wo sich eine Funktion befindet. Über rechte Maustaste auf eine Funktion bekomme ich sofort den Ort der Implementierung im Atmel Studio heraus. Andere Entwicklungsumgebungen mögen das nicht liefern:


GotoImplementation.PNG



Manchem wird auffallen, dass ich viel mehr Libraris eingebunden habe als für das Projekt nötig. Zum Beispiel die niboprot. Sie wird für das Senden wie gesagt nicht benötigt. Das ist aber kein Nachteil. Im Code sorgt der Compiler letztlich dafür, dass nur der verwendete Code im Ergebnis landet. Trotzdem habe ich jederzeit die Möglichkeit auf im Projekt schon mal programmierte Routinen zuzugreifen.

Ich will hier nur meinen Aufbau erklären, Andere haben sicher Gründe es anders zu machen...

Gruß Boson
Letzte Änderung: 4 Jahre 11 Monate her von boson.
Der Administrator hat öffentliche Schreibrechte deaktiviert.
  • Seite:
  • 1
Ladezeit der Seite: 0.049 Sekunden

Werbung