IMUguide noS

Omen est nomen, wie der gemeine Lateiner gerne anzumerken pflegt. So auch hier.

“IMUguide noS” bedeutet nichts anderes, als die Implantierung des IMU-Würfels auf der GUIDE und Wegfall des Servo (was natürlich bedeutet, dass diese GUIDE keinen Tricopter steuern wird).
Das war aber auch nicht Ziel der Übung, sondern ich wollte eine Platine entwerfen, die den abgesetzten IMU-Würfel on board nimmt, nachdem ich in der einschlägigen Presse Veröffentlichungen über den SD746 , einen 6DOF-IMU-Chip, gelesen habe.

Dieser Chip der Firma SensorDynamics enthält drei Drehratensensoren und drei Beschleunigungssensoren, ersetzt also vollkommen die vier im IMU-Würfel enthaltenen Sensoren und ist dabei mal eben 6x6 mm groß.

Nicht ganz trivial ist sicher die Verarbeitung dieses für das Reflow-Lötverfahren vorgesehenen Winzlings mit Hobbymitteln, da auf jeder der vier 6 mm langen Seiten 10 Anschlüsse vorhanden sind. Nach meinen Erfahrungen mit dem Auflöten des Quarzes auf meiner ersten TriGUIDE-Version ist es aber bei entsprechender Vorsicht, einer guten Lupe und einer ruhigen Hand machbar. SMD-Lot und -Lötkolben vorausgesetzt, natürlich.

Ein weiteres Hindernis auf dem Weg des Einsatzes dieses neuen Chip ist dessen Versorgungsspannung.
Die ist mit maximal 3,6 V kleiner als die des Verwendung findenden Atmel Mega328, der mit 5 V Versorgungsspannung betrieben werden will, um die notwendige Taktfrequenz von 16 MHz sicher zu verarbeiten. Es ist also ein Pegelwandler notwendig, der die beiden unterschiedlichen Pegel auf dem zur Kommunikation verwendeten I²C-Bus angleicht.

Hierfür gibt es unterschiedliche Ansätze. Bei Philips (heute NXP), dem “Erfinder” des I²C-Bus, findet sich hierfür eine Schaltung mit zwei FETs und vier Widerständen. Maxim hingegen hat eine IC-Lösung für das Problem auf den Markt gebracht, die den Charme hat, dass bereits alle notwendigen PullUp-Widerstände integriert sind. Das spart enorm Boardfläche, kommt uns also bei der Suche nach einer möglichst kleinen Steuerplatine zu Gute. An dieser Stelle möchte ich meinen Dank an Richard und Günter, zwei nette Kollegen aus dem RoboterNetz-Forum, los werden, die mir zielführende Tipps hierzu gaben.

Nach anfänglichen Schwierigkeiten, alle notwendigen Bauteile überhaupt auf der, mit 27 x 37 mm recht kleinen, vorgesehenen Boardfläche unter zu bringen und einem Zwischenschritt mit zweiseitig entflochtenem Layout, habe ich nach einem Tag konzentrierten Arbeitens eine Platine entworfen, die den Randbedingungen soweit genügt.

IMUguide V2.1 no Servo

Ich musste dafür mehrere Tricks anwenden. Die Stecker sind normale TH-Komponenten (TH = through hole) also durchkontaktierte Bauteile, die von der Unterseite der einseitig entflochtenen Platine eingesetzt werden. Das Gleiche gilt für die beiden Festspannungsregler und eventuell auch für die LED, dazu später mehr.

Die Betriebsspannung für den SD746 ist 3,3 V (maximal 3,6 V). Es gibt auf dem Markt (soweit es Reichelt oder Conrad, meine beiden bevorzugten Bauteilelieferanten, betrifft) allerdings keine Festspannungsregler im TO92-Gehäuse die diese Spannung liefern, weshalb ich auch hier getrickst habe.

Mit zwei in Flussrichtung in Reihe mit dem Masseanschluss des Reglers geschalteten Dioden hebe ich dessen Bezugspotential um die Durchlassspannung der beiden Dioden an, womit seine Ausgangsspannung gegen Masse um den gleichen Betrag steigt. Wir erhalten auf diese Weise eine Spannung von ca. 3,4 V, was der SD746 vertragen sollte. Da der SD746 ab 2,55 V arbeitet, kann alternativ eine der beiden Dioden durch eine Brücke ersetzt werden, der 78L02 gibt dann eine Spannung von ca. 2,7 V ab, was ebenfalls innerhalb der Spezifikation des Bausteins liegt. Der Pegelwandler verarbeitet beides.

Da die Massefläche unterhalb des Chip beim Lötkolbenverfahren nicht angelötet werden kann, ist die Wärmeabfuhr aus dem Chip über diesen Pfad eher nicht gegeben. Ich habe auf Grund des einseitigen Layouts die ursprünglich im Footprint für dieses Gehäuse vorgesehenen Vias innerhalb der Massefläche weg gelassen, die Löcher würden ohnehin keine Wärme auf die andere Platinenseite übertragen.
Unter diesem Gesichtspunkt ist der Betrieb mit der kleineren Spannung zu bevorzugen, wobei man sich fragen darf, ob eine Verlustleistung von ca. 20 mW ausreichen würde, den Chip in Wärmebedrängnis zu bringen.
Das könnte man übrigens vom SD746 selbst erfahren, denn er enthält zusätzlich noch einen Temperatursensor, der über die gewählte Schnittstelle abgefragt werden kann. Allerdings wäre es dann bereits zu spät, denn dann ist er ja schon aufgelötet ;-)

Es sind noch zwei Luftlinien übrig, für deren Verbindung ich, wie schon bei der TriGUIDE smd, Lötpunkte vorgesehen habe.

Ich habe das Layout nach dem genialen Tipp eines interessierten Kollegen noch einmal leicht überarbeitet, so dass jetzt die Fläche unterhalb des IMU-Chip komplett mit Masse belegt ist, wie das vom Hersteller wohl auch vorgesehen ist, obwohl das aus den Unterlagen zum IC nicht eindeutig hervor geht.

IMUguide V2.2 no Servo

Und da ja aller guten Dinge drei sind, habe ich nach erster Kontaktaufnahme mit William noch eine Version entflochten, die für die Kommunikation zu den ESCs und dem IMU -Chip um den Preis einer dritten Luftlinie den Hardware-I²C-Bus des Mega328 verwendet.

IMUguide V2.3 no Servo, Hardware-I²C

Gleichzeitig habe ich noch die Lötpunkte ein wenig gefälliger platziert, das Auge soll ja auch was davon haben, sowie nochmals einige der Verbindungen durch Umplatzierung von Bauteilen optimiert.

Man könnte Stunden damit verbringen, hier und da noch eine Leitung zu verkürzen oder anders zu verlegen und alles noch ein bisschen besser zu machen... aber irgendwann sollte Schluss sein und der Deckel drauf kommen.

So vorbereitet muss jetzt nur noch William Stellung beziehen und seinen Code so umstricken, dass er die IMU-Werte nicht über die Analogeingänge des Mega328 sondern über den I²C-Bus einliest :-)

Als Alternative käme übrigens auch in Frage, die momentan nicht belegten SPI-Pins des Mega328 für die Kommunikation zum SD746 zu verwenden, der spricht nämlich auch SPI. In diesem Fall würden sich IMU-IC und ESC-Daten zumindest auf dem I²C-Bus nicht in die Quere kommen. Dafür müsste ich aber das Layout ändern, und es ist nicht gesagt, dass der Platz reicht, die notwendigen Pegelwandler für die beiden zusätzlichen Leitungen unterzubringen (und die Verbindungen zu legen).

Wie versprochen noch ein Wort zu der LED. Der aufmerksame Leser und potentielle Nachbauer wird sofort gemerkt haben, dass ich die Befestigungslöcher an der Platine “vergessen” habe.
Nun - da alle hohen Bauteile (vordergründig erst mal die Stecker und Spannungsregler) auf der Unterseite der Platine montiert werden, kann man mit zwei Doppelklebebändern mit Schaumgummizwischenlage die Platine sehr gut Kopf über auf dem Deck fest kleben. Damit ist auch eine relativ gute mechanische Entkopplung der Platine vom Multicopter gegeben, was schon beim abgesetzten IMU-Würfel eine gute Maßnahme war.

Setzt man diesen Vorsatz in die Tat um, kann man leider die SMD-LED nicht mehr sehen, sollte sie also tunlichst durch eine bedrahtete Version ersetzen, die von der Unterseite der Platine aus eingesetzt wird. Diese Variante ist im Layout berücksichtigt.

Die Eagle Designfiles im V5.2-Format können hier geladen werden. Es ist die aktualisierte Version des Layout enthalten.

Die Version mit Hardware-I²C-Bus ist hierin enthalten.

Zur Zeit ungeklärt ist,

ob William seinen Code umstellt
ob diese Umstellung gegebenenfalls trägt

Ist das Auslesen der IMU-Werte zeitkritisch?
Entstehen Zeitengpässe im Zusammenspiel mit den ebenfalls über den I²C-Bus versorgten ESCs?
Sind die Messbereiche des SD746 für den gedachten Einsatz adäquat?

ob der Pegelumsetzer von Maxim in Deutschland erhältlich ist
ob die Platine in der angesetzten Größe gefertigt werden kann (teilweise sehr enge Leiterabstände)
ob man den IMU-Chip tatsächlich mit dem Lötkolben auf die Platine bannen kann (und er danach funktioniert)
ob sich der Aufwand lohnt ;-)

Mittlerweile sind zumindest einige der oben in Frage gestellten Punkte geklärt.

William geht einen anderen Weg für die Nano-Lösung seiner xxxGUIDE, die Codeumstellung wird also nicht stattfinden.
Viel wichtiger allerdings: Die maximale Auslesefrequenz des SD746 liegt mit ca. 80 Hz drastisch unterhalb der momentan in der TriGUIDE realisierten Werte, und da ich aus eigener Anschauung weiß, dass selbst eine doppelt so hohe Updaterate der Motorstellwerte (ca. 167 Vorgaben je Sekunde an die ESCs) nur für ein “geht gerade noch so” reicht, ist 80 Hz mit Sicherheit zu langsam.
Mithin stehen alle weiteren Punkte nicht mehr in Frage.

Gestorben ist die Idee, eine winzige Platine mit Onboard-IMU zu verwirklichen aber nicht. Der nächste Ansatz in dieser Richtung, die IMUguide V3, ist auch für einen Tricopter geeignet, die Servoansteuerung wird eingebaut.

Besucher seit
25.11.2000