CableCam mit BL-Gimbal

Mooooment mal: Hast Du Deine Meinung geändert? Irgendwann ganz am Anfang warst Du doch gegen Automation, oder?

* Andere Gimbals: Das sehe ich als trivial an, einfach eine andere Befestigungsplatte fertigen.
* Intelligenz zwischen Empfänger und Regler? Was zum Beispiel? Die Weglängenbegrenzung?
* Automation würde ich nach wie vor am liebsten in der ESC selbst implementieren. Die Hallsensoren auslesen um ein PWM Signal zu erzeugen mit dem der Regler ein Drehfeld erzeugt das über die Hallsensoren kalibriert wird erscheint mir irgendwie von hinten durch die Brust geschossen. Aber egal, mal überlegen.

Ich bräuchte einen Mikroprozessor mit 3 PWM Ausgängen
* ESC
* Pan
* Nick

Er bräuchte 1 bis 3 Digitaleingänge für die Hallsensoren. Interrupt Frequenz müsste mindestens 20'000 Interrupts/sec erreichen können wenn es um eine reine Geschwindigkeitssteuerung geht. Wenn man auch exakt stoppen möchte müsste es 3*20'000 sein


Ich arbeite gerade viel mit einem PIC24FJ256GA110 Board, das auch WLAN kann. Die CableCam würde dann also eine WebSeite bereitstellen über die man per Smartphone/Tablet die Einstellungen vornehmen kann. Dieser Mikroprozessor hat
* 9 PWMs mit 16Bit Auflösung
* 5 Interrupts (3 sind bei dem Board verfügbar)
* 32MHz

Das würde also gehen.....hmmmm......beginnt mir zu gefallen. Was nicht gehen wird ist den Motor am Schrägseil mit ein wenig Gegen-Gas zum stoppen zu bringen. Ein echter Stopp ist nur dann möglich wenn die Motorbremse stark genug ist. Vermute ich mal.

Also, liste einmal auf an was Du denkst wenn Du sagst da soll Intelligenz hinein. Welche Funktionen schweben Dir so vor?

Nein ich war nie gegen Automation, ich war nur dagegen das wir uns die Ziele schon am Anfang so hoch stecken das wir sie alleine nicht erreichen können. Ich habe ja hier auch schon vorgeschlagen das wir für das Thema Steuerung einen eigenen Thread eröffnen, dein Argument, das wir eher ein Randthema sind und uns nicht unnötig ausbreiten sollten, war für mich einleuchtend und daher habe ich das auch wieder verworfen.
Ich denke zur Intelligenz zwischen Empfänger und ESC als erstes mal an eine gedämpfte Beschleunigung, also ein System das selbst bei wilden Befehlen von der Funke nur so beschleunigt wie es sinnvoll und machbar ist, aber das ist nur der Anfang.
Ich finde es nicht sinnvoll ein spezielles ESC zu bauen denn das ESC funktioniert ja gut und macht nichts falsch. Einen eigenen ESC zu bauen oder auch Software für einen bestehenden ESC zu erstellen ist aufwändig und aus meiner Sicht nicht nötig.
Vielmehr benötigen wir eben eine Intelligenz vor dem ESC.
Dazu meine Ideen bzw. Ausbaustufen:
1) gedämpfte Beschleunigung
2) Hallsensor (sollte nicht auf dem Antriebsrad sitzen, denn nur so ist beispielsweise auch eine Antischlupfregelung möglich)
3) Start und Endposition des Schlittens festlegen
4) Pan Fahrt abhängig von der Schlittenposition (stehendes Objekt im Auge behalten)
5) Eigenständige Fahrt mit Pan und Nick auf Knopfdruck

Wie du richtig sagst brauchen wir dazu einen Mikroprozessor mit PWM ein und Ausgängen und was würde sich da eher anbieten als ein Arduino? Warum Arduino, es gibt viele Coder die auf der Platform Ahnung haben, und es gibt haufenweise billige und kleine Hardware in den unterschiedlichsten Ausführungen.
Ich kann verstehen das W-LAN als Steuerung interessant scheint aber das bringt auch Probleme mit sich. Ein 2,4Ghz Sender in unmittelbarer Nähe eines 2,4Ghz Empfängers (Funke) ist keine gute Idee.

Aber wir können halt beide nicht Coden und brauchen Hilfe von anderen die hoffentlich bock drauf haben.

Ich sehe hier einen Widerspruch. Die ersten drei Dinge kann man gut mit einer zwischengeschalteten Elektronik realisieren, korrekt. Die maximale Beschleunigung wird einmal festgeschrieben und nicht mehr geändert, etwa beim Firmware update oder per USB. Und über Schalter an der Fernsteuerung kann man die Start Endposition festhalten. Soweit kein Problem.

Aber wie machst Du die Einstellungen wenn es Richtung Automatisierung geht? Einfach die Bewegung aufzeichnen und dann immer wieder abfahren können, erscheint mir nicht der richtige Weg. Denn das interessante an der Automatisierung ist eben genau das man nicht die gleichen Fahrfehler wiederholt. Dein Punkt 4) ist ein schönes Beispiel dafür. Wenn ich das manuell mache dann wird immer ein rumgewackel sein, mal zu schnelles Pan, dann eine unbeabsichtigte Zwischenbeschleunigung. Da wäre es viel besser eine grafische Oberfläche zu haben, dort den Punkt zu markieren und dann alles mathematisch genau abzufahren. Aber das ist nicht mehr per einfachen Fernsteuerkommandos zu machen. Und vorher per Kabel programmieren erscheint mir zu unhandlich.

Zusammengefasst würde ich also folgende Möglichkeiten sehen
1. Steuerung per Fernsteuerung, Mikrokontroller fungiert als reiner Wächter - Punkt 1-3) von Dir
2. Steuerung nur(!) per WLAN, also weniger für freie Fahrten, sondern komplexe Profile einstellen und automatisiert abfahren lassen.
3. Eine Mischung aus beiden. Per Schalter an der Fernsteuerung kann man das WLAN Modul aus dem Tiefschlaf wecken, die Programierung vornehmen und wieder abschalten wenn man rein über die Fernsteuerung arbeiten möchte.


Ich wäre sofort dafür einen weiteren Drehgeber in eines der Laufräder einzubauen, nur welchen und wie sieht die Mechanik aus? Ich bleibe bei meiner Aussage, bei vernünftiger Beschleunigung ist kein Schlupf vorhanden. Daher wäre es nett den Schlupf zu messen, aber nicht zwingend notwendig. Aber auch das ist eigentlich egal, weil ob man jetzt den Hallsensor vom Motor oder einen externen Sensor abgreift, ändert nichts an der Sache selbst. Diese Fragestellung können wir also zurück stellen. Außer Du hast eine gute Idee wie man einen Sensor billig und einfach in das Laufrad bekommt, weil dann spricht ja nichts dagegen.

Nochmals auf die ESC zurück kommend....

Stell Dir vor die PWM Weite an der ESC ist gerade konstant 2ms und Du misst die Geschwindigkeit, die ist 10m/s. Jetzt möchtest Du die Geschwindigkeit innerhalb von 2s auf 8m/s senken, welche Pulsweite muss dafür eingestellt werden?

Du weißt es nicht, denn die ESC rechnet die Pulsweite in Energiemenge um, nicht in Drehzahl. Du musst also die Pulsweite reduzieren, schauen was passiert und dann dich daran anpassen. Und das binnen ein paar ms um eine schöne und gleichmäßige Fahrt zu erreichen. Der Regelkreis wird sehr mühsam zu realisieren sein.

Wenn man die ESC direkt steuern würde dann würde man die in einem Governer Mode betreiben, also die Pulsweite korreliert mit einer Drehzahl and damit mit einer Geschwindigkeit. Ich müsste nur sagen, reduziere die Pulsweite von 2ms auf 1.8ms linear mit 0.1ms pro sekunde und der Regler steuert das Motordrehfeld entsprechend und ohne Schlupf wäre das auch genau die tatsächliche Geschwindigkeit. Vieeeel einfacher, aber wir würden eine neue ESC benötigen. Da wir die aber mit hoher Wahrscheinlichkeit nicht bekommen, haben wir keine große Wahl.

vielleicht darf ich ein paar mir logisch klingende Gedanken hierzu äußern

Meines Wissens ist Coden können oder nicht können keine genetische Eigenschaft, sondern alle Coder standen irgendwann in Ihrem Leben vor der Situation nicht Coden zu können. Der Unterschied ist also nur, dass die Coder irgendwann Bock hatten das zu lernen. Der Satz könnte daher also z.B. heissen "Aber wir beide haben halt keinen Bock darauf Coden zu lernen und brauchen Hilfe von anderen die hoffentlich bock drauf haben". Das da nicht mehr als ein Achselzucken rausspringt scheint mir nicht ganz unverständlich. Der Satz könnte natürlich auch heissen "Aber wir beide haben voll Bock darauf Coden zu lernen und brauchen nicht auf Hilfe von anderen die hoffentlich bock drauf haben warten."

Nehmen wir jetzt mal an dass jemand der mit Cable-Cams nichts am Hut hat Bock darauf hat etwas für Euch zu schreiben. Stellen sich da nicht Fragen wie: Wie soll der Code getested werden? Es ist extrem uumständlich nur Code zu schreiben ihn aber nicht gleich selber zu testen, oder wenn eine spezielle Funktion rein soll etc. und pp.. Ein weitere Frage: Wie lange hat der Jemand Bock darauf? Wenn ihr nach ner gewissen Zeiot feststellt, ui, das brauchen wir unbedingt noch, glaubt ihr das der Jemand für immer bei der Stange bleiben wird? Der Gang der Dinge scheint mir offensichtlich, Ihr werdet auf einer halbfertigen, halbfunktionierenden Sache sitzen bleiben, die Ihr dann doch irgendwann rausschmeisst weil sie halbfertig ist. Es bleibt Euch also eigentlich nur, Jemanden zu finden der Bock aufs Coden hat UND auf Cable Cams. Nun, schaut euch um...

Ein letzter Gedanke. Der Punkt 1), gedämpfte Beschleunigung, ist (IMHO) tatsächlich ein hervorragendes Anfängerprojekt. Nicht zu schwierig und trotzdem für Euch nützlich. Wie schon festgestellt bietet Arduino hierfür eine hervorrangende Umgebung. Auch wenn im Moment alle nach 32-Bittern schreien, die Atmegas können wirklich sehr viel, schaut Euch nur das Alexmos Board an, oder MultiWii. D.h. Hardware mässig reicht der locker und wird Euch ne ganze Weile locker reichen. Auch Softwaremässig macht es Arduino wirklich sehr leicht, gerade für euren Fall wo es nur einen RC-Eingang und PWM-Ausgang gibt. Der Arduino Uno (Rev 2 oder Rev 3) wäre sehr geeignet, ist größer als ein Nano oder Mini, aber Gewicht/Platz Probleme habt Ihr für den Anfang ja wirklich nicht und der Uno hat den (IMHO) benutzerfreundlichsten Bootloader.

Also, Ihr könnt jetzt die Seiten mit schönen Gedanken und Lamentos füllen, oder Ihr beschafft euch einen Arduino Uno Rev 2 oder Rev 3, gebt eine Woche lang jeden Abend ein Stichwort in Google ein und lest Euch ein, und stellt fest das in der Zeit in der Ihr weiter lamentieren würdet Ihr plötzlich einen Code stehen habt.

Wenn Ihr dann den Quellcode auch noch hin und wieder irgendwo postet, werdet Ihr vielleich sogar Hinweise von Codern bekommen, die zwar keinen Bock darauf haben das ganze Projekt zu entwickeln, aber vieleicht doch die eine oder andere Verbesserungsidee haben...

Ich kann mich natürlich auch täuschen, und Coden können oder nicht können ist doch eine genetische Eigenschaft...

Und ich hatte noch überlegt ob ich diesbezüglich etwas schreiben soll oder nicht. Also doch...

Ich arbeite viel mit Mikrocontrollern, zwar hauptsächlich mit PICs von MicroChip, aber das ist sekundär. Das Coden an sich ist also kein Problem. Wenn es um Platinen geht, das ist der Bereich wo ich meine Komfortzone verlassen. Und wenn eine Platine mit 150A umgehen soll, erst recht. Das ich da etwas in annehmbarer Zeit vernünftig hinbekomme ist mir einfach zu unwahrscheinlich.

Bleibt also die Möglichkeit nicht eine intelligente ESC zu bauen, wie ich eigentlich für sinnvoll erachte, sondern die vorhandene ESC zu steuern. Das werde ich auch machen, aber nicht sofort. Winterferien vielleicht.
Wichtig war mir nur herauszustellen das es nicht nur eine einfache Stell-Regelung ist, sondern eine Rückkopplungsschleife. Stelle einen neuen Wert ein, schau nach wie sich die Geschwindigkeit verändert und benutze diese Information um einen besseren Wert zu einzustellen. Einiges dieser Logik wird dem Hallsensor Iterupt gemacht werden um ein präzises Timing zu haben. Das wird Feintuning erfordern bis es gut funktioniert.

Die viel wichtigere Entscheidung ist was man haben möchte. Per Fernsteuerung fahren und der Mikrocontroller greift korrigierend ein? Per UI einstellbare Fahrprofile? Beides?

Ich würde ein Grove Board mit FlyPort Wifi einsetzen, wenn es nach mir geht. Davon habe ich auch noch welche herumliegen.
http://wiki.openpicus.com/index.php/Grove_Board

nehm mir meine Gedanken bitte nicht übel... sorry wenn ich das falsch verstanden habe

Nein, nein, ganz im Gegenteil! Ich freue mich über jede Rückmeldung, hab' nur ein wenig ein schlechtes Gewissen weil ich das nicht schon vorher klargestellt habe.

Bezüglich Testen wäre ja mein Angebot: Einer verspricht die ESC zu bauen und bekommt dafür eine CableCam von mir. Oder so....

Ich habe mal in meinem Blog alles zusammengefasst. Die einzige Änderung die ich in der letzten Woche gemacht habe ist dass der Akku jetzt doch unter das Seil gewandert ist, sorry Jogi

http://wdaehn.blogspot.de/2013/11/a-different-perspective-filming-with.html

Moin Moin jungs, mal ne allgemeine Frage.

Um vernünftige aufnahmen machen zu können ist mit Sicherheit ein FPV System nötig. Könnt ihr mir eins empfehlen? Hab mal rumgeschaut und mir ist das Immersion RC Set mit 25mW Sender ins auge gefallen...welches Kabel benötige ich außerdem dazu um eine Canon 7D anzuschließen!?

danke schon mal

Servus,

bin durch Zufall auf diesen Thread gestoßen und muss sagen - Hut ab zu dem was bisher steht! Bitte jetzt nicht schlapp machen

Oder auch PID-Regler genannt Und genau hier erhöht sich die Schnittmenge zum Forum. Denn ein FC oder das Gimbal macht auch nichts anderes als durch ständiges messen und korrigieren um vom IST zum SOLL zu gelangen.

Aus Sicht der Softwareentwicklung würde ich mich Jogijo anschliessen und mit "kleinen" Zielen an das Gesamtziel herantasten. Dabei sollte jedes Modul nur so intelligent sein wie es nötig ist um das gewünschte Ziel zu erreichen. Also einem ESC noch weitere Intelligenz zu geben halte ich für zu aufwändig und auch nicht nötig.

1. Ziel
Hier sollte sich lediglich mit der Regelung an sich befasst werden, um die Cable Cam auf eine gewünschte "Geschwindigkeit" zu beschleunigen. Um dabei einen geschmeidigen Übergang zu gewährleisten sollten gewisse Max werte für die Beschleunigung nicht überschritten werden.

2. Ziel
Danach kann man eine etwas intelligentere Schicht entwickeln, die unter Verwendung eines geeignet Sensors (z.B. Hall Sensor) die Position auf der Strecke bestimmt und definierte Punkte nicht überschreitet oder bei Gefälle/Steigung auch die Position halten kann.

3. Ziel
Gespeicherte Strecken-Punkte mit gewünschter Geschwindigkeit anfahren.

Sollten diese Ziele erreicht sein, ist es dann ein leichtes die Wegpunkt Übertragung über wifi, bluetooth oder anderes Funk Modul vorzunehmen.


Beim Board würde ich vorerst auf die Nanowii zurückgreifen, da hier bereits viele Komponenten integriert sind die für das 1. Ziel notwendig sind.

Tja, das ist genau mein Punkt.

Nehmen wir als Beispiel einfach mal nur das Stehen auf einer schiefen Ebene. Bei einem PID Regler messe ich die Geschwindigkeit mit der ich gerade runter rolle und gebe Energie auf den Motor. messe weiter, gebe mehr Energie, .... eben ein Regelkreis.

Wenn ich die Magnetpole des Motors direkt steuern würde, dann würde ich auf eine Spule Energie geben und damit den Motor blockieren und mir den ganzen Regelkreis mit dessen Nachteilen (Zittern, komplex, schwer einzustellen) ersparen.

Das gleiche bei der Geschiwndigkeitssteuerung, dann würde ich das Magnetfeld mit 100Hz drehen und der Motor würde sich mit 100U/sec drehen. Kein Regelkreis notwenig. Alles was ich machen muss sind die Systemgrenzen nicht zu überschreiten, etwa von 0Hz direkt auf 100Hz springen.


Darum hätte ich den Motor gerne direkt gesteuert. Aber da ich keine ESC Hardware bauen kann bleibt mir sowieso nichts anderes übrig.

Hey, nicht hängen lassen...
Ihr schafft das!!!

Da ist überhaupt die Frage ob sich diese beiden Eigenschaften vereinen lassen. Schnell aber auch gleichzeitig so stark das sich die cable cam samt Zuladung nur durch einen magnet pol halten kann.

Ein gimbal hat ja einen speziell gewickelten Motor um diese kraft erzeugen zu können. Aber hier müsste mal ein ESC Experte sine Meinung abgeben.

Okay, mein WLAN Microcontroller kann jetzt 4 Servos steuern, Signalauflösung sind 16'000 Werte zwischen den Endausschlägen bei 1ms und 2ms Pulslänge, Wiederholfrequenz ist 100Hz anstatt der üblichen 50 Stellwerte pro Sekunde.

Realisiert per 16Bit Timer mit 16MHz Zählfrequenz und Timerinterrupt.

Als nächstes implementiere ich eine sehr einfache WebSeite mit der ich die Servos steuern kann und dann wird mal die ESC angeschlossen.

Tja, das war mal ein Schuss vor den Bug.

Prinzipiell funktioniert alles. Ich kann die ESC per WLAN steuern, ich bekomme die Anzahl Schritte und Drehrichtung mit. Daraus kann ich mir die U/min errechnen.

Allerdings wird das so nichts.
1. Ich gebe natürlich +3.3V Signalpulse aus, ein RC Empfänger würde +6V liefern. Die ESC scheint aber nichts dagegen zu haben.
2. Ich vertraue dem Schrittzähler Interrupt nicht. Ich bin mir sicher das wegen der anderen Interrupts und dem RealtimeOS viele Schritte verschluckt werden. Die Schrittgeschwindigkeit scheint sich nicht zu verdoppeln wenn ich die Drehzahl verdopple. Schwer zu sagen ob ich recht habe oder nicht, messen kann ich es ja nicht.
3. Man hört das die Drehzahl nicht konstant ist. Am Speicheroszi sehe ich keine Pulsaussetzer und auch die Pulsweite ist immer gleich. Da vertraue ich aber meinem 200EUR Oszi nicht ob es mir immer alle Pulse anzeigt?


Aktuell weiß ich nicht so recht was ich machen soll.
* Von Interrupts auf Counter umstellen bringt nichts, dann verliere ich die Drehrichtung.
* Ich könnte einen Timer verwenden und ihn im Interrupt auslesen. Das würde die Genauigkeit dramatisch erhöhen, ich darf aber nach wie vor keinen Interrupt verlieren.
* Ein Steuerboard verwenden wie oben mit NanoWii vorgeschlagen. Erhöht die Komplexität weil dann die Kommunikation dazu kommt.
* Bei meiner Hardware bleiben aber mal alles rausschmeissen was nicht notwendig ist, WLAN, RealtimeOS. Ich gehe davon asu das ich das hinbekommen würde, nur dann wäre das mein Steuerboard, verdammt groß für das wenige was ich benötige.
* Analysieren ob ich überhaupt Recht habe und Schritte verliere.

Ich habe mir mal die NanoWii für eine Stunde genauer durchgelesen. Das sind so meine Gedanken:

* Wenn man diese als Steuerboard verwenden würde, könnte man alle Ziele erreichen. NanoWii macht die Auswertung vom Hall Sensor und steuert die ESC. Eingabe könnten entweder RC Signale sein oder serielle Signale von meinem WLAN Board.
* ESC Signal scheint ebenfalls nur 3.3V zu haben
* Software ist Open Source, ich hätte also einen Startpunkt
* Bin nicht 100% sicher ob die Interrupts da klappen werden, ob der schnell genug nach oben zählt.
* Die eingebaute IMU könnte man später für die Steuerung nutzen. Man könnte die Steilheit an der Stelle messen, Pendeln der CableCam erkennen
* Wo würden die Hall Sensor inputs hinkommen? An drei der A0-A3 Pins nehme ich an.
* Sind diese Pins 5V tolerant?
* Können alle drei Pins Interrupts? Oder zumindest einer davon?

Ist halt nichts anderes als ein Arduino das zusätzliche Komponenten für die Multicopter Steuerung On Board hat

Bzgl. der Ein-/Ausgänge gibts hier auch den Schaltplan zum Board:

http://www.multiwii.com/forum/viewtopic.php?f=6&t=1337&start=30#p17031

Habe es mit Option 2 geschafft: Einen Timer im Interrupt Handler auswerten.

Vorher hatte ich nur die Schritte gezählt und das mit dem PWM Takt synchronisiert. Viel zu ungenau.

Jetzt habe ich einen Interrupt Handler für Hallsensor 1 in dem ich einen 16Bit Timer ausliese und dann wieder auf Null setzt. Somit weiß ich ganz genau wie viel Zeit zwischen zwei Interrupts vergangen sind. Der Timer hat einen Prescaler von 256, ich kann also jetzt Werte zwischen 16'000'000/256/1 = 62'500Hz und 16'000'000/256/65536= 0,95Hz, also 3'750'000U/min und 57U/min auf diese Art messen. Alles langsamer erzeugt einen Zählerüberlauf. Ich könnte jetzt zu einem 32Bit Timer wechseln aber so viele habe ich nicht frei und würde das eher gerne vermeiden.
Für so langsame Drehzahlen kann ich genausogut die Werte aus der Realtime Clock im Interrupthandler lesen. Mal sehen.

Wichtig ist, ich verliere keine Interrupts. Ich habe die Timer-Werte gelesen und gleichzeitig einen Frequenzzähler an einem der Hallsensor-Pins dran gehabt, stimmt absolut überein.

Jetzt muss ich mich darum kümmern warum die ESC die Drehzahl hin und wieder für eine Sekunde absenkt. Ich werde mal die PWM Routine von einem Timer auf zwei umstellen.

Möchte mir jemand mit der NanoWii helfen? Ein wenig Code als Starthilfe geben? Ich werde es schon hinbekommen und dank der MultiWii Software habe ich auch eine Referenz, aber die Software hat so viele #DEFINES das mir schon ganz schwindelig ist.

Was ich mir wünschen würde wäre
* NanoWii bekommt auf den Pins D7, D14, D15, D16 ganz normal die aktuellen Werte vom RC Empfänger (PWM)
* Diese Werte werden in ein Array geschrieben
* Auf den Pins 5, 9, 10, 11 werden wieder PWM RC Signale für ESC und die drei Gimbal Achsen ausgegeben
* Die drei Hall Sensoren liegen auf drei beliebigen Pins
* Interrupt auf einen oder alle drei Hall Sensor Pins (entweder steigende oder fallende Flanke)

Wie gesagt, nur falls mir jemand helfen möchte....