Embedded World 2014

Die größte Messe für Embedded Systeme findet jedes Jahr im Februar in Nürnberg statt. Mit sehr knappem Zeitbudget haben wir es geschafft am letzten Tag eine lange Wunschliste mit Ständen von Herstellern, Entwicklungsbüros und vor allem Gadgets zu besuchen.

Adapteva war mit dem Parallella-Board auf der Messe vertreten. Der Stand war gut besucht und die Demos auf den Bildschirmen beeindruckend. Natürlich gab es keine Boards zu kaufen und auch die Backer des erfolgreichen Kickstarter-Projekts gingen leer aus.

Auf dem Adapteva-Board ist neben dem Parallel-Prozessing-Chip Epiphany auch ein Zynq von Xilinx verbaut. Und dieser FPGA mit zwei ARM-Kernen war definitiv der heimliche Star der embedded world 2014. Alle Hersteller mit Platinen auf der Basis eines Zynqs hätten alleine schon die größte Halle füllen können.

Aufgefallen ist uns ein Board mit dem launigen Namen “Gimme2″. Der Hersteller af inventions aus Braunschweig verwendet den Zynq für die Steuerung einer Stereokamera mit zwei 10Mp-CMOS-Chips. Insbesondere für die Robotik ausgelegt verfügt das Board über zwei Gigabit-Ethernet-Ports und zusätzliche I/Os.

Bei dem Stand von Vision Components konnte man andere Lösungen für Kamera-Systeme mit mehreren Bildnehmern ansehen. Basierend auf einem DSP von Texas Instruments können so ohne zusätzlichen CPU-Aufwand beispielsweise 3D-Daten aus einem Zweikamerasystem ermittelt werden.

Ein anderer Hersteller und Reseller von FPGA-Lösungen ist die Firma Bayer DSP Solutions aus Düsseldorf. Eines ihrer interessanten Produkte ist die Xynergy-Reihe. Statt eines SoC mit ARM und FPGA findet sich hier ein Spartan 6 und STM32 Cortex-M4 separat auf einer kleinen Platine mit SO-DIMM-Anschluss.

Der Besuch bei der Firma enclustra aus Zürich hat gezeigt, dass die Boards der Mars- und Mercury-Reihe auch in echt sehr kompakt und gut verarbeitet sind. Die Mars-Boards basieren wiederum auf einem Zynq und die Mercury-Boards haben die vergleichbaren Cyclone-Chips von Altera drauf. Im Prinzip ist er mit dem Zynq vergleichbar. Allerdings brachten mehrere Gespräche auf der Messe zu Tage, dass der Cyclone mit über 100 Gbit/s offensichtlich eine wesentlich höhere Datenrate zwischen den ARM-Prozessoren und dem FPGA-Core bietet. Demgegenüber wurde auf dem Xilinx-Stand gezeigt, wie eine App auf einem Zynq pro Core jeweils 8 GBit/s zum FPGA überträgt.

Keine Hardware zeigte die Firma antmicro aus Poznan. Dennoch war sie gefühlt auf jedem dritten Stand präsent. Das junge Team ist extrem engagiert im Bereich der Betriebssysteme für embedded Systeme. Dabei liegt ihr Fokus auf Open Source Systemen. So portieren sie beispielsweise das freie OS ecos auf die Mars-Reihe von enclustra und auf das oben genannte Parallela-Board. Ihre Software geben sie weitestgehend auf github frei.

Für das Projekt OpenDGPS stellte sich die Firma round solutions aus Neu-Isenburg bei Frankfurt als Goldgrube heraus. Mit Trimble und Telit haben sie zwei Hersteller im Portfolio, die GNSS-Bausteine mit RTK-Funktionalität bieten und auf Genauigkeiten im Zentimeterbereich kommen. In der Pipeline, aber noch nicht verfügbar soll ein Chip mit nur 12mm Größe aus der Jupiter-Reihe sein, der auch die Rohdaten rausgibt. Die aktuell verfügbaren Module beherrschen GPS, GLONASS, GALILEO und QZSS und unterstützen sogar “Jammer recjection”. Mit einem Preis von unter 20€ ist das Modul für OpenDGPS extrem interessant.

Selbst mit unserer beschränkten Zeit war die embedded world in diesem Jahr eine fruchtbare Veranstaltung. Deutlich fiel auf, dass die Zeit der MiniPCs auf der Basis von 8086ern vorbei ist. ARM beherrscht den gesamten Markt und zunehmend werden FPGAs damit gekoppelt. Für alle Arten der Signalverarbeitung – egal ob Audio, Video oder Sensoren – bietet diese Kombination hohe Rechenleistung bei sehr niedrigem Stromverbrauch.

FPGAs und SDR auf dem #30c3

Spannende Vorträge über vier Tage 30C3. Oft auch gleichzeitig.

Spannende Vorträge über vier Tage 30C3. Oft auch gleichzeitig.

Morgen startet der 30C3 mit einigen spannenden Talks. In diesem Jahr liegt der Focus der Veranstalter natürlich noch mehr als sonst auf der permanten Überwachung. Kritisch wird hier selbstverständlich auch die Funktion aller mobilen Geräte die Position permanent zu tracken. Am Samstag findet dazu um 12:45 der Talk “lecture: Glass Hacks” statt in dem Stephen Balaban über Google Glass spricht. Am gleichen Tag um 16:00 beschreibt Felix “tmbinc” Domke in “Script your car” wie man die Firmware seines Autos aufmacht und so auch an die GPS-Daten kommt oder diese modiziert. Einen Tag später um 11:30 berichtet Maria Xynou über die Überwachung in Indien.

Aus technischer Sicht sind mehrere Vorträge über FPGAs interessant: An Tag 2 gibt es um 12:45 einen Talk mit dem Titel “Extracting keys from FPGAs, OTP Tokens and Door Locks” von David Oswald von der Ruhr-Uni Bochum und um 17:15 dann “FPGA 101 – Making awesome stuff with FPGAs” von Karsten Becker (von den Parttimescientists). Am gleichen Tag zu späterer Stunde um 21:45 wird dann ebenfalls von Karsten Becker noch PSHDL vorgestellt, das den Anspruch erfüllen soll, die Programmierung von FPGAs so einfach zu machen, wie die des Arduino.

 

Handgestrickter GPS-Receiver in einem FPGA

Die Bereitschaft der GNSS-Receiver-Hersteller, die Rohdaten zur Verfügung zu stellen scheint sich in letzter Zeit nicht signifikant zu verbessern. Dies muss inzwischen aber niemanden mehr ärgern oder allzu tief in die Tasche greifen lassen. Inzwischen gibt es gute Referenzimplementierungen für selbst gemachte GNSS-Receiver. Den Anfang machte Andrew Holme mit einem Spartan-3-FPGA in Zusammenarbeit mit einem Raspberry Pi.

Die Besonderheit bei diesem Projekt ist die Programmierung des FPGA mit Forth. Sicher keine Allerweltssprache aber für den Zweck hervorragend geeignet. Der Sprachcore passt ohne Probleme in den inzwischen recht kleinen Spartan 3 mit unter 10k Logic Cells. Das Projekt ist ein hervorragender Ausgangspunkt für eigene Entwicklungen.

Basierend darauf hat John Seamons vor kurzem eine eigene Implementierung mit einem Spartan 6 und einem Beaglebone Black gemacht. Der FPGA wäre tatsächlich in der Lage, die Rohdaten aufzubereiten und der Prozessor auf dem Beaglebone hätte genug Power, die Differenzsignale zu berechnen. Die Kosten für eine solche Kombination sind allerdings derzeit noch mit knapp 150€ zu hoch. Spannender könnten dann Systeme sein, die über einen Zynq-Prozessor von Xilinx verfügen. Dieser hat zwei vollwertige ARM-Kerne und einen groß bemessenen FPGA gleich mit drin. Für $15 pro Zynq liessen sich wesentlich kostengünstigere und stromsparende GNSS-Reciever bauen.

 

Messpunkte, Koordinatensysteme, Landesvermessungsämter

Bei einem spontanen Gespräch mit einem Messionar am Strassenrand mitten in Berlin ging es heute schnell um die Frage, ob die Landesvermessungsämter die Koordinaten der Vermessungspunkte zur Verfügung stellen. In einer idealen Welt würden

  • alle Vermessungspunkte bundesweit,
  • über eine einheitliche digitale Schnittstelle,
  • in verschiedenen Koordinatensystemen,
  • kostenfrei und
  • zur kostenlosen Nutzung

verfügbar sein. Ganz offensichtlich leben wir ja nicht in einer idealen Welt und daher ist es nicht verwunderlich, dass einige dieser Wünsche als illusorisch darstellen.

Continue reading

Piksi: 1cm Genauigkeit mit DGPS bei Kickstarter

Piksi Modul (Quelle: swift-nav.com)

Piksi Modul (Quelle: swift-nav.com)

Bei Kickstarter ist vor wenigen Tagen ein Crowdfunding Projekt gestartet, dass sich ideal für OpenDGPS eignen würde. Wenn es nicht viel zu teuer wäre. Mit $900 für zwei Piksi-Module verlangen die Macher fast das zehnfache der Materialkosten. Der Preis scheint aber gerechtfertigt, da schon jetzt die angestrebte Summe von $14.000 weit überschritten ist.

Ein Piksi-Modul besteht aus Antenne, einem Analog-Digital-Wandler, einem Startan-6 (jenem FPGA-Chip auf dem Mojo) und einem ARM Cortex-M4 (STM32F4, über diese günstige CPU hatten wir uns letzte Woche einen Vortrag auf der Makers Faire in Hannover angehört). D.h. Piksi verfügt selbst nicht über einen eigenständigen GNSS-Receiver und stellt damit eine neue Kategorie dar, die man in Zukunft häufiger antreffen dürfte. Zumal das Design mit einem Stromverbrauch von 500mA sehr sparsam ist.

Die Macher von Swift Navigation aus Kalifornien versprechen eine Genauigkeit von bis hinunter zu 1cm. Dabei muss man aber berücksichtigen, dass dazu das Differenzsignal von einer geeichten Feststation kommen muss. Andernfalls gilt diese Genauigkeit nur in Bezug zur Referenzstation. Insofern dürfte es bei einigen Käufern ein böses Erwachen geben. Denn immerhin sind DGPS-Signale noch nicht frei verfügbar.

Interessant ist das Projekt auch, weil sowohl Hardware als auch Software Open Source ist. Damit ist es auch anderen möglich, das Modul nachzubauen und dann bei wesentlich geringeren Kosten zu landen.

[Update] Mit Sicherheit wäre ein Zynq 7010 oder 7020 für das Projekt wesentlich besser geeignet als die Kombination aus Spartan-6 und Cortex-M4. Denn erstens ist darin ein wesentlich leistungsfähigerer ARM-Prozessor drin und zweitens hat der FPGA-Teil bis zu 10 mal mehr Logicelemente. Bei einer Abnahme von x000 Stück kostet eine solche CPU lediglich $15. [Update]

Empfehlung: BeagleBone Black

Das Raspberry Pi hat viel Aufmerksamkeit nicht nur bei den Bastlern erregt und dürfte zu einem Revival der DIY-Elektronik-Szene geführt haben. Und sicher hat es mindestens dafür einen dicken Pluspunkt verdient. Für alles andere verdient das RasPi leider nur befriedigende Noten. Das Layout ist mehr als mangelhaft, die Ausführung ist nur 2- und das Software-Packaging ist schlecht bis unterirdisch.

Gutes Layout und ausgezeichnete Verarbeitung.

Ganz anders das BeagleBone Black. Abgesehen von der sowieso leistungsfähigeren Ausstattung ist das Layout und die Verarbeitung wesentlich besser. Aber vor allem ist die Softwareausstattung und Dokumentation um Welten besser. Auf dem integrierten 2GByte Speicher ist eine lauffähige Ångström-Linux-Distribution installiert. Und: bei der Inbetriebnahme kann man dieses interne Medium direkt an einem Rechner mounten. Über USB kann man darüber hinaus sogar ein Netzwerkinterface anschliessen. Auch Neulinge ohne Erfahrung mit Ethernet und DHCP erreichen so nach wenigen Klicks den integrierten WebServer auf dem BeagleBone.

Ein echtes Highlight ist jedoch Beaglescript. Eine Brücke zwischen JavaScript und dem System. D.h. mit JavaScript kann man auf die Hardware zugreifen und so erste Gehversuche mit den I/O-Ports auf dem Gerät machen.

Überhaupt, die Ports: Mit Dutzenden digitalen und einigen Analogports dürfte das BeagleBone Black das ideale Gerät für Bastler sein. Es gibt bereits jetzt etliche Projekte, die sogenannte Capes entwickeln. Diese Huckepack-Platinen bieten zum Beispiel GPS-, Accelerometer, Magnetfeldsensoren oder Thermometer. Ein schönes Beispiel findet man auf Hipstercircuits. Dort wird beschrieben, wie ein BeagleBone als Controller für einen 3D-Drucker verwendet werden kann.

Mojo – Command-Line statt umständlicher Xilinx ISE

Das Mojo-Board mit einem Xilinx-FGPA Spartan 6 ist nicht nur ein preiswertes und ausgezeichnet gemachtes Stück Hardware sondern eignet sich auch hervorragend als Ergänzung für ein mobiles DGPS-System. Es verbraucht extrem wenig Strom und hat ausreichend Rechenpower, um ein eventuell nötiges Preprocessing der GNSS-Daten durchzuführen. Beispielsweise kann ein FPGA für einen Kalmen-Filter (pdf) – oder ein Complementary Filter – verwendet werden. Neben einem GPS-Receiver lässt sich gleichzeitig an den Analog-Ports auch ein Accelerometer anschliessen.

Allerdings ist der Weg zu einem ersten Programm extrem steinig. Die Xilinx-Suite ist nicht unbedingt die beste Wahl für die Entwicklung der Module. Für die meisten Entwicklungen dürfte sich das sperrige und riesige Paket schlecht in den Workflow integrieren lassen.

Nach etlichen Stunden Recherche steht jetzt eine vernünftige Umgebung: Xilinx läuft unter Linux (in unserem Falle in einer VirtualBox) und das Flashen des Boards findet unter MacOSX auf einem anderen Rechner am Arbeitsplatz statt.

Notwendig dafür war eine Anleitung eines FPGA-Experten, wie man die Xilinx-Commandline-Tools verwendet (pdf). Darin ist neben den Tools selbst auch beschrieben, wie man die notwendigen Shell-Variablen setzen muss und wie man in einem Projekt an die jeweilige Syntax kommt. Es zeigt sich jedoch, dass man eine teils erheblich längere Build-Zeit einkalkulieren muss, oder die Scripte anpassen sollte, da sie immer alle Schritte komplett durchführen auch, wenn sich bestimmte Sachen nicht geändert haben.

Die Überspielung des Bitstreams kann statt mit dem vorgegebenen Mojo-Loader (src), der eine aktuelle JVM voraussetzt auch mit einem Python-Programm erfolgen. Im Mojo-Forum war der User mogorman so nett ein Script zu veröffentlichen, das dies sowohl unter Linux als auch unter MacOSX erledigt. Unter letzterem sollte man noch den Parameter -n hinzufügen, da sich das Script andernfalls mit der Meldung “Flash is not same size as local bitstream.” verabschiedet.

Das Mojo selbst wird von OSX als USB-Modem eingehängt und der serielle Port findet sich immer als /dev/tty.usbmodem*. Wobei der Stern eine dreistellige Ziffer ist. Wer schonmal mit einem Arduino unter OSX gearbeitet hat kennt das bereits. Leider ist nicht klar, wie man das System dazu bringt immer den gleichen Device-Namen zu verwenden. Für den Fall, dass man nur ein entsprechendes Gerät an seinem Rechner hat, kann man folgenden Befehl zum Flashen verwenden:

./mojo.py -v -n -d `ls /dev/tty.usb*` mojo_top.bin

Auf der Mojo-Seite findet sich unter anderem ein Beispielprogramm für die serielle Kommunikation über den AVR auf dem Board. Damit liessen sich die berechneten Daten eines GPS-Recievers und eines Accelerometers problemlos an einen Controller (z.B. RaspberryPi) weitergeben. Auf diesem könnte dann die RTKLIB laufen, die die Daten nicht noch selbst bereinigen müsste.

Wem Verilog als Synthesesprache nicht liegt, der kann das Mojo auch mit VHDL benutzen. Ebenfalls im Forum findet sich ein schöner Beispiel-Code von User Xark, das auch gleich noch verdeutlicht, wie die Analogports benutzt werden können.

Ein Beispiel, wie ein FPGA (hier ein etwas älteres Basys 2 von Diligent für ~€50) mit einem GPS-Receiver zusammenspielen kann hat grade All Programmable Planet beschrieben. In nächster Zeit sollen noch weitere Artikel und Beschreibungen zu dem Projekt kommen.

Hohe Ortungsgenauigkeit als Unterstützung für Blinde

Mobiler GNSS mit DGPS-Verarbeitung für eine Genauigkeit von unter einem Meter auch in städtischen Gebieten. (Quelle: alberding.eu)

Mobiler GNSS mit DGPS-Verarbeitung für eine Genauigkeit von unter einem Meter auch in städtischen Gebieten. (Quelle: alberding.eu)

Einer der sinnvollsten Einsatzzwecke für Ortungsgenauigkeit im Dezimeterbereich ist sicher die Navigationsunterstützung für Blinde und Sehbehinderte. Das Projekt Guide4Blind hat sich zum Ziel gesetzt, Blinde neue Möglichkeiten der Bewegung im Tourismus zu eröffnen. Als eines der spannendsten Ergebnisse ist es dem Projekt gelungen, zusammen mit der Firma Alberding aus Schönefeld bei Berlin einen tragbaren GPS-Empfänger mit DGPS-Unterstützung zur Marktreife zu bringen.

Das Alberding A07 (Produktbeschreibung und Vertrieb) basiert auf dem NV08C und kann mit NTRIP-Daten über eingebautem GPRS umgehen und kommt so auch in bebautem Gebiet auf eine Genauigkeit von unter einem Meter. Über Bluetooth kann es die Positionsdaten an ein iPhone oder Android-Handy schicken. Es unterstützt neben GPS und Glonass auch Galileo.

Sensordaten eines Accelerometers mit Kalman-Filter bereinigen

Das MMA7341L-Modul von Freescale

Das MMA7341L-Modul von Freescale

OpenDGPS hat grade eine kleine Sachspende bekommen: ein 3-Achsen-Accelerometer vom Typ MMA7341L (Technische Daten). Solche Sensoren werden nicht nur in der Robotik eingesetzt sondern sind prinzipiell auch als Eingänge für die RTKLIB geeignet. Allerdings müssen die Sensordaten im Allgemeinen vorher vom Rauschen befreit werden. Etabliert hat sich dafür ein Kalman-Filter. Im Gegensatz zu einem Lowpass-Filter werden nicht einfach nur bestimmte Signalteile abgeschnitten oder gedämpft sondern die Dynamik wird an das jeweilige Messsystem angepasst.

Eine ausführliche Einführung mit Code-Sampels ist auf der Site Interactive Matter Lab zu finden. Beschrieben wird der Einsatz mit einem Accelerometer zwar von einem anderen Hersteller aber ebenfalls mit einem binären Output zwischen 0 und 128 für jede Achse.

Bauanleitung für ein Akkupack

Als Messionar im Ausseneinsatz braucht man Geräte, die eine eigene Stromversorgung mitbringen. Handys und Laptops bringen diese von Haus aus mit. Für eine mobile Messstation auf der Basis eines Raspberry Pis oder vergleichbaren Geräten muss jedoch eine separate Stromversorgung her.

@Faldrian von jenseitsderfenster.de hat eine Bauanleitung für ein externes Akkupack geschrieben und seine Lernklurve beschrieben. In der dritten Iteration scheinen jetzt auch frühere Temperaturprobleme gelöst.

Die Leistung dürfte ein Raspberry Pi mit angeschlossenem GPS-Receiver ausreichende Zeit betreiben können, selbst wenn die Rohdaten nicht nur für die Offline-Berechnung gespeichert werden sondern die Daten direkt bearbeitet werden. Damit eignet sich ein solches Pack als Stromquelle für die Erzeugung eines temporären Diffentialsignals für die Eichung einer neuen Feststation in der Nähe mit Hilfe eines Messpunktes.