CableCam mit BL-Gimbal

Dieter hast du unter deiner Cablecam/Kopter/Handheld überall das gleiche BL gimbal oder ist das unterschiedlich?
nutzt du noch die Antennen von Herrmann_s ?
spitzen sachen... muss immernoch an die mk forum anfangstage denken *grins*

grüße
Der Kunde hier hat jetzt ein anderen Brushless Gimbal unter der cablecam. Aber ich denke, nicht mehr lange ;-)
Wir verwenden den Colibri mit kopter, cablecam, Steady, Hovercam etc. ;-)
Hermann_s Antennen haben wir für den normalen Einsatz drauf. Der Kunde hatte einen Live HD Link.
Ja, sind auch schon wieder 7 Jahre her, da hat sich viel getan seit den ersten Flugzeugsperrholz Remote Heads ;-)
 
G

Gelöschtes Mitglied 1973

Gast
hihi die ersten nur mit nick "ausgleich" :D aber hey wenigsten kein rs wie alle anderen ;)
weiter so ! mal schauen wie es in den nächsten 7 jahren aussieht.
die hermann_s antennen sind bis jetzt für mich auch die besten, hab einige industrielle getestet aber da kommt keiner ran bis jetzt ;)

grüße
 

Jogijo

Erfahrener Benutzer
Wie muss ich mir das vorstellen, machst du das dann händisch?
Der Fräser hat einen Anschlag und mit der Positionshöhe bestimmt man wie viel er entgratet oder?
 

yang

Erfahrener Benutzer
Genau so. Die Oberseite per CNC, die Unterseite händisch. Beim Umspannen bekomme ich eine Fehler von ca. 0.2mm und das sieht man beim Entgratfräsen sofort. Daher händisch.
 

Jogijo

Erfahrener Benutzer
Ok, der Fräser steht an einer fixen Position (ich denke jetzt an deine Portalfräse) und du schiebst das Werkstück, welches flach am Tisch aufliegt, händisch zum Fräser?
 
Zuletzt bearbeitet:

yang

Erfahrener Benutzer
Jein. Könnte man so machen aber...

Eigentlich ist diese Maschine dafür vorgesehen:
http://www.fwt-gmbh.de/de/Maschinen...geraete/Kantenentgratgeraet-KEG-250-500W.html


Du hast also die Spindel unter dem Tisch, spannst den Fräser ein und über die Höheneinstellung wird festgelegt wie viel vom Grat man wegnimmt. Man kann niemals unabsichtlich zu viel wegnehmen weil ja der Anlaufzapfen/Kugellager am Fräser ist. Zumindest solange das Frästeil flach aufliegt.

Wie ich es tatsächlich machen werde weiß ich noch nicht. Eine Option wäre eine Oberfräse zu verwenden - wenn die nur verwindungsteifer wäre. Der andere Gedanke ist ein Bohrständer. Man legt das Teil auf den Bohrtisch, senkt den Bohrkopf bis zum eingestellten Anschlag und dann das Werkstück entlang fahren. Auch hier mache ich mir um die Genauigkeit Sorgen.
 

Jogijo

Erfahrener Benutzer
Dann habe ich mir das eh halbwegs richtig vorgestellt, gefällt mir und hätte ich auch gerne.
Ich vermute das man da aber ordentlich Drehzahl braucht damit das gut funktioniert und nicht schlägt. Habe gerade beim originalen Tisch nachgeschaut, ja hat ordentlich Drehzahl das Ding, 11000 bis 30000.
Solche Drehzahlen bringe ich auf meiner großen manuellen Fräse nicht zustande.
Man könnte sich natürlich auch so einen Tisch bauen, ist ja nicht viel dahinter, Motor mit Spannfutter. (und noch ein mögliches weiteres Projekt das nicht fertig wird :) )
In deinem Fall würde ich es wirklich auf deiner Fräse versuchen, ich kann mir schon vorstellen das das funktioniert.
 

yang

Erfahrener Benutzer
Ein paar updates
* Seil ist super
* Seilrolle ebenfalls
* Motor der Seilrolle könnte ein wenig stärker sein. Ich denke wenn ich ihn mit 18V betreiben würde, wäre alles okay. Punkt ist, weder sind 10kg Zugkraft noch 200W oder mehr nötig. Meiner Meinung nach.
* Habe einen 8-fach Seilzug für ein paar Euro bekommen, mit kugelgelagerten Rollen, und verwende dafür 50m vom gleichen Seil. Funktioniert sehr gut, ich würde aber eher einen 6-fach Flaschenzug empfehlen. z.B. die beiden als Paar: http://www.segelservice.com/HS-Kugellagerblock-MICRO-XS-6mm-3-scheibig-mit-Hundsfott.html und http://www.segelservice.com/HS-Kugellagerblock-MICRO-XS-6mm-3-scheibig.html
* PID Regler funktioniert aber das war's dann auch schon. Ich würde ihm ins Arbeitszeugnis schreiben "Er bemühte sich sehr". Das Problem ist die Auflösung, denke ich: Bei einem Brushless Gimbal gibt es 100te von Schritten, beim Fahrtenregler bedeutet 1 Schritt ca. 10cm. Ich habe mit den PID Werten gespielt, ich sage auch dass wenn man dem Zielpunkt auch nur nahe genug ist, dann stoppe hier, aber trotzdem springt die Cablecam immer wieder mal einen Schritt vorwärts oder wieder zurück. Ich kann nicht mit 100% Sicherheit sagen ob nicht doch mit besseren PID Werten ein schöneres Verhalten erreichbar wäre, habe mich aber jetzt 1h lang damit gespielt, mag nicht mehr.

Wahrscheinlich werde ich den WLAN Kontroller entfernen, aus der Nano WII das Serielle Protokoll und den Absolutpositionsgeber-Algorithmus (PID) entfernen und nur die Logik für die maximale Beschleunigung - diesmal per RC Werte - sowie die Endpositionsabschaltung lassen.

Ach ja, ich habe in den letzten Monaten eine zweite CableCam gefräst, die werde ich in den nächsten Tagen bei eBay einstellen. Muss aber erst Fotografieren usw.
 
Zuletzt bearbeitet:

yang

Erfahrener Benutzer
Ich habe jetzt die NanoWii Software entschlackt. Das Abfahren von vordefinierten Profilen gebe ich für's erste auf, weil ich nicht glaube auf einen Qualitätslevel zu kommen mit dem ich zufrieden wäre. Ich fühle mich jetzt bestätigt, dafür müsste man die Steuerungslogik für Absolutpositionen in die ESC direkt einbauen.

Dafür funktioniert jetzt die NanoWii sehr schön. Ich habe das hier mal ohne Seil ausprobiert. Nach dem einschalten gibt man einfach Gas, der Motor beschleunigt langsam (Beschleunigungslimiter erhöht das RC Signal um 0,2ms pro 1/50tel Sekunde, also 10ms pro Sekunde) auf eine niedrige Maximalgeschwindigkeit (RC Signal darf maximal 1500ms + 50ms sein). Und mit dieser Geschwindigkeit fährt man bis ans Seilende.
Dort lässt man die CableCam für 30 Sekunden stehen, damit ist der Endpunkt programmiert. Ab jetzt fährt die Cablecam frei zwischen Startpunkt und programmiertem Endpunkt mit einer maximalen Beschleunigung von 50ms Signalzuwachs pro Sekunde und das Endgeschwindigkeitslimit ist bei 500ms Signalerhöhung.
Mit andern Worten, die NanoWii nimmt mein Signal von der Fernsteuerung und tut so also würde ich langsam den Steuerknüppel nach oben geben und auch langsam wieder in die Mitte.

Gleichzeitig berechne ich immer den aktuellen Bremsweg und sollte ich damit in die Nähe er Start- oder Endposition kommen, dann bremst die CableCam mit der maximal eingestellten Beschleunigung (50ms/Sek) ab.


Der wesentliche Unterschied zu vorher ist das ich das RC Signal als Geschwindigkeit annehme. Wir wissen schon das das nicht stimmt, die Knüppelstellung steuert die Energiezufuhr und erst über Steigung, Widerstand etc wird daraus eine Geschwindigkeit. Dafür ist die Programmierung wesentlich einfacher udn die Bewegung schöner. Schließlich kommt genau das Signal der Fernsteuerung an der ESC an, nur wenn ich zu schnell Gas gebe wird das gedämpft.

Für Fahrten an einem Seil die Böschung hinunter ist dieser Limiter unbrauchbar, dafür wäre die korrekte Weg basierte Regelung geeignet.
 

yang

Erfahrener Benutzer
Kommt darauf an. Stell' Dir vor das Seil ist recht steil. Beim Bergauffahren muss man viel Gas geben, wenn man in Neutralstellung ist, dann rollt der Wagen ganz langsam von alleine herunter. Dank des Limiters könnte es jetzt sein das man gar nicht bergauf fahren kann weil 50ms Signalausschlag nicht reichen. Und herunter fährt sie mit den 50ms mit 50km/h.

Mit dem PID Regler wäre das anders gewesen. Dort hätte man die Sollposition verändert, z.B. Erhöhe die Sollposition jede Sekunde um 1m. Und der PID Regler hätte jetzt alles gemacht um möglichst schnell diese Position einzunehmen. Ich wäre also mit der gleichen Geschwindigkeit sowohl rauf als auch runter gefahren.

Das hat bei normaler Fahrgeschwindigkeit gut geklappt, auch bei langsamer Fahrt, aber im Stillstand ist er immer um die Zielposition hin und her gesprungen. Hüpf. Hüpf. Hüpf. Nervig.

Ich werde demnächst - nur eine Zeitfrage - den Sourcecode hochladen, vielleicht findet jemand ja einen Fehler oder eine Verbesserung. Die Baupläne werde ich ebenfalls hochladen, muss noch ein paar Kleinigkeit kontrollieren.
 

Yups

Erfahrener Benutzer
Kommt darauf an. Stell' Dir vor das Seil ist recht steil. Beim Bergauffahren muss man viel Gas geben, wenn man in Neutralstellung ist, dann rollt der Wagen ganz langsam von alleine herunter. Dank des Limiters könnte es jetzt sein das man gar nicht bergauf fahren kann weil 50ms Signalausschlag nicht reichen. Und herunter fährt sie mit den 50ms mit 50km/h.

Mit dem PID Regler wäre das anders gewesen. Dort hätte man die Sollposition verändert, z.B. Erhöhe die Sollposition jede Sekunde um 1m. Und der PID Regler hätte jetzt alles gemacht um möglichst schnell diese Position einzunehmen. Ich wäre also mit der gleichen Geschwindigkeit sowohl rauf als auch runter gefahren.

Das hat bei normaler Fahrgeschwindigkeit gut geklappt, auch bei langsamer Fahrt, aber im Stillstand ist er immer um die Zielposition hin und her gesprungen. Hüpf. Hüpf. Hüpf. Nervig.

Ich werde demnächst - nur eine Zeitfrage - den Sourcecode hochladen, vielleicht findet jemand ja einen Fehler oder eine Verbesserung. Die Baupläne werde ich ebenfalls hochladen, muss noch ein paar Kleinigkeit kontrollieren.
Hat dein Regler keinen Governermode? So wie es bei den Helis üblich ist? Damit stellst du dann die Drehzahl und der Regler regelt nach.
Falls du einen sensor-regler nutzt, der soweit ich weiss i.d.R. keinen Governermode unterstützt, würde ich einfach versuchen den Hallsensor mit auszuwerten. Dann kannst du dir die Drehzahl recht genau bestimmen und einen PI(D) Controller verwenden. Alles andere wird wie du schon geschrieben hast, bei unterschiedlichen Steigungen und Lasten zu schlechten Ergebnissen führen. Alleine die Position am Seil und der damit verbundene unterschiedliche Durchhang könnte schon problematisch sein wenn man keine Regelung hat.
 
Zuletzt bearbeitet:

yang

Erfahrener Benutzer
Was ich noch nicht verstanden habe, was begrenzt die Auflösung?
Ein Brushless Gimbal Motor hat vielleicht 8 Pole und kann die Stromstärke in 256 Schritten auflösen. Ergibt also pro Umdrehung 2048 Schritte Auflösung.
Ein Antriebsmotor hat drei Hallsensoren, Du has also maximal 120° Auflösung.

Richtig?

Was dann dazukommt ist eben die ESC und deren Steuercharakteristik die ebenfalls nicht linear und nicht stetig ist. Im Bereich um 1500ms sprichts sie gar nicht an, erst wenn man aus dem Neutralbereich kommt legt sie los.


@Yups: Ein Governermode wäre schön, ja. Aber so etwas gibt es nicht. Beim Heli gibt man eine hohe Drehzahl vor, dann läuft die ESC in den Startmodus und versucht diese Drehzahl zu erreichen und halten. Was man damit nicht kann ist
* langsam anfahren, sprich Schritttempo fahren
* bremsen
* retour fahren
* position halten
* usw

Was Du mit Hallsensor auswerten schreibst ist genau das was ich gemacht habe. Wie gesagt, zum Fahren funktioniert das recht gut, fast keine Regelschwankungen wenn man z.B. mit konstanter Geschwindigkeit fahren möchte. Nur beim Position halten ist die Regelqualität wegen der ESC Charakteristik, nicht schön genug.
 

Jogijo

Erfahrener Benutzer
Ok, jetzt verstehe ich auch deinen Wunsch, die Logik und den ESC zu Vereinen, was die Sache aber ganz und garnicht einfacher macht.
 

Yups

Erfahrener Benutzer
Was Du mit Hallsensor auswerten schreibst ist genau das was ich gemacht habe. Wie gesagt, zum Fahren funktioniert das recht gut, fast keine Regelschwankungen wenn man z.B. mit konstanter Geschwindigkeit fahren möchte. Nur beim Position halten ist die Regelqualität wegen der ESC Charakteristik, nicht schön genug.
Ein genauerer Sensor (z.B. optischer inkremental Encoder) würde dir also auch nicht helfen?

Dann musst du dich wohl nach einem anderen Antrieb umsehen:

z.B.

http://www.anaheimautomation.com/pr...ess-motor-item.php?sID=148&pt=i&tID=96&cID=22
http://www.anaheimautomation.com/pr...-item.php?sID=275&serID=1&pt=i&tID=999&cID=23

oder:
http://www.anaheimautomation.com/pr...-item.php?sID=276&serID=3&pt=i&tID=100&cID=23

Finde ich jetzt gar nicht mal besonders teuer.
 
FPV1

Banggood

Oben Unten