Banana Pro & Teensy

[barney]

Ich bin mir momentan recht unsicher, wie das Teensy Projekt weitergehen soll. Eine Idee wäre, die Fernbedienung ohne Schnickschnak zu bauen (einfache BT-Kommunikation) und alle höherwertigen Funktionen im Skateboard mittels WLAN und Webserver anzubieten. Derzeit teste ich einen Banana Pro mit 2 x 1GHz ARM 7 Kernen und 1GByte RAM. Dort soll ein einfacher nginx Webserver laufen, der Grafisch die Fahrdaten aufbereitet und die Konfiguration per Webservice ermöglicht. Damit entfällt die künstlerische Aufgabe mit dem Touch-Display.

Ich habe hier schon sehr gute Eigenbau Controller gesehen, die mit einem Teensy und BT-Modul, LiPo, Buzzer und LEDs kompakt bleiben können.

Die Idee ist ein skalierbares System aus Teensy für die Echtzeitaufgaben und den angedockten Banana Pro für die User Interaktion. Der Banana Pro hat mit dem SD-Card Interface auch später das Logging zu übernehmen. Die Leiterplatte des Banana ist ein Hauch größer als das Teensy Board. Vielleicht eine Revision 3.x die direkt auf den Banana Pro gesteckt wird?

Der Energieverbrauch des Banana Pro liegt bei ca. 1.7 bis 3W. Fällt also unter Messungenauigkeit. Da ich meine Leiterplatte mit dem Teensy weiter verwenden möchte, ist der Banana Pro nur optional anzudocken!

 

Ich bitte um Beiträge und eine Reichhaltige Diskussion

 

Barney

[barney]

Erste Erfolge:

 

Der Banana Pro stellt jetzt mit Nginx die Strom Spannungsberechnung aus dem Wiki bereit. Das es so einfach geht hatte ich nicht gedacht. Jetzt noch einige Fahrdaten generieren und als Grafik anzeigen. Kai! Nicht dein Ding?

[Kai]

Klingt super, auch das alles Modular aufgebaut sein wird.

 

Ich les mich gerade ein wenig in die Echtzeitprogrammierung ein und hab eben das hier entdeckt:

Externe Links nur für Mitglieder sichtbar

RT Kernel für Debian, allerdings für i368 und 64Bit AMD/Intel CPUs und nicht den Cortex A7

 

...Realtime Linux für den Fall auch komplett auf Banana Pro oder einen alternativen SBC gehen zu können.

Für den Modularen Aufbau, wenn Teensy die Echtzeitroutinen macht brauchen wir keinen Realtime Kernel.

Mich interessiert es gerade nur was mit dem Linux Kernel machbar wäre.

Eventuell kann man den Kernel für den Banana mit den rt-Patch selbst kompilieren. Falls der nicht eh schon drin ist.

bearbeitet 8. Februar 2015 von Kai

[barney]

Klingt super, auch das alles Modular aufgebaut sein wird.

 

Ich les mich gerade ein wenig in die Echtzeitprogrammierung ein und hab eben das hier entdeckt:

Externe Links nur für Mitglieder sichtbar

RT Kernel für Debian, allerdings für i368 und 64Bit AMD/Intel CPUs und nicht den Cortex A7

 

...Realtime Linux für den Fall auch komplett auf Banana Pro oder einen alternativen SBC gehen zu können.

Für den Modularen Aufbau, wenn Teensy die Echtzeitroutinen macht brauchen wir keinen Realtime Kernel.

Mich interessiert es gerade nur was mit dem Linux Kernel machbar wäre.

Eventuell kann man den Kernel für den Banana mit den rt-Patch selbst kompilieren. Falls der nicht eh schon drin ist.

 

Mit dem RT-Kernel würde ich nicht soviel Aufwand machen. Dem Banana, Ras oder wie sie alle heißen fehlt es an ADCs, DACs / PWMs. Dafür sind viele Serielle Schnittstellen vorhanden. Ich habe mir die Erweiterungsplatinen für diese Gruppe an SBCs angesehen. Diese werden über den I2C Bus adressiert und ausgelesen. Wenn ich die alle kostenmäßig zusammenrechne, fahre ich mit dem Teensy preiswerter. Ich würde Messaufgaben und Zeitkritische Elemente im Teensy lassen und den Rest ab in den Banana. Die jetzige Teensy Leiterplatte würde anders gelayoutet werden und eine Buchsenleiste zum Banana bekommen. Die Spannungsversorgung würde ich so abändern, dass der Banana mitversorgt wird. Optokoppler, MOSFETs usw. wie gehabt beim Teensy. Aber das ist noch Zukunft, oder mit den jetzigen Teensy-Boards Gegenwart. (Ein Name muss für den Teensy her!)

 

Was erhoffe ich mir: Das jeder eine Domäne findet, wo er sich austoben kann. z.B. das Ankoppeln von GPS wird vereinfacht. Logging mit Auswertung von GPS mit hinterlegten Kartendaten aus OSM ein nettes Feature. Keiner muss ein bestimmtes Handy haben, keine Apps die veralten oder für IOS und Android geschrieben werden müssen. Pures HTML mit Grafiken. Das bekommt jeder Schüler heute hin:D

Schnell mal die Kennlinie für die Fernbedienung verändern. Wie weit komme ich noch? Wäre da ein Klacks.

 

Akkuüberwachung: Wenn der Teensy über den I2C Bus adressiert wird, könnte ein weiterer für die Akku-Überwachung eingesetzt werden. Der Teensy könnte aufgrund der ADCs bis zu 21 Zellen überwachen (ich gehe mal davon aus, das einige Pins wieder doppelt belegt sind). Ein autonomer Balancer wäre damit auch möglich. Das restliche System legt sich schlafen und der Balancer arbeitet weiter, solange das Akku geladen wird.

 

Oder drehe ich frei?

[Kai]

Buggy Programme könnten Probleme mit dem Realtime Kernel Patch machen.

Ein Grund den Patch sein zu lassen.

Und vielleicht reicht es auch einfach schon mit die Software mit nice -20 zu starten

oder mit chrt -f 99

Den 50ms Timer für die Motorsteuerung-Routine einzuhalten sollte ja kein Problem sein, solange parallel kein Youtube-Video in FullHD auf der Banane läuft.

Die Daten vom Nunchuck werden momentan auch nur alle 50ms gepollt.

siehe

Externe Links nur für Mitglieder sichtbar

thread

 

Für mich wäre die Frage noch offen ob ein SBC mit allen nötigen Schnittstellen ok wäre, Preisleistungs, Stromaufnahme und Performancemäßig.

Ich tendiere aber zu der Modularen Lösung

bearbeitet 8. Februar 2015 von Kai

[Beatbuzzer]

Akkuüberwachung: Wenn der Teensy über den I2C Bus adressiert wird, könnte ein weiterer für die Akku-Überwachung eingesetzt werden. Der Teensy könnte aufgrund der ADCs bis zu 21 Zellen überwachen (ich gehe mal davon aus, das einige Pins wieder doppelt belegt sind). Ein autonomer Balancer wäre damit auch möglich. Das restliche System legt sich schlafen und der Balancer arbeitet weiter, solange das Akku geladen wird.

Ginge auch mit nem Attiny26 für bis zu 11S kleiner und sparsamer. I²C hätte der dann auch noch frei, oder SPI oder nen Software-UART.

[barney]

Ginge auch mit nem Attiny26 für bis zu 11S kleiner und sparsamer. I²C hätte der dann auch noch frei, oder SPI oder nen Software-UART.

 

Ja, alles was sich am I²C-Bus anhängen lässt. Aber eine weitere Entwicklungsumgebung? Oder wolltest du eine neue Eigenentwicklung zu diesem Thema hier vorstellen

 

Auch ein MSP430 ist da nicht zu verachten.

[Beatbuzzer]

Oder wolltest du eine neue Eigenentwicklung zu diesem Thema hier vorstellen

Hab ich

Ist aber nur absolutes Minimum für 10S mit Unterspannungs- und Drahtbruchüberwachung, zwei LEDs zur Abschätzung VOLL/HALB/gleich LEER...

I²C und co müsste man da noch nachprogrammieren.

Aber frag mich nicht bis Bremen und auch noch nicht gleich danach, ist grad ziemlich eng

[barney]

Hab ich

Ist aber nur absolutes Minimum für 10S mit Unterspannungs- und Drahtbruchüberwachung, zwei LEDs zur Abschätzung VOLL/HALB/gleich LEER...

I²C und co müsste man da noch nachprogrammieren.

Aber frag mich nicht bis Bremen und auch noch nicht gleich danach, ist grad ziemlich eng

 

Ich will keinen Druck erzeugen, aber her damit, aber sofort! I²C wirst du doch in 10 Minuten reinbekommen.

[barney]

Gestern mit ttyS0 und GP0 herum gespielt. Unter C sieht das bis jetzt ganz O.K. aus. I2C ist als nächstes dran. Danach die Kommunikation mit dem Teensy. Wenn das klappt, würde ich mich wieder nur noch auf den Teensy konzentrieren, ggf. mal ein Probelayout für eine Aufsteckbare Platine anfangen.

 

@Kai:

ich würde dir von einer Ausfahrt eine csv-Datei zukommen lassen. Kannst du mit Nginx diese so aufbereiten, dass nette Grafiken dabei rauskommen? Ich würde gerne sehen, wie sich das mit einem Handy so macht. Vielleicht auch schon eine Konfigurations Seite für die Teensy Parameter. Im Quellcode des Teensys "Custom Parameter" findest du die Werte, die verändert werden können. Sogar mit Einschränkungen im Wertebereich.

[Kai]

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.

[barney]

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.

 

An ein APT-Repository hatte ich auch gedacht. Damit ist die Aktualisierung auch für einen Laien einfach möglich.

[Kai]

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.

[barney]

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:

 

Beim Teensy Flashen müssen wir noch einige Dokumente wälzen.

[Kai]

Das stimmt wohl

Den Einstieg in die Materie hab ich hier schon verlinkt:

Externe Links nur für Mitglieder sichtbar

[barney]

Hallo Kai,

 

anbei ein kleiner Ausschnitt einer gespeicherten Ausfahrt. Ich habe bei den Temperatursensoren ein T1: und T2: vorangestellt. Da nicht jeder die gleiche Anzahl an Sensoren hat. Bei Spannung, Strom, Leistung, Akkumulierte Leistung würde ich entsprechend U:, I:, W:, Wh: voranstellen.

 

Wir sollten bei Datenabriss über ein Start- und Stopp-Symbol sprechen.

 

Ich hatte leider kein größeres Log zur Hand und auch leider keine Temperaturwerte mehr. Ich zeichne mal bald neue auf.

 

Der Banana Pi hat eine RTC onboard, die mit einer Batterie auf Dauerbetrieb umgeschaltet werden kann. Durch NTP und GPS könnte die Zeit automatisch gestellt werden.

 

Spaßsensoren wie 9-Achsen Sensoren würde ich nicht an den Teensy klemmen wollen.

 

Ich suche gerade einen neuen Spannungsregler der genügend A zur Verfügung hat um den Teensy und Banana Pro zu versorgen.

 

Muhahah

 

Barney

Ausfahrt.zip

[Beatbuzzer]

Ich will keinen Druck erzeugen, aber her damit, aber sofort! I²C wirst du doch in 10 Minuten reinbekommen.

Einigt euch erstmal auf ne API, dann sehen wir weiter

 

PS: Zu Wandlern hab ich die hier grad noch im Angebot. Setze ich bei meinem neuen Controller jetzt auch ein:

Externe Links nur für Mitglieder sichtbar

[Kai]

Als Datenaustauschformat: JSON

 

Externe Links nur für Mitglieder sichtbar

[barney]

Einigt euch erstmal auf ne API, dann sehen wir weiter

 

PS: Zu Wandlern hab ich die hier grad noch im Angebot. Setze ich bei meinem neuen Controller jetzt auch ein:

Externe Links nur für Mitglieder sichtbar

 

 

Hi Beatbuzzer,

 

Danke für den Hinweis!

 

Dachte eher an was kleines:

 

Bloß wo herbekommen?

 

Barney

[Beatbuzzer]

Dachte eher an was kleines:

Externe Links nur für Mitglieder sichtbar

Achso. Ich hatte an die Meanwell gedacht wegen der hohen Eingangsspannung bis 72V. Das war doch auch mal ein Thema?!

[barney]

Achso. Ich hatte an die Meanwell gedacht wegen der hohen Eingangsspannung bis 72V. Das war doch auch mal ein Thema?!

 

Ich habe das mit der Spannungsmessung anders gelöst. Mann kann ja irgendwo beim Akku abgreifen. 72V auf 5V runter spannen ist nicht wirklich eine gute Idee.

[Beatbuzzer]

72V auf 5V runter spannen ist nicht wirklich eine gute Idee.

Was meinst Du könnte da Probleme machen?

Ich z.B. gehe per DC/DC von Akkuspannung auf 12V, weil die noch für den Treiber der MOSFET-Ansteuerung nötig sind. Von dort dann für wirklich saubere Spannung linear auf 5V für µC, Funkmodul usw.

 

Willst Du dann wirklich die Versorgung mitten im Akku abgreifen? Wäre bei Teensy + Banana Pro und Wlan, BT usw ja schon ne ganz schöne unsymmetrische Belastung, die bei jedem Laden wieder ausbalanciert werden muss.

Ich denke da jetzt gerade auch an die RC-Pack Fahrer ohne BMS oder die 12S Heli-Stickpack Fahrer, die dann am Balanceranschluss fummeln müssen. Oder aber die inkl BMS eingeschrumpften Li-Packs, wo man gar nicht mehr zwischen die Zellen kommt...

[Kai]

anbei ein kleiner Ausschnitt einer gespeicherten Ausfahrt.

Schau ich mir an wenn es ans programmieren geht...

 

Wir sollten bei Datenabriss über ein Start- und Stopp-Symbol sprechen.

Datenabriss bei der seriellen Übertragung meinst du?

 

Der Banana Pi hat eine RTC onboard, die mit einer Batterie auf Dauerbetrieb umgeschaltet werden kann. Durch NTP und GPS könnte die Zeit automatisch gestellt werden.

 

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 €

Externe Links nur für Mitglieder sichtbar

Kann man auch mit reinnehmen in unseren Zeitabgleichspool

 

Smartphone/PC verbunden mit Web-GUI: Zeitgleich über Browser / Jacascript

 

 

Spaßsensoren wie 9-Achsen Sensoren würde ich nicht an den Teensy klemmen wollen.

erstmal

[Kai]

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.

bearbeitet 11. Februar 2015 von Kai

[barney]

Was meinst Du könnte da Probleme machen?

Ich z.B. gehe per DC/DC von Akkuspannung auf 12V, weil die noch für den Treiber der MOSFET-Ansteuerung nötig sind. Von dort dann für wirklich saubere Spannung linear auf 5V für µC, Funkmodul usw.

 

Willst Du dann wirklich die Versorgung mitten im Akku abgreifen? Wäre bei Teensy + Banana Pro und Wlan, BT usw ja schon ne ganz schöne unsymmetrische Belastung, die bei jedem Laden wieder ausbalanciert werden muss.

Ich denke da jetzt gerade auch an die RC-Pack Fahrer ohne BMS oder die 12S Heli-Stickpack Fahrer, die dann am Balanceranschluss fummeln müssen. Oder aber die inkl BMS eingeschrumpften Li-Packs, wo man gar nicht mehr zwischen die Zellen kommt...

 

Die 75V auf 12V zu reduzieren ist an sich kein Problem. Was wirklich Probleme bereitet ist ein Spannungsbereich von 20-75V auf 12V oder 5V umzusetzen. Da einen kleinen, kompakten und billigen Spannungswandler aufzutreiben sehe ich als Problem an. Und wo liegt hier die Grenze? Du bist mit 75V weit über der Schutzkleinspannungsgrenze. Mit welcher Spannung fährt der nächste? 100V?

 

Aus 12V kann man schöne saubere 5V ableiten. Ich möchte aus 5V 3.3V machen. Das von dir aufgezeigte Modul ist leider definit zu groß für die Allgemeinheit.

 

6V-42V

Externe Links nur für Mitglieder sichtbar

Bis 60V

 

Schon blöd irgendwie!

 

Weiter sehe ich auch das Problem die rippel Spannung im Griff zu bekommen. Von 75V auf 3.3V ohne Umwege? Ich verwende derzeit den Gaptech Wandler, den du mir aufgezeigt hast. Der hat eine nicht unerhebliche Störspannung. Bei einem Stromwandler von +-200A auf 0..3.3V Messspannung flattern einige Bits herum. Für eine präzise Messung nicht so gelungen, aber der Preis und die restlichen Daten sind einfach attraktiv.

 

Ich bin noch auf der Suche. Aber nur bis 60V!