Ich habs grad noch einmal unter Hardy ausprobiert und es hat überraschenderweise auf einmal doch geklappt. Ich musste nur noch ein sudo vorranstellen. Anscheinend schreibt sich das Programm nun automatisch sogar in /usr/local/bin.
Ich werde das Wiki dahingehend noch ergänzen, aber vielleicht kann das jemand andereres noch ausprobieren, um sicher zu gehen, dass das auch wirklich bei jedem funktioniert.

mfg Ubuntuxer

Ist der Artikel im statischen Wiki nicht vorhanden?

Der Link ASURO ist tot.

Edit: Ok habs gelesen… keine Baustellenartikel.

@Ubuntuxer: auf meinem Ubuntu 7.10 funktioniert der USB-Tranceiver immer noch nicht ohne manuelle Änderungen.

Gruß,
obstriegel

Was musst du denn manuell ändern ? Was funktioniert nicht ? Bei mir ging der USB-Transceiver nach unserer Anleitung unter 7.10. Ich werde mir den ASURO jetzt auch mal unter 8.04 installieren schauen ob sich was geändert hat.
mfg Daniel

Kann einer der Moderatoren den Artikel bitte aus der Baustelle verschieben.
Ich hab mich mit tuxfreak abgesprochen und wir sind der Meinung das der Arikel fertig ist.

Hallo,

habe ein paar Korrekturen gemacht.

Nach dem Lesen des Artikels stellt sich die Frage, ob der Artikel wegen der ganze Installiererei eine „Fortgeschritten“-Box gekommen sollte…

Gruß, noisefloor

Ich denke das ist nicht nötig, da man schließlich nur die aufgeführten Befehle für die Installation abtippen muss.
Aber du kannst das durch deine Ehrfahrung bestimmt besser beurteilen.

Hab‘s jetzt nach ASURO verschoben und unter Hardware (Sonstiges) verlinkt. Vielen Dank für eure Mitarbeit!
(wir heute Nacht erst ins statische Wiki kopiert)

Hi,

Danke an die Autoren für den Artikel, ich hab schon seit 3 Jahren genau so einen Roboter! Bei mir funktioniert nur das neue Flash-Tool (V. 1.6.2) nicht mit ubuntu, bei Win XP in Virtualbox mit USB-Transceiver funktioniert es schon...

Ich hatte einige Probleme mit der Compilerinstallation, bis ich bemerkt habe, dass die Installation von avr-binutils/avr-gcc mit bereits installierten alten Versionen (binutils-avr/gcc-avr) nicht funktioniert, weil die Paketbezeichnungen umgedreht sind (binutils-avr -> avr-binutils) und die Pakete daher nicht einfach ersetzt werden. Ich hab jetzt im Wiki-Artikel dazu einen kleinen Absatz geschrieben...

Gruß, flo

Hallo,

wenn jetzt dafür stimmt ist das ja ok.

Gruß, noisefloor

Hallo liebe Leute,

ich habe den Artikel auf 9.10 getestet, es funktioniert bei mir bisher alles einwandfrei. Ich habe es praktisch 1:1 wie im Beitrag beschrieben, gemacht. Dann habe ich mir, weil ich es einfach praktischer finde, ein kleines Skript erstellt, es erstellt die hex-Datei, überträgt sie auf den Asuro und räumt hinterher wieder komplett auf. Nach jedem Schritt muss man jedoch [ENTER] drücken, damit es weitergeht, praktisch als Zeichen: Es hat geklappt. Natürlich vorher ausführbar machen. Ich habe es unter dem Namen "flash" abgespeichert. Es ist also so etwas wie die Flash.exe unter Windows, nur dass das Skript vorher die hex-Datei erstellt und hinterher wieder aufräumt. Zumindest in dem Ordner, in dem das Ding liegt.

#! /bin/bash
make 
read
asuroflash /dev/ttyUSB0 test.hex
read 
make clean

"[...]/dev/ttyUSB0 test.hex[...]" muss man ggf. ändern, wenn man hier (ASURO) etwas anderes erfahren hat. Ich benutze nur die USB-Übertragung, da die doch recht flott geht. Vorraussetzung ist auch, dass die hex-Datei, und somit auch die c-Datei den Namen "test" trägt. Andernfalls einfach ändern, dann jedoch nicht vergessen, das auch im makefile zu korrigieren. Ich habe bei mir für die einzelnen Sachen Ordner angelegt, die Ordner tragen den Namen der Projekte, nur die c-Datei heisst immer "test". Natürlich alles eine Frage des Geschmacks.

Noch Fragen? Ich häng einfach mal einen gezippten Ordner dran, damit ihr euch was darunter vorstellen könnt, wie ich das meine. Das Skript liegt einfach mit im Ordner.

Gruß, Zeitschlag

Hallo !

Ich habe mir nun auch mal einen Asuro geleistet und habe ein ganz komisches Problem. Unter Windows XP bekomme ich den USB Adapter nur zum laufen wenn ich die CPU kuenstlich belaste ( kilcpu ). Aber dann funktioniert das Flashen sehr gut. Doch Unter Ubuntu 10.04 habe ich ihn bisher nur wenige male zum laufen bekommen mit Asuroflash. Ich kann mir nicht erklaeren warum es selten funktioniert und meistens ein Timeout kommt. Es hat weder mit Neustart, noch mit anderen USB Geraeten, noch mit der Entfernung zum Sender zu tun. Sogar die gruene LED am USB Empfaenger geht an, wenn ich den Asuro an mache. Aber nichts passiert beim Programm. Unter Linux die CPU kuenstliche mit pi Berechnung zu erhoehen brachte kein Ergebnis. Hat jemand Rat ?

mfg

baud

CPU Überlastung könnte vielleicht klappen, ist aber 1. nicht sehr zuverlässig (habs selbst mit Fakultät auf KCalc probiert) und 2. macht man/frau sowas nicht (von wegen CO2 Ausstoß und so).

besser gehts mit der Konfigurationsdatei von Asuroflash. Diese befindet sich im Home Verzeichnis im versteckten .config Ordner und kann mit

gedit ~/.config/asuroflash &

editiert werden.

Bei mir funktioniert das Flashen mit folgenden Einstellungen:

connect_timeout = 10
flash_timeout = 7
flash_retry = 10
...

Den flash_timeout habe ich auf 7 (von 5) erhöht. Wobei der flash_timeout nicht höher als der connect_timeout eingestellt werden darf (hab ich irgendwo gelesen). Den flash_retry auf 10 (von 5)

Liebe Grüße Frank

PS: evtl. wäre das was für den Flash Teil im Wiki?

fgross2 schrieb:

PS: evtl. wäre das was für den Flash Teil im Wiki?

Auf jeden Fall! bei mir hat das Flashen unter Linux auch nicht funktioniert...

Heute habe ich versucht, dem Asuro das Fahren beizubringen. Dabei bin ich gleich nach Eingabe des folgenden Programmes auf ein Problem gestoßen:

#include "asuro.h"

int main(void)
{	
        unsigned int i;
	unsigned char j;
	unsigned int speed;

	Init();

	FrontLED(ON);
	StatusLED(GREEN); 

	MotorDir(FWD,FWD);
	for (speed = 0; speed < 0xFF; speed ++) {
		for (i = 0; i < 0x1FFF; i++)
			for (j = 0; j < 0x1F; j++); 
		MotorSpeed(speed,speed);
	}
	FrontLED(OFF); 
	StatusLED(RED); 

	MotorSpeed(0,0);

	while(1);
	return 0;
}

Front- und Status LED tun das Gewünschte. Man spürt ein kurzes Zucken. Die Motoren laufen aber nicht an. Interessanterweise fährt der Asuro, wenn man/frau den letzten

1

MotorSpeed(0,0);

Funktionsaufruf auskommentiert.

Da ich den Code zur Motoransteuerung aus dem test.c Programmcode (

1

MotorTestBoth()

) von der CD rauskopiert hatte, habe ich den SelfTest neu kompiliert. Und siehe da: Ich habe den gleichen Fehler. Die mitgeliefert SelfTest.hex funktioniert dagegen einwandfrei. Irgendwie scheint es also was mit dem Crosscompiler zu tun zu haben.

Hilfe! Wer hat eine Idee oder hat sowas schon durchgemacht?

Liebe Grüße Frank

fgross2 schrieb:

Die Motoren laufen aber nicht an.

Habe es nicht getestet, aber ich würde es mal mit einer sleep Funktion testen bzw. in einer Schleife, so 3 sekunden Fahren, dann 5 sekunden nicht usw... Kann halt sein, dass der µC (mikrocontroller) zu schnell ist, dass deine Schleife

1
2

for (i = 0; i < 0x1FFF; i++)
	for (j = 0; j < 0x1F; j++);

irgendetwas bringen würde. Musst aber auf den sleep-Parameter achten, also erst Mal ausrechnen

Viel Erfolg!