Schon seit fast einem Jahr sind all meine Akkus mehr oder weniger kaputt. Nach fast 10 Jahren dürfen sie das auch sein.
Heute fand ich dann ein Angebot: 12V 9.5Ah für 18Eur. Natürlich sofort gekauft :)
Und solange Amee noch still steht, kann man den Akku ja für die Solaranlage nutzen. WENN denn mal wieder die Sonne scheint.
So, nun ist die neue Akku Halterung fertig
Neuer Akku
Build or buy the controller board
Nachdem nun endlich mein Oszilloskope endlich gekommen ist, habe ich mir mal die H-Brücke genauer angesehen und getestet. Eigentlich funktioniert sie perfekt. Die Mosfets schalten ordentlich durch und werden nicht warm. Keine Ahnung warum sie das letzte mal heiß wurden. Eine kalte Lötstelle gab es, aber die sollte nicht so schlimm gewesen sein.
Ich habe noch ein paar Shunt Widerstände eingebaut, damit man auch mal den Strom der Motoren messen kann, aber das ist momentan nicht weiter wichtig.
Hier ist noch der Schaltplan: http://ichlebe.aufdemmond.de/calle/h-bridge/hb_12V_10A.png
Und hier ein Video robotest1.avi
PS. Das Oszi ist toll :D
Ferb, i know what we gonna do today!
Wir erweitern Amee um zwei Ebenen nach oben. Auf der untersten Ebene hat nach wie vor die Spannungsversorgung, H-Brücke und Motorkontroller platz. Auf die mittlere Ebene kommt der Servo- und Sensorkontroller. Ganz oben hat das Netbook seinen Platz.
Ein Netbook auf dem Roboter bringt einige Vorteile. Es hat eine integrierte Kamera für diverse Bildverarbeitungs Aufgaben mit genug Rechenpower. Ausreichend Speicherplatz für alle Sensordaten und abgefahrene Wege um z.b. eine "Landkarte" zu erstellen. WLAN für die Fernsteuerung und Live Kamerabild. Der Akku hält mindestens 4h und es wiegt kaum mehr als 1kg.
Alle beiden Ebenen sind seitlich auf klappbar damit man an die unten liegenden Platinen kommt. Der Aufbau hat das ganze Wochenende gedauert. Insgesamt sind jetzt mehr als 160 Schrauben, Mutter und Unterlegscheiben, und 7m Alu Profil verbaut.
Als nächstes muss ich die Akku Halterung montieren und die H-Brücke überarbeiten. Die wird aus irgendeinem Grund auch bei geringer Last ziemlich heiß.
Bilder gibts dann auch
Als ich mir eine Video-Vorlesung der Uni Tuebingen ansah, kam mir die Idee, mit einem AVR einem Zufallsgenerator zu programmieren. Als Quelle sollte der Analog-Digital Wandler (ADC)dienen, dessen Eingang in der Luft hängt. Es wird also nur das Rauschen des Wandlers und ein paar Störsignale digitialisiert. Von dem eingelesen Wert wir nur das erste Bit benutzt, also ob die Zahl grade oder ungerade ist. Nach acht Durchläufen hat man somit eine Zufallszahl mit einem Wertebereich von 0 bis 255.
Beim echten Zufall sollte sich eine Gleichverteilung einstellen. Da es 256 Mögliche Ereigniszahlen gibt, beträgt die Wahrscheinlichkeit fü eine Zahl 1/256 = 0.39%.
Nach dem ersten Testlauf mit 39 Millionen Zufallszahlen, sah die Verteilung doch garnicht mal so schlecht aus. Aber es gibt einige Zahlen, die stark von der erwarteten WK abweichen. Darunter ist z.B. die 2 mit 0.71%, die 32 mit 0.63%, die 128 mit 0.98% und die 192 mit 0.87%. Unter binärer Betrachtungsweise fällt sofort auf, dass die Null besonderst oft vertreten ist.
2 = 00000010
32 = 00100000
128 = 10000000
192 = 11000000
Nun liegt die Vermutung nahe, dass der ADC mehr geraden Zahlen produziert als ungeraden. Ein einfacher Test bestätigt es, die Null kommt mit 0.2% häufiger vor als die Eins. Die Ursache hierfür kann nur auf Bauteiltolleranzen im ADC zurückzuführen sein. Als eine Referenzspannung vom 5V genommen wurde, anstatt 2.65V, trat die Eins nun mit 0.2% häufiger auf. Da der Mikrocontroller 6 ADC Kanäle hat, liegt die Vermutung nun nahe, durch wechseln des ADC Kanals den Fehler zu minimieren.
Gesagt, getan. Hier ist die neue Verteilung.
Ahja, das ganze läuft auf einem ATmega8. Das Programm kann aber auf jeden beliebigen Mikrocontroller portiert werden, solange es mindestens einen ADC gibt.
Die Zufallszahlen werden über USART gesendet. Ansonsten gibt es nichts zu sagen, ausser: Macht was ihr wollt damit :)
zufallsgenerator-01.zip
So, im laufe der letzten Tage habe ich die Platine fertig gelötet und eingebaut. Einen erfolgreichen Funktionstest wurde sie auch schon unterzogen. Dabei verbrauchen die Spannungswandler im Leerlauf 240mW. Dieser Verlust ist aber garnichts im Vergleich zu welchen, den ich bekäme, würde ich Festspannungswandler einsetzten.
Als nächstes werde ich den PID-Regler in Angriff nehmen, damit sich die Schüssel endlich mal wieder vom Fleck bewegen kann.
Bilder gibts auch irgendwann.
Ok, hier sind meine Ideen für die Stromversorgungsplatine. Das muss alles drauf:
Mit der H-Brücke und den Motorcontrollern ist die erste Ebene des Roboters mit Platinen bestückt.
So langsam wurde es Zeit, ein paar Platinen festzuschauben. Zwar ist die Schaltung noch nicht komplett aufgelötet, aber das ist nun viel besser, als die Platinen lose herum hängen zu lassen. Vorallem kann der Bot nun wieder herumfahren.
Die Aluminiumplatte habe ich ersteinmal mit Klebeband bezogen, so dass eine Schraube, die sich zufällig unter die Platine verirrt, keinen Kurzschluss nach Masse auslösen kann. Die mittlere Platine ist die H-Brücke für die 2 Motoren und die rechte Platine ist die Motorsteuerung. Jeweils ein mega8 für ein Motor.
Bei der letzten Robotliga habe ich beschlossen, dass unser Bot unbedingt auch über eine Fernbedienung gesteuert werden kann. Nach einigen Stunden im Internet stöbern und jede menge Seiten lesen die sich schon mit dem RC5-Protokoll beschäftigt haben, habe ich beschlossen, das Rad nicht neu zu erfinden, sondern ein fertiges Programm von Roboternetz zu nutzen. Nach anpassen von F_CPU, PRESCALER und eine Erweiterung von usart-Funktioenen, funktionierte es fast auf Anhieb. Bei dem ersten Versuch nahm ich eine Fernbedienung, die nicht das RC5 Protokoll nutzt. Zum Glück hatte ich noch eine alte VCR Fernbedienung gefunden, die funktioniert.
In der Schule beschäftigen wir uns dieses Jahr auch mit Mikrocontroller. Jeder hat sich das myAVR Board bestellt, mit dem wir nun eine Ampel in Assembler programmieren werden. Das einzigste Interesannte an dem Board ist der USB-Programmer. mySmartUSB nennt sich das Teil und hat einen CP2102 Chip. Er wird unter Linux problemlos unterstützt, Wenn man den Treiber im Kernel hat. Wenn nicht, findet man ihn auf folgendem Weg:
Device Drivers - USB supoort - USB Serial converter support - USB CP2101 UART Brigde Controller
Wenn man das Board dann anschliesst, meldet es sich folgendermasen:
Oct 13 16:11:46 ktux kernel: usb 1-1: new full speed USB device using uhci_hcd and address 23
Oct 13 16:11:46 ktux kernel: usb 1-1: Product: CP2102 USB to UART Bridge Controller
Oct 13 16:11:46 ktux kernel: usb 1-1: Manufacturer: Silicon Labs
Oct 13 16:11:46 ktux kernel: usb 1-1: SerialNumber: 0001
Oct 13 16:11:47 ktux kernel: usb 1-1: configuration #1 chosen from 1 choice
Oct 13 16:11:47 ktux kernel: cp2101 1-1:1.0: cp2101 converter detected
Oct 13 16:11:47 ktux kernel: usb 1-1: reset full speed USB device using uhci_hcd and address 23
Oct 13 16:11:47 ktux kernel: usb 1-1: cp2101 converter now attached to ttyUSB0
Oct 13 16:11:55 ktux kernel: usb 1-1: USB disconnect, address 23
Oct 13 16:11:55 ktux kernel: cp2101 ttyUSB0: cp2101 converter now disconnected from ttyUSB0
/dev/ttyUSB0 ist nun das Device, dass bei der Programmersoftware angegeben werden muss.
Ich habe das Ampelprogramm in Assembler und C geschrieben. In C war ich nach 10 Minuten fertig. Für den Assembler Teil habe ich allerdings 2 Tage gebraucht, da ich vorher noch nie etwas in ASM gemacht hatte.
Powered by WordPress
