Kai

Auto ist gestopft. Mit Niceday unterwegs nach Bremen.

Das Board wie es hier genannt wurde ist der Prototyp für das spätere StVo-Board. Für die Straßenzulassung ist das Board auf unter 25km/h gedrosselt. Was bedeutet Haftpflichtversicherung ist Pflicht, Helm braucht man nicht. Einen Helm braucht man nach Vaterstaat erst ab 25km/h. Da es noch keine zeitgerechte Version der Mobilitätshilfenverordnung gibt hat sich Carsten gedacht passen wir uns eben, bis es soweit ist, an bestehende Richtlinien an und modifizieren ein Elektro Skateboard so das es zugelassen werden kann. Kurz ausgedrückt, es wird eine eBoard / eRoller Hybrid. Durch das montieren eines "Carving Sticks" wird das Board elektronisch auf ~24km/h gedrosselt. .... ist man dann im "Gelände" kann man den Stick abnehmen und hat die volle Leistung.

Es ist wunderschön :yo:

SBC meinte ich Single Board Computer SOC steht für System-on-a-Chip

Ja das mit der mechanischen Belastung und dem benötigtem Platz ist nicht Ideal. Der Banana Pro ist ja wie gesagt nur eine übergangslösung. Wir brauchen ein SoC mit: - WLAN - Bluetooth - GPIO Ports (i2c, ...) - DEBUG UART - Audio 3,5 Klinke) - MicroSD - USB (ohne Buchsen, nur die Anschlüsse auf der Platine) Hab ich was vergessen? - GPS onBoard wäre auch noch ok.

ist scheinbar nix dabei, also neue Ideen... bebo - barneys eboard osesbo - open source elektro skate board osbo - open source board roflosbo - rolling on floor and laughting open source board

Ja das soll immer verbunden sein, das wäre die Idealvorstellung. Aber richtige Ideal ist das erst wenn wir ein kleiners SoC gefunden haben, ohne die ganzen Schnittstellen die wir nicht benötigen. Das APT-Repsoitory ist soweit online, bisher liegt da nur der Teensy Loader. cat <<EOT > /etc/apt/sources.list.d/apt.esk8b.de.list deb http://apt.esk8b.de/ esk8b-bananian-wheezy main EOT wget -O - http://apt.esk8b.de/gpg.key | apt-key add - apt-get update apt-get install teensy-loader-cli

Ich habe bis heute noch kein Antwort von dem Händler "Preferito" wegen dem defekten Akku bekommen. Falls sich da noch was tut werde ich es berichten, ansonsten bleibt halt nur eine negative Bewertung bei Amazon übrig.

Danke für das Danke Mobokikke Also das ist erstmal ein Test des Danke Buttons. Ein paar Übersetzungen muss ich noch machen, ansonsten sieht das schon ganz gut aus. Sinn des Buttons ist es sich für einen guten Beitrag oder für eine Hilfe im Forum zu bedanken. Man könnte den Button aber auch einfach umbenennen in "gefällt mir" dann wäre der Button universeller einsetzbar. Im Hintergrund wird gezählt wie viele Bedankungen man erhalten hat und wie oft man sich Bedankt hat. Was meint ihr? Danke lassen oder zu gefällt mir verallgemeinern?

Dies ist ein Test für den neuen Danke Button :thumbsup:

Von Schaltplan her sieht es für mich als Laie eigentlich gut aus: http://www.pjrc.com/teensy/schematic.html Wenn oben die zwei Kästen die Pads sein sollen. BT-Stick: Nein, ich brauche ja keinen

So auf die schnelle überflogen find ich auch erstmal nur "Spuren" denen man weiter nachgehen kann. Was ist damit: http://www.pjrc.com/teensy/teensy31_back_pinout.png Rechts oben: Cut to separate VIN from VUSB... Ist das nicht das was wir brauchen?

Ich werde dieses Jahr das erste Mal einen Live-Stream versuchen. :guckstu: http://www.elektro-skateboard.de/live-stream Bis zur Live Übertragung läuft eine Dia-Show von bisherigen Events.

jetzt hab ich's geschnallt Dann nehmen wir beim USB Kabel die Kabel für VBUS und GND raus und gut ist? Und so ein Kabel hast du dir gemacht zum Flashen? Oder trennst du den Teensy vorher vom Barney Board Controller

Flash ich mal spasseshalber heute Abend zuhause...

Das mit den 5V kapier ich nicht was du meinst. Wie schließt du den Teensy denn an den PC an zum flashen?

du sagst Beide aber GPIO erwähnst du nicht 1. BT 2. USB 3. GPIO Serial ok also brauchen wir kein GPIO Serial Port, das ist cool. Das heißt wir können den Teensy Flashen über die USB Verbindung, können die Telemietrie Daten auslesen und können Daten für das Setup der Motorsteuerung an den Teensy senden. Wenn du noch eine Bootloader Jump Funktion einbaust braucht man den Button auf dem Teensy nicht drücken zum Flashen. http://www.pjrc.com/teensy/usb_debug_only.html Dann können wir auch Teensy updates über das Repository ausrollen und automatisiert flashen. 5V Koppeln? Was meinst du damit? USB Port hat doch 5V Betriebsspannung? Ich schon, da der ja alles Loggen soll.

Cool, möchtest du bei der Bananian Konfiguration / Programmierung für das Projekt einsteigen? Für's Flashen ganz normal über USB. Mehr habe ich noch nicht gemacht, also keine Telemetriedaten ausgelesen. @barney wie machen wir das denn jetzt? Sollen wir auf dem Bananapro zwei GPIO Pins zur Kommunikation zw. Teensy und Banana konfigurieren oooder geht das etwa auch über die USB Verbindung?

Klasse Fotos Ralf :thumbsup: Die würden sich im Wiki so als Veranschaulichung in Richtung Best Practices auch gut machen. Und dann sind mir auf der Platine zwei Worte besonders aufgefallen Barney und Board (Fingerzeig für den Namensfindungs Thread)

Das Crius NEO-6 GPS. Ich würde beim nächsten Mal wahrscheinlich eins nehmen mit Timepluse / PPS Ausgang. Das erspart das Anlöten eines extra Kabels. PPS braucht man anscheinend weil die Genauigkeit des Zeitstempels über GPS nicht so toll sein soll. Hab da noch keine Tests gemacht. Das PPS Kabel ist zwar schon angelötet aber ich habe erstmal nur das GPS Signal in den NTPd gebracht. Mal sehen... ob man PPS zwingend braucht. Zuerst das CLI Tool kompliliert und udev rule für den Teensy hinzugefügt. Wie genau steht in gescripteter Form im Abschnitt ###################################### # Teensy Loader ###################################### in der bananian_mod.sh im git Dann hab ich die Beispiele zum Testen runtergelden. In den Teensy laden geht dann so schnelles Blinken: teensy_loader_cli -mmcu=mk20dx128 -v -w blink_fast_Teensy31.hex langsames Blinken: teensy_loader_cli -mmcu=mk20dx128 -v -w blink_slow_Teensy31.hex Usage: teensy_loader_cli -mmcu=<MCU> [-w] [-h] [-n] [-v] <file.hex> -w : Wait for device to appear -r : Use hard reboot if device not online -n : No reboot after programming -v : Verbose output <MCU> = atmega32u4 | at90usb162 | at90usb646 | at90usb1286 | mk20dx128 For more information, please visit: http://www.pjrc.com/teensy/loader_cli.html Für den 3.1er Teensy müsste eigentlich mk20dx256 die richtige Angabe für -mmcu sein. Der Test hat aber auch so funktioniert. Man muss da aber im Hinterkopf behalten und ggfls. den Paul fragen wenn das mit größeren Files probleme machen sollte. Debian Paket für teensy_loader_cli hab ich erstellt, ist im Anhang. Das soll später mal ins Repository rein. dpkg -i teensy-loader-cli_2.1_armhf.deb installiert teensy-loader-cli nach /usr/bin und schreibt die udev rules in /etc/udev/rules.d/49-teensy.rules Hat auch funktioniert als ich die Zustände noch per echo geändert hatte echo "1" > /sys/class/gpio/gpio17/value Als ich den Button angeschlossen hatte änderte sich zwar der Wert aber Inotify bekam das nicht mit. Jetzt hab ich inotifywait -qq -e modify /sys/class/gpio/gpio17/value erstmal ersetzt durch while [ `gpio -g read 17` = 0 ]; do sleep 0.1 done Ist gar nicht schön aber schön wenn man etwas Verbesserungpotential für die Zukunft aufheben kann. ;-) uname -a Linux bananapi 3.4.104+ #1 SMP PREEMPT Thu Jan 8 15:40:40 CET 2015 armv7l GNU/Linux teensy-loader-cli_2.1_armhf.deb

zu meinen Eingangsfragen nochmal: 1. Welches Image nehmen wir Also ich bin immer noch bei bananian weil es ein minimal System ausgeliefert wird. Gute Ausgangsbasis für eigene Anpassungen. Raspbian hatte ich kurz mal gebootet. Da müsste man halt alle Pakete die man nicht möchte "purgen" was aber kein Problem ist wenn man die erst mal festgelegt hat. Lubuntu hab ich mir noch nicht angesehen. 2. Eigenes Image bootstrapen? Meine aktuelle Idee ist es das ein original Image zu nehmen und anzupassen (siehe unten gemu chroot) Das heißt es braucht ein paar Scripte die das original Image automatisiert anpassen. Im GIT ist das aktuelle Script, welches noch eher als Notiz in Bashscript form betrachtet werden soll Ich möchte am Ende ein komplett vorkonfiguriertes Image anbieten sowie die manuelle Installation über das APT-Repository. 3. Für die Web-GUI würde es sich anbieten ein Framework zu verwenden? Es gab und gibt da schon mehrere Projekte für den Raspberry. Sehr tief bin ich da nicht eingestiegen aber Ideal wäre ein Bananian-WebGui das man mit Add-Ons erweitern kann. Diese WebGui wäre dann für das Setup des Systems und für den EBoardcontroller. Eine zweite WebGUI fürs Fahren. 4. Wie kann ich einen Schalter am Banana anschließen und den Status abfragen? Han ich bereits gelöst. Leider erstmal nur mit "Polling" (while schliefe, status abfragen, sleep Kombination) Da das mit inotify und dem sys-fs nicht so funktioniert wie mit richtigen Filesystemen. In der Endfassung soll das noch mit Interuppt gelöst werden. Muss da mal ein Feature request stellen an den WiringPi Entwickler. Er schreibt zwar wie man das Programmiert, hat das aber (scheinbar) in seinem gpio cli tool nicht eingebaut. kurzes Update was bereits funktioniert: - per script Hardware auf bananapro einstellen - Powerbutton fährt Bananian runter (ACPI) - Blinkende Grüne LED abschalten. Blinkt nur noch während dem Booten - wiringBP per script runterladen und kompilieren - GPS Modul - Tracks als .gpx speichern - GPS Modul - Uhrzeit per GPS abgleichen - Soundausgabe - Sprachausgabe - teensy flashen über Shell - wlan umschalten per Script - wlan umschalten per (gpio) Button Das alles muss noch schön ordentlich in .deb Pakete verpackt werden die dann über unser (noch zu erstellende) apt repository geladen werden können. Dazu ein Meta-Paktet das alles in einem Rutsch installiert. wie man angepasste Images erstellen kann hab ich auch schon raus: Mit einem "qemu architectural chroot" Genial simpel. #!/bin/bash BCH=$HOME/banana_chroot mount -t ext4 -o loop,offset=$((512 * 104448)) bananian-1501.img $BCH cp /usr/bin/qemu-arm-static $BCH/usr/bin/ cd $BCH mount -t proc /proc proc mount -o bind /dev dev mount -o bind /dev/pts dev/pts mount -o bind /sys sys chroot . /bin/bash Das reicht um ein chroot auf die root Partition des original bananien Image zu machen und dabei den ARM Prozessor zu emulieren. Das Script ist "vereinfacht" (Offset hardcodiert) und funktioniert mit dem aktuellen 1501 Image. Es wird noch ausgebaut so das es den Offset der Partition zur Laufzeit ausliest und berechnet. Für eine saubere Build-Umgebung habe ich mir Wheezy in einer VirtualBox VM installiert. Noch ein bisschen Feinschliff und Cross-Compiling einrichten, dann werde ich es veröffentlichen. PS: Max Headroom war das coolste was damals lief

So viel geht mit den Bamboo Decks von Mobo und dem original Akkukasten.

Meine sind auch angekommen. Voll kantig :cornut:

Das ist ein absolutes muss :cornut: Gibt es denn schon sowas wie die Oakley Airwaves nur für den Sommer?

Video: https://cloud.esk8b.de/public.php?service=files&t=3aa12c67d01d5b9dcf759020a90c69ff Das Script dazu funktioniert auch schon inkl. Konfiguration der Netzwerkschnittstelle und dem Umschalten des WLAN Mode. Als nächstes mache ich das Setup Script fertig. Modul NEO-6 GPS Modul funktioniert auch. Loggen der Daten im gpx Format auch. Das möchte ich aber noch in mysql bringen damit man es dort zusammen mit den Telemetriedaten abfragen kann.