Kai

Das hört sich gut an. Mein Teensy ist jetzt auch da. Am WE nehme ich mir den auf den Tisch.

espeak -vde "wlan verbunden! ei pie ist: $(hostname -i)" --punct="." espeak -vde "accesspoint gestartet! ei pie ist: $(hostname -i)" --punct="." espeak -vde "wlan aus!"

Der Schalter für das WLAN soll den Modus durchschalten. Jedes Mal wenn der Zustand vom PIN von LOW auf HIGH wechselt wird in den nächsten Modus gewechselt. 1. AUS 2. WLAN-AP 3. WLAN-Client Mal sehen wie man die Überwachung des Schalters macht. Ob man das jetzt am besten mit gpio macht oder doch mit inotify bzw. iwatch die virtuelle Datei des GPIO Ports auf Änderung überwacht. /sys/class/gpio/...

WiringBP installieren apt-get install git-core sudo make gcc libc6-dev libc-dev git clone https://github.com/LeMaker/WiringBP.git -b bananapro cd WiringBP chmod +x build ./bulid Testen: gpio -v gpio version: 2.20 Copyright (c) 2012-2014 Gordon Henderson This is free software with ABSOLUTELY NO WARRANTY. For details type: gpio -warranty Banana Pro Details: Type: Banana Pro, Revision: 1.2, Memory: 1024MB, Maker: LeMaker gpio readall +-----+-----+---------+------+---+--Banana Pro--+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 2 | 8 | SDA.1 | ALT5 | 0 | 3 || 4 | | | 5V | | | | 3 | 9 | SCL.1 | ALT5 | 0 | 5 || 6 | | | 0v | | | | 4 | 7 | GPIO. 7 | IN | 0 | 7 || 8 | 0 | ALT0 | TxD | 15 | 14 | | | | 0v | | | 9 || 10 | 0 | ALT0 | RxD | 16 | 15 | | 17 | 0 | GPIO. 0 | ALT4 | 0 | 11 || 12 | 0 | IN | GPIO. 1 | 1 | 18 | | 27 | 2 | GPIO. 2 | ALT4 | 0 | 13 || 14 | | | 0v | | | | 22 | 3 | GPIO. 3 | ALT4 | 0 | 15 || 16 | 0 | IN | GPIO. 4 | 4 | 23 | | | | 3.3v | | | 17 || 18 | 0 | IN | GPIO. 5 | 5 | 24 | | 10 | 12 | MOSI | IN | 0 | 19 || 20 | | | 0v | | | | 9 | 13 | MISO | IN | 0 | 21 || 22 | 0 | ALT4 | GPIO. 6 | 6 | 25 | | 11 | 14 | SCLK | IN | 0 | 23 || 24 | 0 | IN | CE0 | 10 | 8 | | | | 0v | | | 25 || 26 | 0 | IN | CE1 | 11 | 7 | | 0 | 30 | SDA.0 | ALT4 | 0 | 27 || 28 | 0 | ALT4 | SCL.0 | 31 | 1 | | 5 | 21 | GPIO.21 | IN | 0 | 29 || 30 | | | 0v | | | | 6 | 22 | GPIO.22 | ALT4 | 0 | 31 || 32 | 0 | ALT4 | GPIO.26 | 26 | 12 | | 13 | 23 | GPIO.23 | IN | 0 | 33 || 34 | | | 0v | | | | 19 | 24 | GPIO.24 | IN | 0 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 | | 26 | 25 | GPIO.25 | IN | 0 | 37 || 38 | 0 | IN | GPIO.28 | 28 | 20 | | | | 0v | | | 39 || 40 | 0 | IN | GPIO.29 | 29 | 21 | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+--Banana Pro--+---+------+---------+-----+-----+ Links: http://wiki.lemaker.org/WiringPi http://wiringpi.com

Du musst wohl dazuschreiben über welches Image du schreibst. Bei Bananian ist der /boot Ordner leer. Um an diesen .bin und .fex file ranzukommen musst du da ein mmcblk0p1 device mounten: mount /dev/mmcblk0p1 /mnt dann findest du unter /mnt/fex/BananaPro die Dateien script.bin und script.fex Fex reference: http://linux-sunxi.org/Fex_Guide#FEX_Description

Ich nenne jetzt vorerst so :-) Untertitel: Banana du alte Frucht ich pell dich. GIT Repositiory: git clone http://git.esk8b.de/banana4fun Zip Download: http://git.esk8b.de/banana4fun.zip Jeder der bereits einen GIT Zugang über SSH hat kann auch schreibend auf das Repository zugreifen. Bis her gibt es nur eine Pseudo README und ein Bash-Script für die automatisierte Konfiguration des Bananas. Der Thread hier dient zur Diskussion, Vorschläge und vor allem Mithilfe. Offene Fragen 1. Welches Image nehmen wir am Besten als Basis. In Fragen kommen nur welche die Debian als zurundeliegende Distribution verwenden. Es stehen drei zur Auswahl: Lubuntu, Raspbian oder Bananian. Ich habe als erstes zu Bananian gegriffen aber mir die anderen noch nicht genauer angesehen. Ich glaube aber das Raspbian weiter verbreitet ist, wegen dem Raspberry PI. Ist hier jemand der dazu schon mehr sagen kann? 2. Eigenes Image bootstrapen? Ich bin mir noch nicht schlüssig ob wir ein eigenes Image bauen müssen/wollen oder ob es auch ausreicht unser APT Repository hinzuzufügen und die Konfiguration über apt-get install banana_setup4xxxx auszuführen. Die Entscheidung hängt auch von der Klärung der Frage 1 ab. Bananian ist eine minimal Image und installiert nur was absolut notwendig ist. Das ist schonmal gut. Eigene Images hätte den Vorteil das man es einfach nur runterladen und auf die SD-Karte spielen muss. 3. Für die Web-GUI würde es sich anbieten ein Framework zu verwenden? Kennt da jemand zufällig das Beste wo gibt. Sollte gleich auch für Smartphones was haben und eigene Elemente wie Slider, Gauges und so. 4. Wie kann ich einen Schalter am Banana anschließen und den Status abfragen? Ich möchte drei zustände schalten können. WLAN aus WLAN im AP Mode WLAN in Client Mode (verbinden mit eigenen Netzwerk) ROADMAP so oder so ähnlich sieht meine Roadmap aus. Naja eine richtige Roadmap ist es nicht, eher der Versuch die Entwicklung der Features in eine Reihenfolge zu bringen die Sinn macht. v0.1.0 Grundkonfiguration des Systems (Bash, Tools, Lokalisierung, BananaPro spezifische Einstellungen ...) WLAN Der Banana wird so konfiguriert das er einen AP aufmacht wenn er keine bekannte SSID von einem WLAN-Netzwerk findent für das er als Client konfiguriert ist. Ist man zuhause verbindet er sich automatisch mit dem Heimnetz und hat so auch Internet. GPS Zeitsynchronisation über GPS Geo-Daten auslesbar, vorbereitung für späteres Logging. v0.2.0 Dummy Webinterface Einstellungen des Banana Pros über Webinterface v0.3.0 Anbindung Teensy, Telemetriedaten auslesen und im Webinterface als Live Ansicht anzeigen. Einfache Logging Funktion v0.4.0 Erweitertes Logging. Chronologische Ansicht der gespeicherten Daten. v1.0.0 Alle bisherigen Features funktionieren Stabil. v1.0.0 Konfiguration des Teensy Controllers über CLI v1.1.0 Konfiguration des Teensy Controllers über Web-GUI ... Spielereien wie Hupe über Audio-out mit konfigurierbare Sounddatei. Sprachausgabe ... So der grobe Verlauf, es gibt aber noch ein paar "unbekannte" die in der Roadmap nicht berücksichtigt sind.

Ich habe fürs GIT eine Subdomain git.esk8b.de angelegt und die URL für die GIT Repositories eben geändert. esk8b.de ist die KurzURL für elektro-skateboard.de Die alten GIT-URLs funktionieren noch, sie werden auf die neue URL umgeleitet. Das werde ich aber irgendwann abschalten. Beispiel mit den aktuell vorhandenen Repositories: #Read Only Zugriff über git mit der kompletten History git clone http://git.esk8b.de/test git clone http://git.esk8b.de/Elektroskate_Lib git clone http://git.esk8b.de/Elektroskate_Controller git clone http://git.esk8b.de/Elektroskate_Fernbedienung git clone http://git.esk8b.de/Controller_Nunchuck_Arduino # Download als Zip http://git.esk8b.de/test.zip http://git.esk8b.de/Elektroskate_Lib.zip http://git.esk8b.de/Elektroskate_Controller.zip http://git.esk8b.de/Elektroskate_Fernbedienung.zip http://git.esk8b.de/Controller_Nunchuck_Arduino.zip Für den Zugang mit Schreibrechten über SSH spielt es momentan noch keine Rolle ob als Domain esk8b.de oder git.esk8b.de verwendet wird, da Beides auf die gleiche IP auflöst. Trotzdem solltet ihr die URL für das Remote Repository anpassen. Grund für die Änderung ist eine saubere Struktur, später soll noch apt.esk8b.de hinzukommen für das APT-Repository unsers OpenSource Skateboard Projekts. Allgemeine Fragen zu git können hier gestellt werden. Die Lösungen zu den Fragen kommen dann nach und nach ins Wiki.

http://esk8b.de ist die KurzURL von http://www.elektro-skateboard.de Momentan funktionieren zwei Kurzformen zum Verlinken ins Forum. Eingerichtet ist das schon länger, ich verwendet die KurzURLs zum Beispiel immer für Tweets. Wer möchte kann die Kurzformen auch gerne benutzen. Für Threads: http://esk8b.de/t[0-9] t steht für Thread und [0-9] für die Thread-ID Beispiel: ZielURL: http://www.elektro-skateboard.de/forum/news-5/esk8b-de-kurzurl-[b]3463[/b].php KurzURL: http://esk8b.de/t[b]3463[/b] Für Videos: http://esk8b.de/v[0-9] v steht für Video und [0-9] für die Video-ID Beispiel: ZielURL: http://www.elektro-skateboard.de/forum/videos/mo-bo-3/mobo-breakdance-[b]2[/b].php KurzURL: http://esk8b.de/v[b]2[/b]

Halt uns bitte auf dem Laufenden. und sag Bescheid sobald du ein Statement von Andrew hast. Manchmal ist auch alles anders als es scheint. Aber schon krass das du da aus Amerika einen Brief mit Einladung zum Kreditoren Treffen bekommst :D:D

Ich hab mir die jetzt auch bestellt. Der optische Effekt ist genial und wenn die echt soviel schlucken einfach nur so yeah. @nic-lobo: Woooo hast du die drauf? @flow: Das Video zeigt die Rollen ganz gut: Aber wie machen wir das mit dem Ritzel jetzt? Ohne Motor geht da mal gar nix

Ich möchte mir aktuell zwar kein Bubblegum zulegen aber das interessiert mich trotzdem. Hast ne PN Edit: @barney, sehe ich genau so aber wenn er die Gründe doch nicht öffentlich machen kann hat das offensichtlich einen Grund.

Jeb Ich kümmere mich jetzt erstmal um die Grundeinrichtung des Banana Pro für unsere Zwecke. Dann kommt der Teensy an den Banana Pro dran und es geht an die Umsetzung der Kommunikation zwischen den Beiden. Ich mach am WE einen Thread über den Banana Pro auf, mit meiner favorisierten Roadmap und Überlegungen und Aufrufen zur Mithilfe

Die TupperIdee ist super :thumbsup: Wie gesagt wenn die externe Anbindung an den Teensy über alle Möglichen physikalischen Schnittstellen geht kann jeder flexibel Entscheiden wie er was ankoppeln möchte. Für mich wäre das zu unbequem ein weiteres Teil (plus USB Powerbank)dabei haben zu müssen und das auch noch im Rucksack. Okay es wäre ja nur fürs Loggen und fürs Livemonitoring (nach aktueller Planung), also kann man das auch weglassen, das Board fährt auch so. Bequemer ist es für mich wenn ich einfach das Board einschalte und es automatisch alle Daten speichert, ich bei Bedarf mit dem Handy mal ins Monitoring schauen kann oder auch Einstellungen wie Hase / Igel ... ändern kann.

meine Gedanken... Der BananaPro ist auf keinen Fall die ideale Lösung für unser Projekt, klar. Für mich ist das erstmal egal, den Krams vom Banana Pro auf ein anderes SBC System zu übertragen lässt sich machen. Wir brauchen kein HDMI, kein IR, kein RJ45 .... Ideal wäre ein Single Board Computer ohne all das aber mit einem über i2c oder CAN verbundenen onboard Mikrocontroller. Wenn wir was passenderes finden wird der Banana Pro einfach ausgetauscht. Wichtig sind die Schnittstellen nach außen vom Teensy. Diese sollten über mehrere Wege (BT, UART, i2c ...) laufen, so hat man freie Auswahl ob Kabelgebunden oder über Funk. Schön wäre es wenn wir uns dabei nur über unser Protokoll auf Applikationsebene gedanken machen müssten. Aber das wäre ja zu einfach gewesen ne. Über welche "Kanäle" kommuniziert wird lässt sich dann "einfach" austauschen, das ist das Prnzip des OSI-Schichten Modells. Der Teensy sollte nur die wichtigsten Sachen machen - die zum Fahren notwendig sind und eben auch die Überwachung der Betriebsparameter. Quasi das Fundament bilden. Wenn er sowieso kein Logging macht (keine Daten speichert) braucht er auch nichtmal die genaue Uhrzeit. Die Telemetriedaten können vom angeschlossenen System empfangen werden und mit eigenem Timestamp gespeichert. Ob GPS direkt am Teensy sein muss / kann? Oder ob wir das auslagern? Der Teensy wertet die GPS Daten selbst ja nicht aus, braucht sie auch nicht für irgendwelche Entscheidungen zu treffen, sondern würde sie nur zur Verfügung stellen. Also könnte GPS auch auf das "Logging-System" ausgelagert werden, im aktuellen Fall der Banana. Oder eben das Handy das per BT angekoppelt ist. Rudimentär geht das ja schon oder? Und wer weis ob nicht doch jemand mal native Apps für die Smartphone programmieren will. Wie gesagt wichtig ist nur das vom Teensy die Schnittstellen nach außen wohl definiert sind.

Bei mir läuft alles was den Controller angeht so ziemlich im Blindflug da ich noch keine Hardware hab auf die ich schauen kann. Aber ich bin heiß drauf... Morgen müsste der Banana Pro kommen und dann mach ich mich erstmal an den. Du kannst eigentlich auch erstmal mit dem Sigma, low level brushless Algorithmus, ... ?weitermachen. CAN Canceln, wenn die Pins schon weg sind bleibt ja nix anderes übrig. Ein Bussystem, egal jetzt ob CAN oder i2c hätte gegenüber UART den Vorteil das so viele Teilnehmer wie adressierbar sind das Übertragungsmedium teilen können. Ideal wäre es demnach das für unsere Zwecke beste Bussystem auszuwählen und nur diese Schnittstelle (und Teensy Pins) für die Kommunikation zwischen allen Komponenten zu nehmen. Ob das in der Praxis bereits umsetzbar ist? Vermutlich nicht, ohne alles oder vieles from Scratch zu programmieren. Ob das so ist müssen wir sehen... "CRC hinten dran und gut ist" Ist die Fehlerkorrektur ist dann schon inklusive? Eher nicht oder? Mehr als ein false wird nicht rumkommen wenn der Check fehlschlägt. d.h der Empfänger muss dem Sender mitteilen können das die soeben gesendeten Daten bitte nochmal gesendet werden sollen. Das müsste von uns implementiert werden wenn das nicht schon ein paar Protokollschichten untendrunter transparent gemacht wird. Ein komplettes Protokoll für die Kommunikation neu zu Erfinden macht bestimmt Spass, aber auf bewährtes zurückzugreifen und sich um auf die eigentlich Anwendung zu konzentrieren ist auch nicht schlecht.

Zumindest bei CAN hab ich jetzt auf Wikipedia gelesen das es wie Ethernet auf Layer1 und 2 liegt. Also auch die Datensicherungsschicht. (CRC) I²C wäre laut Wikipedia eher Störungsanfällig. Und da haben wir wie bei UART kein Übertragungsprotokoll. Leider hab ich für den Teensy keine CAN-Lib gefunden: http://www.pjrc.com/teensy/td_libs.html Hier ist der Foren Thread zu Teensy 3.1 und CAN-Bus (hab ich noch nicht gelesen) Edit CANbus Library for Teensy 3.1: https://github.com/teachop/FlexCAN_Library

Okay, für UART, viel besser, kann direkt auf auf die 40Pinleiste gesteckt werden. Können wir versuchen. Es muss aber trotzdem flexible bleiben, zb für die Temperatursensoren die in Unterschiedlicher Anzahl vorhanden sein können. Mit eine festen Länge kommen wir nicht hin, viele feste Längen, wenn wir jeden Wert, oder jedes Key=Value Paar einzeln übertragen. Das treibt den Aufwand um einiges in die Höhe. Auf der Sender und Empfänger Seite. Abwärtskompatibelität ist auch nicht. Einer von der Größe variabler Payload beim Daten-Protokol setzt keine dynamischen Arryas in der Programierung voraus. Dynamisch Speicher allozieren wird aber so oder so nicht ausbleiben. Wenn die Parameter für den Controller über das Webinterface eingestellt und im EEPROM (2048 Bytes) (oder im Flash 256kB - Firmware, wenn das geht) des Teensys gespeichert werden. Zb wenn im Webinterface die Anzahl der TempSensoren und deren Adressen eingetragen werden können. Also momentan sagt mir eine dynamische Paketgröße und JSON noch am meisten zu weil wir damit flexibel sind. Liegt aber auch daran das ich noch nicht weis wo die Reise hingeht Oder auf ein anderes Protokoll setzen welches weniger Störanfällig ist bzw. so nette Features wie CRC unter der Haube hat aber trotzdem nicht zu überladen ist. I2C, SPI, PWM, CAN, I2S, SPDIF, LRADC, ADC, LINE-IN,FM-IN,HP-IN. Das sind die Protokolle die man für die GPIO Ports einstellen kann. Ist da was bei? CAN Bus vielleicht, hat sich in Autos bewährt. Ich komme eher aus der Ethernet TCP/IP Ecke, sorry

Wollen wir für die serielle Kommunikation ein eigenen Datenprotokoll austüfteln oder auf was etabliertes zurückgreifen wie zb Modbus ASCII? Hat da jemand Erfahrung? Für ein Eigenes werfe ich den ersten Entwurf zur Ausarbeitung in den Raum: 2Byte 1Byte 2Byte +---------+-----------+------------+- - - - - - - - - - - - - - - | Go | Format | Länge | Datenblock +---------+-----------+------------+- - - - - - - - - - - - - - - Go: Startflag, Kennzeichnet den Beginn eines neuen Datenblockheaders. x00 xFF oder sowas. Format: gibt den Inhalttyp des Datenblocks an gültige Werte 001 - 255 Beispiele: 000 ungültig 001 API v1 JSON 002 API v1 XML 003 API v1 Eigenes Format X ... 255 API vEndgültigFertig DasLassenWirJetztSoFormat Hier wird nur das Datenformat angegeben. In den Daten selbst kann dann definiert werden um welche Daten es sich handelt. Telemetriedaten, Setupdaten ... Länge: gibt die Länge in Bytes des Datenblocks an gültige Werte 001 - 65535 Bytes Reichen uns 64kByte? Wir könnten auch 4Byte bzw. 32bit nehmen für maximal 4GB große Datenblöcke. Soviel werden wir nie brauchen.

Schau ich mir an wenn es ans programmieren geht... Datenabriss bei der seriellen Übertragung meinst du? Richtige Zeit auf dem "Server" ist wichtig ja. Zumal der auch die Timestamps für die Telemetriedaten etc. setzt. Eine 2023 Knopfzelle kostet 1-2 Euro. Batterie für die RTC muss auf jeden fall rein. NTP Zeitabgleich find ich gut. Kann man automatisiert machen lassen sobald die Banane Internet bekommt. GPS, USB GPS Mouse, kostet ~40 euro. Wenn angeschlossen dann Zeitabgleich. DCF77 USB Adapter 7 € http://dokuwiki.ehajo.de/bausaetze:usb-dcf77 Kann man auch mit reinnehmen in unseren Zeitabgleichspool Smartphone/PC verbunden mit Web-GUI: Zeitgleich über Browser / Jacascript erstmal

Als Datenaustauschformat: JSON http://json.org/json-de.html https://github.com/bblanchon/ArduinoJson

Das stimmt wohl Den Einstieg in die Materie hab ich hier schon verlinkt: http://www.elektro-skateboard.de/forum/showpost.php?p=26384&postcount=527

Genau :thumbsup: Und dann kommt die Update-Funktion ins Webinterface, dann muss man nichtmal mehr in die Konsole. Ob es neue Updates gibt über die Web-GUI prüfen, dann Klick, Updates werden installiert wenn es was neues für das Controllerboard gibt wird das auch automatisch geflasht.

Cool wenn meine Banane da ist gehts los. Du musst mir dann deine bisherigen Errungenschaften, auch wenn's nur experimentell ist zusenden. nginx und mysql setz ich auf und fange mit der Website an. Dafür mache ich auch ein git-repository. Features sollen sein: Möglichst interaktiv und responsibel. Für Smartphones gibt es schöne UI-Libs ... Dann wird es Sinn manchen ein APT-Repository aufzusetzen in dem wir die Pakete zur Verfügung stellen damit sie dann auch einfach über apt-get update; apt-get upgrade aktuell gehalten werden können. Ob es Sinn macht ein komplett eigenes Image für die Banane zu bauen werd ich sehen wenn ich mir das Standard-Image angesehen hab und ob es für unsere Zwecke zu überladen ist.

Roses hatte ich auch schon im Kopf. Genial finde ich das mit dem "Dings4" als Präfix. Gun4Roses, Controller4... Barney, jetzt schon abstimmen? Welche Akronyme wären denn jetzt in der engeren Auswahl. Ist da überhaupt etwas bei mit dem wir leben können?

Im Sitzen, Im stehen, elektrisch und auch im Wasser :cornut: [video=Ball-Rider]440 http://www.ballrider.de Hier noch weitere Videos