Debugging minibot

Manchmal sieht etwas so einfach aus: Schaltplan skizzieren, alles aufbauen und los geht’s. Das dachte ich auch bei meinem neuen Roboter dem minibot. Aber leider bewegten sich die Motoren meines kleinen Bots kein Stück.

Lange suchte ich den Fehler in der neu erstellten Test-Software, die ich (erstmals) in Python programmierte. Insbesondere, da das Monster Moto Shield zur Geschwindigkeitsregelung der Motoren PWM (Pulsweitenmodulation) benötigt. Diese wird mit dem verwendeten Python-Modul GPIO per Software erzeugt. Zum Mitmachen und Suchen des Fehlers hier einmal der verwendete Sourcecode:

#!/usr/bin/python

try:
 import RPi.GPIO as GPIO
except RuntimeError:
 print("Error importing RPi.GPIO! This is probably because you need superuser privileges. You can achieve this by using 'sudo' to run your script")

import time # for sleep

# print some infos
# print GPIO.RPI_INFO

# timings
secs = 5

# init
GPIO.setmode(GPIO.BCM) # use the GPIO names, _not_ the pin numbers on the board

# pins BOARD BCM
motor1A = 17 # Motor 1 A pin 11 = GPIO 17
motor1B = 27 # Motor 1 B pin 13 = GPIO 27
motor1PWM = 22 # Motor 1 PWM pin 15 = GPIO 22
motor2A = 25 # Motor 2 A pin 22 = GPIO 25
motor2B = 8 # Motor 2 B pin 24 = GPIO 8
motor2PWM = 7 # Motor 2 PWM pin 26 = GPIO 7

# speed in percent
motor1speed = 128 # 128
motor2speed = 128 # 128
# PWM duty cycle
motor1dc = 1.0
motor2dc = 1.0

# PWM frequency in Hz
motor1freq = 100
motor2freq = 100

# setup GPIO outputs
print('starting setup...')
GPIO.setup(motor1A, GPIO.OUT)
GPIO.setup(motor1B, GPIO.OUT)
GPIO.setup(motor1PWM, GPIO.OUT)
GPIO.setup(motor2A, GPIO.OUT)
GPIO.setup(motor2B, GPIO.OUT)
GPIO.setup(motor2PWM, GPIO.OUT)

# setup PWM Hz
# pwm1 = GPIO.PWM(motor1PWM, motor1freq)
# pwm2 = GPIO.PWM(motor2PWM, motor2freq)
# neu neu neu
GPIO.output(motor1PWM, GPIO.HIGH)
GPIO.output(motor2PWM, GPIO.HIGH)

# start pwm
print('starting PWM...')
#pwm1.start(motor1dc)
#pwm2.start(motor2dc)

# --- drive ---
print('!!driving forward for ' + str(secs) + ' seconds !!')
# motor 1 forward
GPIO.output(motor1A, GPIO.HIGH)
GPIO.output(motor1B, GPIO.LOW)
# motor 2 forward
GPIO.output(motor2A, GPIO.HIGH)
GPIO.output(motor2B, GPIO.LOW)

# delay x seconds
time.sleep(secs)
 
# --- stop ---
print('motor off...')
# motor 1
GPIO.output(motor1A, GPIO.LOW)
GPIO.output(motor1B, GPIO.LOW)
# motor 2
GPIO.output(motor2A, GPIO.LOW)
GPIO.output(motor2B, GPIO.LOW)
 
# stop pwm
print('stopping PWM...')
# pwm1.stop()
# pwm2.stop()
# neu neu neu
GPIO.output(motor1PWM, GPIO.LOW)
GPIO.output(motor2PWM, GPIO.LOW)

# cleanup
GPIO.cleanup()

 

Und Fehler entdeckt? Nein? Nun, zugegeben, der PWM-Teil wurde zum Testen hier noch „deaktiviert“, bzw. die entsprechenden GPIOs einfach stumpf auf HIGH gesetzt. Da ich der Ursache nicht näher, kam, testete ich nun das verbaute Moto Shield mit einem Arduino.

minibot - Monster Moto Shield-Debugging mit Arduino
minibot – Monster Moto Shield-Debugging mit Arduino

Aber es änderte sich Nichts. Die Motoren sagten keinen Pieps. Also nochmals versucht die Funktionsweise aller Pins genau zu verstehen, und den Aufbau noch weiter vereinfacht: Ein Moto Shield aus einem anderen Roboter ausgebaut, Arduino drunter, Demo-Software auf den Arduino, 6 Volt Motorspannung, Motor angeschlossen: Läuft!

WTF?

minibot - separater Test mit anderem Motor und Arduino
minibot – separater Test mit anderem Motor und Arduino
minibot - Monster Moto Shield-Debugging mit Arduino
minibot – Monster Moto Shield-Debugging mit Arduino

Also musste doch irgendwas in der Verkabelung zwischen Raspberry Pi und Monster Moto Shield falsch sein. Darum noch einmal einen Blick auf den Schaltplan geworfen. PS.: Die Lösung ist hier bereits eingezeichnet:

minibot- Wo war der Fehler im Schaltplan?
minibot- Wo war der Fehler im Schaltplan?

Die Ursache lag an der fehlenden Versorgungsspannung des Moto Shields. Die hier eingezeichneten VCC werden am Moto Shield zusätzlich benötigt und werden nicht über die Motorspannung (hier 6 Volt) erzeugt! Die VCC ist in der Zeichnung als leicht roter Strich zu erkennen.

Und – Tada! – nun fährt der Roboter. Natürlich nicht autonom; einzig die Motoren drehen sich eine gewisse Zeit lang, wie oben aus dem Code ersichtlich. :)

 

[5 Aufrufe]

Abschluss der Verkabelung des minibot

Wie gestern auf Twitter angekündigt, ging es weiter mit der Verkabelung meines neuen minibot. Und das konnte endlich abgeschlossen werden! Der aktuelle Stand soll natürlich wie immer hier dokumentiert werden. Und warum mich ein Nicht-Rastermaß sehr genervt hat, sieht man auch später. Aber der Reihe nach.

Zwei Schaltregler - leider unterschiedlich groß
Zwei Schaltregler – leider unterschiedlich groß

Abschluss der Verkabelung des minibot weiterlesen

[58 Aufrufe]

Neues Jahr, neuer Bot – minibot

Ja, wie das so mit Nachwuchs ist. Man findet erst mal weniger Zeit, für sich und seine Hobbys. Darunter leidet leider auch diese Seite etwas, weil die Prioritäten (hobbymäßig) auf meinen Podcasts Robotiklabor und Reich & Knapp liegen.

Nun war es mit dem letzten Bot irgendwie nicht so richtig weitergegangen und er war ja nun auch wieder etwas groß geraten. Außerdem wollte ich mich bereits seit langer Zeit an ROS (Robot Operating System) wagen.
Der Focus wandert also aktuell etwas weg vom Hardwaredesign, hin zu einer Arbeit bzw. Umsetzung mit bereits existierenden Software-Bibliotheken/-Komponenten. Und mit ROS muss man das Rad nicht komplett neu erfinden, so wie ich es aus Neugierde und Spaß mit der bisherigen direcs-Software bisher tat. Mit allen Vor- und Nachteilen, die letzteres so mit sich brachte.

Ich habe mich nun also in 2017 für ein sehr kleine, fertige Fahr-Plattform entschieden, den RP6 von Conrad – allerdings nur für das nackte Fahrgestell.

Oben drauf soll eine einfach Platine zur Verkabelung und Montage der Sensoren und Elektronik montiert werden. Zur Verwendung kommen voraussichtlich folgende Komponenten

  1. Ein Raspberry Pi („Raspi“) – das Hirn des Roboter.
  2. Ein Hokuyo URG-04LX-UG01 Laserscanner – der vorerst einzige Sensor des Roboters.
  3. Ein Sparkfun Monster MotoShield – zur Ansteuerung der beiden Motoren.
  4. Ein 0815-Schaltregler – zur Erzeugung der notwendigen 5V-Spannung für den Raspi.
  5. Ein Akku – die Stromversorgung für den Roboter.

Ach ja, heißen soll der Roboter – wie immer sehr kreativ ;) – „minibot„.

Wie das Ganze bisher aussieht? Hier wie immer die aktuellen Fotos. Ich bin gespannt über euer Feedback!

minibot mit Schrauben als Platinenhalter
minibot mit Schrauben als Platinenhalter

Neues Jahr, neuer Bot – minibot weiterlesen

[97 Aufrufe]

T-962 kein schlechter SMD-Reflow-Ofen – zumindest nach Hack

SMD-Bauteile lassen sich grundsätzlich selbst von Hand einlöten, aber hier sind meines Erachtens nach gewisse Grenzen. Die Teile und Pinabstände werden immer kleiner, und besonders kleine und damit leichte Teile schiebt man beim Einlöten mit einem Lötkolben leicht weg – kein einfacher Vorgang also.

Auf der Suche nach einem bezahlbaren Hobby-Reflow-Ofen stieß ich auf den T-962 bzw. T962. Ein ziemlich günstiger Ofen aus China, den man bequem und trotz der Ferne sehr schnell Singapur bei Ebay bestellen kann. Für unter 180 € erwarb ich einen solchen Ofen, der innerhalb von 3 Werktagen (offenbar aus einem Lager aus Deutschland) geliefert war!

So, wie der Reflow-Ofen out-of-the-box geliefert wird, sollte er auf keinen Fall in Betrieb genommen werden!

Warum?
T-962 kein schlechter SMD-Reflow-Ofen – zumindest nach Hack weiterlesen

[389 Aufrufe]

Überarbeitung der Deckplattenbefestigung

Bisher war die Deckplatte mit jeweils zwei Schrauben und den dreieckigen Haltern an den Aluprofilen befestigt. Hier besteht aber das Risiko, dass es mehr Möglichkeiten gibt, wo sich etwas lockern kann.

Darum wurden nun 5 mm-Gewinde in die senkrechten Profile gebohrt. Das Ganze lässt das ganze trotz weniger Schrauben wesentlicher stabiler erscheinen. Und hier die Bilder im Detail:

Die Aluprofile mit selbst gemachten 5mm-Löchern
Die Aluprofile mit selbst gemachten 5mm-Löchern

Überarbeitung der Deckplattenbefestigung weiterlesen

[379 Aufrufe]

Eine Zwischenebene für den omnibot

Damit die Elektronik auf dem Bot gut untergebracht werden kann, wurde eine Zwischenebene aus Kunststoff eingebaut. Diese hat außerdem den Vorteil, dass sie nicht-leitend ist. Dadurch können Platinen so ohne Kurzschlussrisiko problemlos montiert werden.

Halter für die Zwischenebene
Halter für die Zwischenebene

Eine Zwischenebene für den omnibot weiterlesen

[206 Aufrufe]

Montage des Laserscanners

Schweren Herzens werden nun nach und nach die Teile des alten Roboters direcs1 „recycled“ und auf den Omnibot hier verbaut. Als erstes der größte und wichtigste Sensor: der Sick Laserscanner.

IMG_6973_small
Gar nicht so leicht aus „freier Hand“ hier die Löcher exakt zu bohren…

Montage des Laserscanners weiterlesen

[304 Aufrufe]