Vorstellung eines aktuellen kleinen Weihnachtsurlaub Projekts (ab 22.12.)
Vorstellung eines aktuellen kleinen Weihnachtsurlaub Projekts.
Ich habe zwar schon ein paar Roboter mit jugendlichen gebaut, aber die Altersklasse für dieses Projektes ist neu für mich.
Die Herausvorderung ist:
begrenzter Fachwortschatz, Lese- und Schreibanfänger, kein Englisch.
Bisher nur Rechenregeln für Addition und Subtraktion bekannt (wegen ohmschen Gesetz etc.)
Noch keine schulischen Physikvorkenntnisse.
Also ist eine ganz andere Herangehensweise notwendig wie bei Acht- bis Zehntklässlern.
Momentan laufen die Vorbereitungen.
Um einen aktuellen Controller zu nehmen und nicht mit Assembler anzufangen, habe ich zwei Arduino Nano Clones und etwas Beiwerk (Sensoren und Motortreiber) besorgt und bin seit dem 4.12. da dran.
Erstes Fazit: die Arduino Refernz von der Webseite scheint unvollständig zu sein (Oder ich bin wiederholt Blind gewesen) Auf jeden Fall habe ich nur millis() gefunden, das es micros() gibt habe ich dann so ergoogelt.
Mein Großneffe (7 Jahre) interessiert sich seit neustem für Roboter (Aufräumen, Putzen, Geschirrspülen, Hausaufgaben machen und Treppensteigen soll er können).
Zu Nikolaus gab es den "Galileo - mein Roboter".
Das Ding hat zwei Motoren, zwei LEDs, sechs Taster und einen Einschalter.
Programmiert wird über die Taster.
Es gibt Programmiermodus an-aus, vor, zurück, links, rechts und Programm start.
Daß dad natürlich kein richtiger Roboter ist, sondern eher ein Automat mit einer Schrittkettensteuerung ist klar.
Die Motoren werden ohne Odometrie nur über einen Timer gesteuert. Somit sind dann die Schwenks auch nicht genau 90°,
sondern beim einen Motor über 100° und beim anderen grob 90°
Also kleines Projekt für den Einstieg in "richtige" Robotik:
(Vorgabe meiner Finazministerin: es darf "nichts" {wenig} kosten, damit scheidet Mindstorm aus obwohl schon genug LEGO vorhanden ist)
Als Exkurs habe ich erst mal ein Beispiel vorgesehen das ihm bekannt ist.
Da vor der Schule eine Fußgängerampel steht, also erst mal eine Ampelschaltung mit einem Arduino nano und als Erweiterung einen LDR für eine Nachtschaltung (Gelb für die Autos blinkt).
Mit dem LDR lernt er einen Sensor kennen, der eine Reaktion auf verschiedene äußere Einflüsse ermöglicht.
Schnell gestricktes Programm, schon mit dem LDR und bewust mit delay Befehlen.
Code:
int f_tast = 2;
int a_rot = 3;
int a_gelb = 4;
int a_gruen = 5;
int f_rot = 8;
int f_gruen = 9;
int f_lamp_tast = 13;
int s_licht = A0;
void setup() {
pinMode(f_tast, INPUT);
pinMode(a_rot, OUTPUT);
pinMode(a_gelb, OUTPUT);
pinMode(a_gruen, OUTPUT);
pinMode(f_rot, OUTPUT);
pinMode(f_gruen, OUTPUT);
}
void loop() {
int sensorValue = analogRead(s_licht);
digitalWrite(f_lamp_tast, HIGH); //Blinker an Taste fuer Fussgaenger
delay(500);
digitalWrite(f_lamp_tast, LOW);
delay(500);
if (sensorValue > 300){ //Dämmerungswert für Nachtschaltung
digitalWrite(a_rot, LOW);
digitalWrite(a_gelb, HIGH); //Autos Gelb für Blinker
digitalWrite(a_gruen, LOW);
digitalWrite(f_rot, LOW);
digitalWrite(f_gruen, LOW);
delay(500);
digitalWrite(a_gelb, LOW);
}
else {
digitalWrite(a_rot, LOW);
digitalWrite(a_gelb, LOW);
digitalWrite(a_gruen, HIGH); //Autos gruen
digitalWrite(f_rot, HIGH); //Fussgaenger rot
digitalWrite(f_gruen, LOW);
}
if (digitalRead(f_tast) == LOW){ //Taste Fussgaenger abfragen
digitalWrite(13, HIGH); //Taste Fussgaenger ist gedrueckt worden
digitalWrite(f_rot, HIGH); //Fussgaenger rot
digitalWrite(a_gruen, LOW);
digitalWrite(a_gelb, HIGH); //Autos gelb
delay(1000); // Autos Gelbphase
digitalWrite(a_gelb, LOW);
digitalWrite(a_rot, HIGH); //Autos rot
delay(500); // Fussgaenger Wartezeit damit kein Auto mehr fährt
digitalWrite(13, LOW);
digitalWrite(f_rot, LOW);
digitalWrite(f_gruen, HIGH); //Fussgaenger gruen
delay (6000); //Fussgaenger gruenphase
digitalWrite(f_rot, HIGH); //Fussgaenger rot
digitalWrite(f_gruen, LOW);
delay(1000); //Autos Wartezeit damit kein Fussgaenger mehr laeuft
digitalWrite(a_gelb, HIGH); //Autos gelb
delay(1000); // Autos Gelbphase
}
}
Der Taster für die Fußgänger um grün anzufordern, wird später auf Interrupt umgestellt, da die Delay Befehle ja dafür sorgen, das nur ein langer Tastendruck sicher erkannt wird (bzw. ein Tastendruck der genau zum Zeitpunkt der Abfrage erfolgt).
Um den Interrupt zu verstehen, gibt es ein kleines Spiel.
Ich stehe hinter meinem Großneffen und ihm gegenüber stehen seine Eltern.
Für die zyklische Abarbeitung hält seine Mutter alle 10 Sekunden einen Spigel hin, so da er sehen kann was ich hinter ihm mache.
(Ich halte von Zeit zu Zeit ein Handtuch hoch)
Das wird ein paar mal gemacht, dann kommt sein Vater ins Spiel.
Jedesmal wenn ich ein Handtuch hochhalte sagt er "Alarm", er ist also der Interrupt.
Die Variante mit Interrupt:
Code:
int f_tast = 2;
int a_rot = 3;
int a_gelb = 4;
int a_gruen = 5;
int f_rot = 8;
int f_gruen = 9;
int f_lamp_tast = 13;
int s_licht = A0;
byte f_press = HIGH;
void setup() {
pinMode(f_tast, INPUT);
pinMode(a_rot, OUTPUT);
pinMode(a_gelb, OUTPUT);
pinMode(a_gruen, OUTPUT);
pinMode(f_rot, OUTPUT);
pinMode(f_gruen, OUTPUT);
attachInterrupt(0, button, LOW);
//Serial.begin(9600);
}
void loop() {
int sensorValue = analogRead(s_licht);
//Serial.println(sensorValue);
// Blinker code zum Prüfen ob Programm läuft
digitalWrite(f_lamp_tast, HIGH); //Blinker an Taste fuer Fussgaenger
delay(500);
digitalWrite(f_lamp_tast, LOW);
delay(500);
if (sensorValue > 500){ //Dämmerungswert für Nachtschaltung
digitalWrite(a_rot, LOW);
digitalWrite(a_gelb, HIGH); //Autos Gelb für Blinker
digitalWrite(a_gruen, LOW);
digitalWrite(f_rot, LOW);
digitalWrite(f_gruen, LOW);
delay(500);
digitalWrite(a_gelb, LOW);
}
else {
digitalWrite(a_rot, LOW);
digitalWrite(a_gelb, LOW);
digitalWrite(a_gruen, HIGH); //Autos gruen
digitalWrite(f_rot, HIGH); //Fussgaenger rot
digitalWrite(f_gruen, LOW);
}
// if (digitalRead(f_tast) == LOW){ //Taste Fussgaenger abfragen
if (f_press == LOW){ //Statusvariable Taste Fussgaenger abfragen
delay(500);
digitalWrite(13, HIGH); //Taste Fussgaenger ist gedrueckt worden
digitalWrite(f_rot, HIGH); //Fussgaenger rot
digitalWrite(a_gruen, LOW);
digitalWrite(a_gelb, HIGH); //Autos gelb
delay(1000); // Autos Gelbphase
digitalWrite(a_gelb, LOW);
digitalWrite(a_rot, HIGH); //Autos rot
delay(1000); // Fussgaenger Wartezeit damit kein Auto mehr fährt
digitalWrite(13, LOW);
digitalWrite(f_rot, LOW);
digitalWrite(f_gruen, HIGH); //Fussgaenger gruen
delay (6000); //Fussgaenger gruenphase
digitalWrite(f_rot, HIGH); //Fussgaenger rot
digitalWrite(f_gruen, LOW);
delay(1000); //Autos Wartezeit damit kein Fussgaenger mehr laeuft
digitalWrite(a_gelb, HIGH); //Autos gelb
delay(1000); // Autos Gelbphase
f_press = HIGH;
}
}
void button(){
f_press = LOW;
}
Da der Galileo "Roboter" ja keinerlei Sensorik hat, will ich ihm erst mal zeigen was mit relativ einfachen Mitteln geht.
Also:
1- Bumper zu Kollisionserkennung. (ein Paar Mikroschalter aus Computermäusen per Wiederstandsnetzwerk an einem Analogeingang)
2- Linienfolge Sensor
3- Ultraschall Sensoren um Entfernungen (Abstände) zu messen.
4- IR Sharp GP2D120 um Treppenabsätze zu erkennen. (Kinderzimmer ist im ersten Stock)
(GP2D120 muß ich aber erst besorgen, habe zur Zeit keine mehr übrig)
Um ein Vorführbeispiel zu haben, habe ich mal mit einem Arduino nano, zwei HC-SR04 Ultraschallmodulem und einem Funduino Tracker Sensor (Linienfolgesensor mit 3 IR Reflexkopplern - TCRT5000)
ein Funktionsmuster gebaut.
Code:
const int us1_echo = 2;
const int us2_echo = 3;
const int us1_trig = 4;
const int us2_trig = 5;
const int lf_le = 8;
const int lf_ce = 9;
const int lf_ri = 10;
int lf_le_state = LOW;
int lf_ce_state = LOW;
int lf_ri_state = LOW;
unsigned long us1_echo_st;
unsigned long us2_echo_st;
unsigned long us1_echo_et;
unsigned long us2_echo_et;
unsigned long us1_srt;
unsigned long us2_srt;
unsigned long us1_dist;
unsigned long us2_dist;
unsigned long prev1micros = 0;
const long toggleinterval = 1000;
int togglestate = LOW;
int us1_flag = 0;
int us2_flag = 0;
char* string_[]={"Linefollow:", "US-Echo1:", "US-Echo2:", "Cycletime:"};
unsigned long prev2micros = 0;
void setup() {
Serial.begin(9600);
pinMode(us1_echo, INPUT);
pinMode(us2_echo, INPUT);
pinMode(us1_trig, OUTPUT);
pinMode(us2_trig, OUTPUT);
pinMode(lf_le, INPUT);
pinMode(lf_ce, INPUT);
pinMode(lf_ri, INPUT);
attachInterrupt(0, US1_ISR, CHANGE);
attachInterrupt(1, US2_ISR, CHANGE);
}
void loop() {
lf_le_state = digitalRead(lf_le);
lf_ce_state = digitalRead(lf_ce);
lf_ri_state = digitalRead(lf_ri);
unsigned long cur1micros = millis();
if (cur1micros - prev1micros >= toggleinterval) { //alle 10ms umschalten
prev1micros = cur1micros;
if (togglestate == LOW){
togglestate = HIGH;
digitalWrite(us1_trig, HIGH);
digitalWrite(us2_trig, LOW);
us1_echo_st = 0;
us1_flag = 0;
}else{
togglestate = LOW;
digitalWrite(us1_trig, LOW);
digitalWrite(us2_trig, HIGH);
us2_echo_st = 0;
us2_flag = 0;
}
}
us1_dist = (us1_srt / 58); // Umrechnung des Sensorwerts, ungefähr in cm (für 343m/s bei trockner Luft und 20° wäre 58,3 der genaue Wert)
us2_dist = (us2_srt / 58);
Serial.print(string_[1]);
Serial.println(us1_dist);
Serial.print(string_[2]);
Serial.println(us2_dist);
Serial.print(string_[0]);
Serial.print(lf_le_state);
Serial.print(lf_ce_state);
Serial.println(lf_ri_state);
unsigned long cur2micros = micros();
Serial.print(string_[3]);
Serial.println(cur2micros - prev2micros);
prev2micros = cur2micros;
}
void US1_ISR(){
if (us1_echo_st == 0) {
us1_echo_st = micros();
} else {
us1_echo_et = micros();
++us1_flag;
}
if (us1_flag == 1) {
us1_srt = (us1_echo_et - us1_echo_st);
}
}
void US2_ISR(){
if (us2_echo_st == 0) {
us2_echo_st = micros();
} else {
us2_echo_et = micros();
++us2_flag;
}
if (us2_flag == 1) {
us2_srt = (us2_echo_et - us2_echo_st);
}
}
Ergebniss der Ausgabe:
US-Echo1:226
US-Echo2:227
Linefollow:000
Cycletime:63440
Als nächstes kommen die Antriebe dran.
Da bin ich noch am Überlegen ob gehackte Servos mit Elektronik und Servo Library oder gehackt ohne Elektronik mit H-Brücke als Getriebemotoren.
Letzeres wäre vom Erklären her einfacher (Modell mit 4 Schaltern).
Ggf. ja später zwei Mikroservos out of the Box um mit den zwei US-Sensoren eine 360° Überwachung zu realisieren.
Da ja DC Motoren ohne Regelung nicht besser sind wie bei dem Galileo "Roboter", kommt dann das Innenleben einer Kugelmaus zu neuen Ehren (Odometrie).
Da suche ich allerdings noch den Karton wo die alten Mäuse drin sind.
Als Demonstrationsbeispiel nehme ich eine schwarz gestrichene Pringles Dose bei der man so nicht erkennen kann ob ich sie linksrum oder rechtsrum drehe.
Dann zwei Reihen Löcher versetzt in den Rand gelocht und eine Lampe (mit Pappblenden) innen rein um zu erkennen in welcher Reihenfolge beim Drehen die Lichter an und aus gehen.
Liste der Anhänge anzeigen (Anzahl: 2)
Zitat:
Zitat von
HaWe
Meine Favoriten sind ja immer noch die Lego Encodermotoren.
Man kann sie als einfache DC Motoren verwenden (L293-H-Brücken reichen), bei ca 2-3 U/sek kann man sie direkt an Radachsen ansetzen (und auch noch mit Lego Rädern und Chassis verbauen ), sie sind (gebraucht) einigermaßen preiswert, und die Encoder sind wirklich Top!
Es darf halt nichts (nur wenig) kosten.
Modelcraft RS-2 Servos habe ich hier halt noch einige in der Krabbelkiste liegen.
Beim Neupreis der Mindstorm Motoren würde ich für eigene Projekte auf die Pololu 12VDC mit Metallgetriebe und Quadraturencoder Wechseln oder halt richtige Encoder:
http://www.amazon.de/Encoder-Increme...hase+6mm+Shaft
und dann beliebige Motoren. (Die Pololu Encoder einzeln mit beliebigen Motoren wären dann die günstige Variante)
Aber mal sehen sollte er dabei bleiben, könnte es sein das passend zum schon vorhandenen Lego sich da was tut.
Zitat:
Zitat von
Rabenauge
Preiswerte Hindernissensoren:
http://www.ebay.de/itm/10pcs-IR-Infr...8AAOSwgQ9VrfV6
Hab ich mir neulich mal fünf Stück von besorgt- für _den_ Preis allemal gut.
Gibts auch in einer "Linienfolger"-Version und eine, bei der das Ding einfach nach unten guckt.
Sehr einfach zu handhaben (Strom ran, und dann ein simpler Digitalausgang) und funktionieren recht gut.
Selbst zweie davon nebeneinander (~5cm, das gabs Steckbrettl grade her) kommen sich nicht ins Gehege.
Auch toll zum rum probieren: die haben ne LED drauf für "ich sehe was"-die geht an, wenn er nen Hindernis entdeckt.
Mit nem bissel Treiberei könnte man damit nen Roboter sogar ohne Controller Hindernissen ausweichen lassen (sie schalten HIGH bei feier Bahn, und LOW wenn sie was entdecken).
Ja, die habe ich mir schon angesehen, der Preis ist beim Selbstbau nicht zu schlagen, (Da kommen die Teile ja schon teuerer wenn man sie in Kleinmengen holt)
Bei mir betreibe ich 38/40kHz IR Sensoren im Time Multiplex, da kann ich die wenn nötig dichter packen ohne das die sich in die Quere kommen. Und bei mehr wie 4 Stück spare ich Pins (ein Signaleingang, und 3 Adressausgänge für 7 Stück)
Wegen der Erkennung des Treppenabsatzes und anderer Abgründe, wird es später aber auf jeden Fall GP2D120 geben. (Auch wenn die teuere sind)
Für den Anfang schau ich die mir aber mal an.
- - - Aktualisiert - - -
Einmal die Ampelschaltung als Bild:
Anhang 31039
und der Schaltplan.
Anhang 31040
Liste der Anhänge anzeigen (Anzahl: 7)
Mal ein paar Bilder.
Sensor Testaufbau:
Anhang 31045
Da es möglichst wenig kosten darf und mein Großneffe auch was selbst machen möchte, hier mal meine Selbstbauräder aus Sperrholz und Dichtungen für 50mm Abflußrohren.
Einzelteile:
Anhang 31046
von der Seite:
Anhang 31048
zusammengebaut:
Anhang 31047
Da ich die Kiste mit den Mäusen nicht finde, eben ein Alublech für eine Encoderscheibe gemacht.
Anhang 31049
Auf dem Servo montiert
Anhang 31050
mit Sicht auf die Encoderscheibe
Anhang 31051
Da ich das Alublech, die Schrauben und das Sperrholz als Reste da habe, belaufen sich die Kosten pro Rad auf 0,45€ für die Dichtungen.
Ich habe noch ein paar SG-105F Reflex Lichtschranken da, da muß man zwar recht genau arbeiten, da die nur knapp 1mm haben, aber das geht schon.
- - - Aktualisiert - - -
Zitat:
Zitat von
Rabenauge
Was deine Antriebe angeht: Servos sind doch keine üble Wahl.
Auf arduinisch leicht anzusteuern...
Ich bin noch am Überlegen ob gehackte Servos mit Elektronik und Servo Library oder gehackt ohne Elektronik mit H-Brücke als Getriebemotoren.
Letzeres wäre vom Erklären her einfacher (Modell mit 4 Schaltern).
Das Projekt soll ja didaktisch für einen 7 jährigen möglichst viel bringen.
Zitat:
Zitat von
Rabenauge
Das mit der Kugelmaus interessiert mich übrigens auch brennend, wenn du das machst, erzähl mal bitte mehr drüber. Ich hatte mal versucht, eine Mäuse-Kamera mit nem Arduino zu verbinden, das funktioniert auch als Weggeber, aber nur bei extrem geringem Bodenabstand. So Kugelmausteile hab ich nämlich auch noch da, nur sind meine Elektronikkenntnisse eher rudimentär.
Habe festgestellt das die Kiste eingelagert ist (da ich alle Kisten in der Wohnung durch habe)
Plan B ist jetzt eine Aluscheibe mit einer Maskenfolie fürs Airbrush und schwarzem Mattlack in eine Reflektorscheibe zu verwandeln.
Mit zwei SG-105F Reflex Lichtschranken die im richtigen Abstand zueinander angeordnet sind, kann man dann einen Quadraturencoder wie bei einer Maus aufbauen.
Mit einem 4093 kann man einen Schmitt-Trigger für beide Kanäle aufbauen und mit einem 4069 und 4030 ein Summensignal bei dem jede Flanke an beiden Kanälen einen Puls auslöst. Also ein Signalverdopplung gegenüber den beiden Kanälen.
Dieses Signal kann man zum einen zum Regeln nehmen und zum anderen als Takt auf einen aus D-Flopflops und XOR aufgebaute Richtungsauswertung leiten die so aus beiden Kanälen ein DIR Signal erzeugt.
Damit wird die Auswertung relativ einfach.
Timerauswertung für das Summensignal und Pegelauswertung für das DIR Signal.
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Zitat von
oberallgeier
Die Ansteuerung der LED erfolgt
"gechirpt" (hier mehr davon) und nicht mit Dauerstrich,
Chirpen lasse ich erst mal außen vor, das kann je nach Entwicklung meines Großneffen in eins zwei Jahren kommen, wenn wir uns mit FMCW für Sensoren befassen.
Momentan will ich mit Festfrequenz anfangen.
Als Exkurs werden wir wohl einen einfachen Multivibrator mit Transistoren (Rechteck) und einen Phasenschieber Oszilator (Sinus/Dreieck) bauen.
Dann wird er sich aus dem Phasenschieber einen Durchgangsflöter als erstes eigenes Prüfgerät bauen.
Für die Sensoren werde ich dann wohl aus NANDs oder Invertern einen Generator bauen um die Frequenz zu erzeugen.
Dann muß mit den Portpins die jeweilige LED nur noch gegen GND geschaltet werden.
Erst mal wird je LED ein Receiver genutzt, dann werden wir testen in wieweit ein Receiver mit zwei zeitversetzt sendenden LEDs eine Einsparung von Receivern und Portpins zulässt.
(später dann eventuell mit zwei 4028 eine Adressierung der LEDs und der Receiver realisieren um mehr Sensoren mit wenig Portpins zu realisieren.)
Auch werden alle Teilsysteme immer erst mal separat aufgebaut und programmiert. Erst wenn sie einwandfrei funktionieren erfolgt die Integation in den zweiten Arduino nano.
Da wird dann mit Timing etc. wohl noch genug passieren was die Freude am ersten Erfolg wieder dämpft.
Nur eine Direktintegration bei der Entwicklung wird in diesem Alter wohl noch zu frustrierend sein, das möchte ich vermeiden.
Ich rechne eh damit das der Roboter mindestens drei mal komplett neu designed und aufgebaut wird.
Spätestens beim Treppensteigen, wird wohl ein Kettenantrieb fällig werden.
Bsp.: Anhang 31052
Liste der Anhänge anzeigen (Anzahl: 5)
Die Vorbereitung für den mechanischen Aufbau schreiten vorran.
Einmal die vorbereiteten Teile für meinen Großneffen (ein paar Sachen muß ich heute noch holen, Schrauben etc.)
Anhang 31056
Und das Exemplar, das ich für mich zum vorbereiten und planen baue.
von unten
Anhang 31057
von oben
Anhang 31058
und von der Seite
Anhang 31059
Und ein Kanidat für einen 180° Schwenkantrieb für einen US-Sensor.
Anhang 31060
Da ich von dem Servo noch 3 Stück habe, und auch 3 Stück von den HC-SR04, sowie noch einen fünften RS-2, bin ich grade am überlegen ob ich meinem Roboter 2 US Sensoren gebe oder einen dritten Roboter bauen soll.
(Ein kleiner Schwarm wäre ja auch nicht schlecht)
Liste der Anhänge anzeigen (Anzahl: 2)
Zitat:
Zitat von
Rabenauge
Bau dir lieber ne Maus-Kamera in den Schleifer ein.
Grad bei einer solchen Anordnung haste da _richtig_ was zum spielen, weil man die recht unproblematisch an nem Arduino als Weggeber benutzen kann.
Du könntest dann sogar Kurven berechnen, ne Geradeausfahr-Regelung stricken und nen Linienfolger haste auch gleich noch bei....
Wird bei mir auch kommen.
Habe jetzt genug Sensoren um alle meine Roboter damit nachzurüsten.
Ich muß sie nur mal auslöten und dann auf den verschiedenen Systemen implementieren.
Anhang 31062
Da der Roboter aber von einem 7 jährigen Kind aufgebaut werden soll, kommen hier möglichst nur Elemente zum Einsatz, die man auch diesem Alter erklären kann.
Also erst mal verschoben.
Zitat:
Zitat von
Rabenauge
Schwarm hat allerdings auch was....
Da kann ich auch erst optische kommunikation mit IR und später Funk implementieren.
Und der Lerneffekt bei der Interaktion im Teamwork ist für meinen Großneffen bestimmt von nutzen.
Wobei ich das als "nice to have" und "future option" erst mal im Raum stehen lassen will.
Ich rechne jetzt schon damit das er beim Programmieren laufend das Interesse verlieren wird.
Aus dem Grund programmiere ich ja die Lösungen alle schon vor.
Habe ich bei Projektwochen auch so gemacht, alles war schon funktionsfähig vorbereitet.
Zwar wurde in den 4 Tagen die zum Arbeiten zur Verfügung standen der ganze mechanische Aufbau gemacht, die Elektronik aufgebaut und ein erstes Fahrprogramm erarbeitet und geschrieben, aber meist konnten nur die besten in der Gruppe erste Experimente mit Sensoren die über Bumper hinausgehen machen.
Zitat:
Zitat von
Rabenauge
wobei du _einen_ ja mal rund (wie Nibo2 oder so) bauen könntest, um Junior die Vorzüge einer Bauform zu demonstrieren, die nicht überall hängen bleibt....
Mein Rug Warrior ist schon rund das kann ich ihm also schon demonstrieren.
Anhang 31061
Der rechteckige Aufbau ist momentan zum einen der Tatsache geschuldet, das ich meinen Großneffen zwar mit dem Akkuschrauber die Löcher bohren lassen kann, aber mit der Laubsäge einen Kreis aussägen dauert verdammt lang und ist Fleißarbeit und an den Kreisschneider kann ich den nicht ranlassen, da ist das Unfallriesiko zu groß.
Zum anderen soll der Roboter ja später mal Treppen bewältigen können. Das Modell wird dadurch zwangsweise rechteckig werden, da macht es schon Sinn sich jetzt schon mit der nachteiligen Form auseinaderzusetzen und Strategien gegen das Hängenbleiben und Festfahren zu entwickeln.
Zitat:
Zitat von
Rabenauge
Aus was ist eigentlich die Chassis-Platte?
Einseitig Cu kaschierte Eurokarte in GFK.
Da ich nur noch mit fotopositiv arbeite wenn es kein Lochraster ist, lagen die bei mir noch orginalverpackt rum.
Die 1,6mm GFK Platinen sind sehr stabil und falls notwendig kann ich unten noch als Rippen Streifen von doppelseitig kaschierter Platine dranlöten.
Liste der Anhänge anzeigen (Anzahl: 2)
Zitat:
Zitat von
Rabenauge
Toll-sowas hätte ich auch gerne rum liegen.
Das war ein Glücksgriff. Kompletter Hardare Austausch bei einem Kunden.
Einen Tag bevor der Elektroschrott Container abgeholt wurde, bin ich mit Schraubenzieher angerückt. und habe alle Mäuse an die ich rankam ausgewaidet.
Zitat:
Zitat von
Rabenauge
Ich will nebenbei nen 1:24er Auto auf robotisch umbauen, und überlee, ob es nich sinnvoller wäre, ne Chassisplatte selber zu stricken, damit mehr Platz wäre. Das von unten zugängliche Batteriefach hat zwar was, aber es braucht innen auch wahnsinnig viel Platz. Und ne angetriebene Achse ist nun wirklich nix kompliziertes (könnt ich auch gleich nen anständigen Motor rein bauen)...
In dem Maßstab sind ja viele Chassis bereits aus GFK bzw CFK (Kohlefaser).
Wenn Du da was suchst, Stichworte sind: Glashartgewebe, FR4, GFK.
Zitat:
Zitat von
Rabenauge
Da du ja Arduinos (in irgendeiner Form) benutzen willst, wie wärs für den Lütten mit "Bausteinen"? Ich mein, in dem du diverse Sachen einfach als kleine Bibliotheken schreibst?
Das dürfte nem Kind recht simpel zu erklären sein, und verbirgt die Komplexität hinter den Geschichten..
Ich habe zwei Nanos und einen Due hier, ein Uno ist noch unterwegs.
Die Idee ist nicht schlecht, aber ich denke nicht das ich das in zweieinhalb Tagen noch schaffe.
Ich muß morgen noch die Radencoder und die Bumper fertig bekommen.
Montag schaue ich dann ob ich auf dem Nano die Antriebe noch mit der Servo.h dazubekomme oder ob sich das mit den Pins die ich bereits belegt habe überschneidet.
Wenn es nicht passt, muß ich entweder das bisherige Programm und den Aufbau umstricken, oder die Servos als DC-Motoren per PWM ansteuern.
Ich will halt so viel wie möglich mit dem Nano realisieren. Den Uno und den Due will ich für eine komplexere Version (Treppensteiger mit Kettenantrieb wie in dem Bild vor ein paar Posts) in der Hinterhand behalten.
Dienstag Mittag muß der Prototyp soweit laufen, das ich mit dem kleinen zügig an seinem Roboter loslegen kann.
- - - Aktualisiert - - -
So, noch der letzte Bauvorschritt für heute.
Vordere Sensorbühne und Line Tracker Sensor montiert.
Die Taster der vier Bumper sind auf Lochrasterstreifen gelötet.
Die Druckplatten sind gesägt (0,5mm einseitig Cu kaschierte GFK)
Am ersten Bumper ist schon ein Haltebügel und die erste Federeinheit ist gebogen und fertig zum anlöten an die Druckplatte.
Es werden immer 2 Taster verodert.
an die Druckplatten kommen seitlich noch gebogene Ms Blechstreifen, so das ein verharken an einem Hinderniss nicht so leicht passiert.
Anhang 31066
Anhang 31067
Die Lochbleche stammen von einem zölligen Metallbaukastensystem das es vor ein paar jahren mal gab.
Als es sich nicht verkaufte, wurde es irgendwann beim Discounter verramscht, da habe ich damals zugeschlagen und 3 Kästen auf Vorrat gekauft.
Liste der Anhänge anzeigen (Anzahl: 2)
Erster Bumper fertig zum verdrahten.
Und falls sich jemand für den Aufbau interessiert mal zwei weitere ohne aufgelötetes Druckstück
Anhang 31069
Wobei ich festgestellt habe, das sich mein 55W Lötkolben vermutlich bei den Kugelmäusen befindet.
Mit dem Minitip ist das mehr wie Reiblöten und halt eine große kalte Lötstelle.
Na ja, muß dann später halt noch mal richtig gemacht werden.
Und der Messaufbau für die notwendige Auslösekraft.
Anhang 31070
55g, also etwas mehr als ein halbes N für einen Taster.
Liste der Anhänge anzeigen (Anzahl: 1)
Gestern zu nichts gekommen, da ich Chaufeur spielen musste.
Heute die Encoderscheiben fertig bekommen.
Enmal mit Malerkrepp maskiert und einmal fertig.
Anhang 31073
Von 15:00 bis eben mit meinem Großneffen an seinem Roboter gearbeitet.
Beide Räder gebaut und beide Servos umgebaut.
Ich habe immer einmal vorgemacht und das zweite Teil hat er selbst gemacht.
Liste der Anhänge anzeigen (Anzahl: 2)
So, der Exkurs zum Thema Getriebe ist etwas Extrem geworden:
Anhang 31074
(262144:1)
Der aktuelle Stand:
Anhang 31075
#
Liste der Anhänge anzeigen (Anzahl: 3)
Odometrie
!! Muß nach mal überarbeitet werden !!
Bumper
Anhang 33282
Linienfolgesensor
Anhang 33283
US-Sensor
Anhang 33284
So, genug alte Anhänge gelöscht um diese hochladen zu können.
Liste der Anhänge anzeigen (Anzahl: 2)
Hallo i_make_it,
hast Du die Odometrie-Schaltung ausprobiert? Da ich auch an der HW-Vorauswertung des Quadratursignals interessiert bin und selber damit experimentiert habe, habe ich die Schaltung mal versucht zu simulieren. Im Simulationsprogramm war nicht das richtige Flip-Flop enthalten und ich mußte deshalb die S- und R-Eingänge noch mit Invertern auf richtigen Zustand bringen.
Anhang 33289
Den Pegelschrieb liest man von rechts nach links. Zuerst wird A zu high, danach B zu high.A zu low usw. Ab der Mitte findet eine Drehrichtungsumkehr statt. Ab da wird B vor A zu high.
Anhang 33291
Die kleinen Verzögerungen der Pulsflanken zu de A/B Flanken kommen durch Gatterlaufzeiten zustande.
Aber beiden Drehrichtungen macht "Direction" zwischendurch Pegelwechsel. Ist das richtig und wie würde man das im µC auswerten?
Gruß
Searcher
Liste der Anhänge anzeigen (Anzahl: 2)
Erster Erfolg:
Anhang 33296
Schaltung in LTSpice
Anhang 33297
Timing (Reihenfolge von Oben: A, B, Pulse, Direction)
Mal sehen ob ich den Pegelwechsel von Direction noch etwas besser (zeitnäher) hinbekomme.
Liste der Anhänge anzeigen (Anzahl: 1)
Anhang 33298
Der zusätzliche Schaltungsaufwand erzeugt ein Rechtecksignal, bei dem immer die zuerst wechselnde Flanke eine steigende Flanke verursacht und die folgende wechselnde Flanke eine fallende. Durch einen Frequenzhalbierer wird daraus das Direction Signal.
Gegenüber der Variante von heute Nacht ergibt sich bei gleichen Simulationsparametern nur in einem der Fälle eine Verbesserung.
Ich muß noch testen ob bei veränderten Parametern dadurch in allen Fällen immer ein schnelleres Umschalten erreicht wird.
Liste der Anhänge anzeigen (Anzahl: 1)
So, habe die Werte für die Simulation noch etwas verändert um auch auf dem B-Kanal mehr Wechsel zu haben.
Momentan wird Direction sofort geändert, wenn nach dem Rictungswechsel an A oder B eine steigende Flanke folgt.
Kommt nach dem Richtungswechsel als erstes eine fallende Flanke, reagiert die Schaltung erst auf die folgende steigende Flanke.
Also noch etwas "basteln".
Anhang 33300
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Zitat von
Searcher
Klappt bei mir mit LTSpice nicht.
Beim Direction Signal kommt bei mir das selbe raus was ich schon beim Summensignal habe (Bei Dir der Ausgang vom XOR links unten).
Ich habe als Logigkgatter die CD 4000 er genommen. Mit deren Werten für Rise und Fall sowie der Durchlaufverzögerung.
Was bei Dir unten ist, der Teil der das Summensignal bildet und dann einen Nadelimpuls pro Flanke erzeugt, funktioniert.
Aber z.B. das Flip Flop am A-Kanal dessen Set Du mit A und dessen Reset Du mit der Inversion von A beschickst, liefert bei mir an Q, grade wieder das Muster von A (halt nur um ein Paar ns verzöger).
Ebenso bei dem Flip Flop an B.
Und das dritte Flip Flop (an B) liefert auch wieder das Signal von B, halt noch ein paar ns stärker verzögert.
Damit kommt dann bei mir an dem XOR rechts oben das selbe raus wie bei dem links unten.
Mit welcher Software hast Du denn simuliert und mit welchen Bauteilen/Bauteilparametern?
- - - Aktualisiert - - -
Hier meine optimierte Schaltung. Direction wird jetzt bei jedem Richtungswechsel mit dem ersten Pegelwechsel umgestellt.
Anhang 33306
Jetzt kommt der Teil vor dem es mir immer graut. Wahrheitstabellen und versuchen zu vereinfachen um kein Chip Grab zu haben.
Eventuell suche ich auch mal meine alten PAL/GAL Unterlagen raus. Ein CPLD wäre auch eine Möglichkeit. Bei der Anzahl Chips die man im Moment bräuchte, würden sich die 5€ für ein CPLD auf jeden Fall rechnen.
Zum Verständnis der Schaltung:
Ganz links ist die Simulation des B-Kanal und dessen Verhalten beim Richtungswechsel.
Die Pulse Spannungsquelle Steuert die beiden Spannungsgesteuerten Schalter die für den Richtungswechsel zwichen den beiden um 180° verschobenen Sinus Spannungsquellen hin und her schaltet.
Der Selbe Aufbau folgt dann für die Simulation des A-Kanal, halt um 90° Verschoben zum B-Kanal.
Dann folgen die Schmitt-Trigger aus je zwei NAND (als Inverter).
Nach den Schmitt-Triggern wird oben durch ein XOR das Summensignal Pulse gebildet und dann mit der Schaltung von Searcher die Nadelpulse erzeugt. Das ergibt eine Vervierfachung der Pulse gegenüber einem einzelnen Kanal (A oder B).
Nach dem ersten NAND der Schmitt-Trigger und nach den Schmitt-Triggern werden A- und B-Kanal jeweils zum Ansteuern der Flip-Flops der Frequenzteiler abgegriffen. Es wird der A-Kanal einmal auf D des einen Flip-Flop und auf CLock des anderen gelegt.
Der B-Kanal entsprechend vertauscht.
Am Ende werden die Beide, je aus drei Flip-Flops, einem XOR und einem NAND (als Inverter) bestehenden Zweige auf einen letzten Frequenzteiler geführt, der das Direction Signal jeweils zum ersten Flankenwechsel nach einer Richtungsumkehr umschaltet.
Im Diagram unterhalb der Schaltung ist rot PULSE und grün DIRECTION dargestellt.
Oberhalb der Schaltung stehen die LTSpice Direktiven damit die V-Switche funktionieren und die CD 4000 Library genutzt wird.
Unterhalb der Schaltung, die Simulationszeit von 30 Sekunden.
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Zitat von
i_make_it
Klappt bei mir mit LTSpice nicht. ...
...
Aber z.B. das Flip Flop am A-Kanal dessen Set Du mit A und dessen Reset Du mit der Inversion von A beschickst, liefert bei mir an Q, grade wieder das Muster von A (halt nur um ein Paar ns verzöger).
Ebenso bei dem Flip Flop an B.
Und das dritte Flip Flop (an B) liefert auch wieder das Signal von B, halt noch ein paar ns stärker verzögert.
Damit kommt dann bei mir an dem XOR rechts oben das selbe raus wie bei dem links unten.
Ja, ich habe mittlerweile auch bemerkt, daß Logikzustände scheinbar einfach durch die R-S Flipflops durchgereicht werden.
Zur Entstehung der Schaltung:
Ich habe mir sämtliche Zustände, die an den A/B Eingängen in Vorwärts- und Rückwärtsrichtung auftreten können, aufgeschrieben.
Die Richtungsbestimmung kann durch Vergleich des gegenärtigen A/B Zustandes mit dem A/B Zustand davor erfolgen.
Zum Speichern der Zustände hatte ich 74HC595 Schieberegister verwendet. Das schien selbst mir etwas zuviel.
Schieberegister kann man durch hintereinandergeschaltete R-S flip Flops erzeugen; mit einem Inverter zwischen R-S im ersten Flip Flop.
Das ist sind die Flip Flops, die an Eingang B hängen.
An A hing das Gleiche bis ich festgestellt hatte, daß nach Wahrheitstabelle zur Feststellung der Richtung das zweite Flip Flop an A entfallen kann.
Code:
Wechsel AB
von nach (Richtung) nur Vorwärtsrichtung rausgezogen
00 01 R
00 10 V 1.2. 3.4. Bit
10 00 R
10 11 V 0 0 1 0
11 10 R 1 0 1 1
11 01 V 1 1 0 1
01 11 R 0 1 0 0
01 00 V
Gemeinsamkeit Vorwärts: 1. und 4. Bit gleich im Gegensatz zu Rückwärts. Deswegen das abschließende XOR.
Mittlerweile sieht es so aus, daß ich auf die Flip Flops ganz verzichten kann aber die Gatterlaufzeiten sehr wichtig sind.
Habe deshalb die Flipflops entfernt und Latches "eingebaut", die nur die Aufgabe haben auf steigende Taktflanke die Logikpegel gezielt durchzuschalten.
Es sollten CD4000er OK sein. Die Latches schalten bei steigender Flanke. Die etwas optimierte Schaltung:
Anhang 33307
LT Spice habe ich länger nicht benutzt und schaue später mal, ob ich das dort auch simuliert bekomme.
Durch die Optimierung und Gewichtung auf die Delays der Gatterlaufzeiten werde ich den Verdacht nicht los, daß ich früher oder später bei der Manf-Lösung lande:
https://www.roboternetz.de/community...ll=1#post82074
Zitat:
Mit welcher Software hast Du denn simuliert und mit welchen Bauteilen/Bauteilparametern?
Ich benutze hier den Uralt- DigitalSimulatorV5.57.exe
Info: http://www.vlin.de/vlin2/material/Si...chaltungen.pdf
https://sourceforge.net/projects/dig...ll%20EXE/5.57/
Man kann keine Bauteile nach Namen auswählen sondern nur die Funktion. Sicher keine hochwertige Simulation aber durch die Anzeige der logischen Zustände durch farbige Leitunngen schön übersichtlich. Durch Rechtsklick auf Leitungen kann man Meßpunkte setzen, die dann im Pegelschrieb erscheinen. Seltsamerweise gehen Beschriftungen nach Abspeichern und Wiederladen einer Simulation verloren :-( Daher die magere Beschriftung, die auch noch umständlich anzubringen ist.
Liste der Anhänge anzeigen (Anzahl: 2)
Zitat:
Zitat von
Searcher
Es sollten CD4000er OK sein. Die Latches schalten bei steigender Flanke. Die etwas optimierte Schaltung:
...
LT Spice habe ich länger nicht benutzt und schaue später mal, ob ich das dort auch simuliert bekomme.
So, nachdem ich LTSpice mit den 4000ern zum Laufen gebracht habe, hatte ich zunächst auch nicht das gute Ergebnis vom Digitalsimulator. Bis ich festgestellt hatte, daß die Pulserzeugung aus V1 und V2 langsamere Flanken hat als das, was aus den Gattern rauskommt. Habe dann einfach noch Inverter nach V1, V2 geschaltet und dann den untenstehenden Plot bekommen. Die Pulserzeugung hat unterschiedliche Periodenzeiten um Vorwärts- und Rückwärtsbewegungen in einem Plot zu zeigen.
Überbrückt man U4, U5 stimmt das Ergebnis nicht mehr.
Anhang 33319
Anhang 33320
Die Schaltung ist weit entfernt vom Ideal aber ich wollte erstmal das Rätsel der unterschiedlichen Ergebnisse untersuchen.
Liste der Anhänge anzeigen (Anzahl: 1)
Also die Schaltung ist so in Ordnung.
Habe sie eben simuliert.
Die Signale sehen einwandfrei aus.
Anhang 33321
Da in der Schaltung nur D, Clock und Q benötigt wird, könnte man wohl auch einen 74HC174 nehmen.
Ist auf jeden Fall nochmal günstiger als 2 CD 4013er.
