@marvin42x
WOW, das ist mal ein geniales Teil! Soweit meine Englischkenntnisse reichen (... und die reichen nicht besonders weit) hat dieses Platinchen ja alles drauf, was man zur Neigungsmessung braucht. Kann man das Teil auch programmieren? Ob ich das was für meine Zwecke wohl auch benutzen könnte?
@PicNick
werde mal deinen Ratschlag befolgen und das PDF File zum Board durcharbeiten. Da steht ja auch was drin zum Thema "Trockentest". Und deine Worte "'Wenn du meinst, Du stehst dicht am Abgrund, vergiß nicht, wir stehen alle dicht hinter dir, um Dich voranzutreiben" sind seeeeehr beruhigend für mich
@sigo
Geschwindigkeitsermittlung wäre kein grösseres Problem, wenn der Bedarf hierzu da wäre. Hab ja eh das Gefühl, das die Maschine "ruhiger" wird, je schneller man fährt.
Grüssle
Jürgen
PS: die Einstellungen (im Roboternetz/wissen) der BASCOM-AVR Options unter dem Reiter "Programmer": gelten die auch bei Verwendung eines ISP-Programmierkabels in Verbindung mit USB Adapter? Oder gibt es da noch Besonderheiten zu beachten?
Wenn es so ist, wie vorgeschlagen, ist der ISP-Adapter für den LPT1:
Da läuft es genau wie in der Doku, keine Extrawürste.
Der USB adapter ist "nur" für die Datenübermittlung µC <> PC
(also z.B. für "Hello, world"
EDIT: Alle Varianten von Gyro sind eher was für Step II, wenn wir also mit dem Nicken schon gute Freunde sind.
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Genau, keine Extrawürste, hier wird jeder (über die Klippe) geholfen
Aber im ernst, den angesprochen Sensor sollte man sich erst in Stufe drei antun. Der muss von einem Controller ausgelesen und ausgewertet werden. Allein macht der nix. So habe ich es jedenfalls verstanden.
Ich hab den nur mal so ins Spielfeld gerollt, kann ja sein das der Mal funktionstüchtig realisiert wird *scheinheilig guck*.
Das könnte ich in meinem Projekt auch gut gebrauchen.
Netter Gruß
Und haltet den PicNick nicht von der Arbeit ab, der hat zu tun
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
*grmpff*... haltet den PicNick nicht von der Arbeit ab,..
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Nicht ärgern lassen
Ignorieren.
Hab selber bis über beide Ohren zu Tun.
Netter Gruß
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
richtig..Um den µC zu versorgen (Code aufspielen) schliesse ich das ISP Kabel an den LPT1 an.
Aber dann isses falsch.
Wenn das Programm draufgespielt ist , läuft es sofort los, da ist nix mit umstecken.
Auf den USB-Adapter gehört das RS232 Kabel (Zubehör).
ein kleiner 3-er Stecker auf's Board, sub D 9-Polig in den USB-Adapter
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Hi Jürgen,
ich habe eben in der c´t 2006, Heft 19, S.22 gelesen
Es geht dort um den FIRA RoboWorld Cup 2006.
Dort wird u.a. über den Roboter Manus berichtet, einen humanoiden Roboter..
Da steht u.a.:
"...Der Roboter gleiche Unebenheiten durch Reaktion auf einen Beschleunigungssensor in Hüfthöhe aus, ....zeigte ein Video, in dem Manus auf einem Hocker stand, der langsam gekippt wurde. Dabei glich der Roboter die Schräglage sowohl zur Seite als auch noch hinten und vorn sicher aus..."
Ein Beschleunigungssensor hätte den ungemeinen Vorteil, dass er in den Scheinwerfer passen würde. Evtl. wäre eine Kombination mit dem Tacho sinnvoll, dann hätte man die Beschleunigung/Verzögerung der Maschine, man kennt die Erdbeschleunigung, und könnte evtl. dann die restlichen Komponenten als Nicken und/oder Schräglage interpretieren.
Mit geeignetet Filterung könnte ich mir vorstellen.
Ob man noch ein Gyro braucht, ist dann die Frage. Das würde natürlich die Schräglage direkter messen..und man würde es mit o.g. Sensoren regelmäßig abgleichen.
Alles würde jedenfalls vollelektronisch sein und in die Lampe passen..
Sigo
Sodele, kam heute mal dazu, ein bisschen zu testen. Und siehe da: kaum fängt man an, treten schon die ersten Probleme auf.
Ich bin mal so vorgegangen, wie es unter Robotikhardware beschrieben ist:
- UMOT, UREF, UMESS geprüft, ob Jumper gesteckt sind
- Netzteil mit 9 Volt angeschlossen
- ISP Programmieradapter an LPT1 angeschlossen
Configuration von Bascom AVR
- Programmer STK200/STK300 gewählt
- Chip M16 gewählt (ist doch aber eigentlich ein M32 oder?)
- rncontroltest.bas kompiliert
- run Programmer - Program
und hier taucht jetzt die Fehlermeldung auf:
"Selected chip and target chip do not match M32 <> M16"
Ich habe dann zwischen M16 und M32 in der Konfiguration gewechselt, nochmals kompiliert, run Programmer - immer die gleiche Fehlermeldung.
Was soll ich tun? Achja: LED7 und LED8 brennen und das Teil hupt 2x.
Grüssle
Jürgen
Die Fehlermeldung gibt der Bascom Programmer typischerweise aus wenn er den Mega auf der anderen Seite nicht sieht.
Normalerweise erscheint der Controllertyp im Programmerfenster wenn er ihn sieht.
Den Controllertyp kannst Du schon im Programmtext angeben:
$regfile = "m32def.dat"
$crystal = 8000000
schreibst Du ganz oben hin
crystal sollte aber bei Dir auf 16000000 stehen.
Ich meine das RN-Kontroll hat einen Mega32 mit 16000000 Hz
Steht auf dem Quarz gleich neben dem Mega32.
Ich weis jetzt nicht, was als Anfangsprogramm auf dem RN-Kontroll drauf ist.
Wenn das so richtig ist mit den Led und dem Hupen kann man glauben der Mega arbeitet.
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
Berechtigungen
Zitieren
Lesezeichen