CableCam mit BL-Gimbal
- Themenstarter Jogijo
- Beginndatum
Stimmt das so?
|---6,5---3/8------1/4------3/8---6,5---| Bohrungen/Gewinde
|--9-|-8,5-|--12,5--|--12,5--|-8,5-|--9-| in mm
|----|-----|-------25--------|-----|----| in mm
|----|-------------42--------------|----| in mm
So habe ich Dich zumindest verstanden.
Noch jemand anderes andere Wünsche?
|---6,5---3/8------1/4------3/8---6,5---| Bohrungen/Gewinde
|--9-|-8,5-|--12,5--|--12,5--|-8,5-|--9-| in mm
|----|-----|-------25--------|-----|----| in mm
|----|-------------42--------------|----| in mm
So habe ich Dich zumindest verstanden.
Noch jemand anderes andere Wünsche?
Zuletzt bearbeitet:
Kann mich bitte mal wer loben? Brauche dringend Streicheleinheiten.
Ich habe beschxxxx 4 Tage gebraucht um den Source Code vom alten STM STD Lib auf die neuen Cube Libraries zu portieren. Keinen Strich mehr Funktionalität, nur das was vorher schon geklappt hat in der Umgebung zum Laufen zu bringen.
Die neue Library ist wirklich besser, aber selbst hier sind so viele Fallstricke eingebaut. Dinge auf die man einfach nicht aufmerksam gemacht wird.
Beispiel gefällig:
Ich verwende zwei Timer Interrupts.
void TIM1_IRQHandler(void)
{
HAL_TIM_IRQHandler(&Tim1HandleServoIn);
}
void TIM3_IRQHandler(void)
{
HAL_TIM_IRQHandler(&Tim3HandleServoIn);
}
Timer3 geht, sobald Timer1 ein Signal bekommt, hängt sich das Board auf.
Warum? Na ja, ganz logisch. Der Interrupt heißt nicht gleich. Bei Timer1 muss der Name TIM1_CC_IRQHandler verwendet werden. So wurde der Interrupt ausgelöst, kein Code der ausgeführt wird, also löscht niemand das Interrupt Bit, als bleibt er für immer in diesem Interrupt Modus stehen.
Man sollte meinen dass solche groben Fehler schon beim Compiler als Fehler ausgegeben werden. Nein, kein Wort. Ein falscher Buchstabe, Groß/Kleinschreibung unterschiedlich, und schon geht gar nichts mehr. Controller hängt.
Als nächstes wird das SBus Protokoll implementiert. Ich denke das müsste leicht eingebaut werden können. So leicht wie man auch die Entwicklungsumgebung upgraded.
Ich habe beschxxxx 4 Tage gebraucht um den Source Code vom alten STM STD Lib auf die neuen Cube Libraries zu portieren. Keinen Strich mehr Funktionalität, nur das was vorher schon geklappt hat in der Umgebung zum Laufen zu bringen.
Die neue Library ist wirklich besser, aber selbst hier sind so viele Fallstricke eingebaut. Dinge auf die man einfach nicht aufmerksam gemacht wird.
Beispiel gefällig:
Ich verwende zwei Timer Interrupts.
void TIM1_IRQHandler(void)
{
HAL_TIM_IRQHandler(&Tim1HandleServoIn);
}
void TIM3_IRQHandler(void)
{
HAL_TIM_IRQHandler(&Tim3HandleServoIn);
}
Timer3 geht, sobald Timer1 ein Signal bekommt, hängt sich das Board auf.
Warum? Na ja, ganz logisch. Der Interrupt heißt nicht gleich. Bei Timer1 muss der Name TIM1_CC_IRQHandler verwendet werden. So wurde der Interrupt ausgelöst, kein Code der ausgeführt wird, also löscht niemand das Interrupt Bit, als bleibt er für immer in diesem Interrupt Modus stehen.
Man sollte meinen dass solche groben Fehler schon beim Compiler als Fehler ausgegeben werden. Nein, kein Wort. Ein falscher Buchstabe, Groß/Kleinschreibung unterschiedlich, und schon geht gar nichts mehr. Controller hängt.
Als nächstes wird das SBus Protokoll implementiert. Ich denke das müsste leicht eingebaut werden können. So leicht wie man auch die Entwicklungsumgebung upgraded.
SBus ist ein schönes Protokoll. Gefällt mir. Auch da natürlich wieder einen Ich-hasse-MicroController Moment gehabt: Was stellt man ein, wenn eine serielle Schnittstelle 8 Datenbits haben soll? Richtig, logischerweise 9 Bits, weil das Parity Bit mit zum Datenregister gehört, die 2 Stopbits aber nicht.
Genau.
Lasst mich das mal ein wenig zusammenfassen.
Aktuell steckst Du den RC Empfänger an die ESC und den Gimbal und steuerst damit die Cablecam und die Blickrichtung.
Diesen Controller kannst Du jetzt dazwischen hängen. Also Empfänger an Controller, der Controller ist mit ESC und Gimbal verbunden. Wobei die Gimbalansteuerung natürlich weiterhin auch direkt über den Empfänger laufen kann.
Am Controller hängt ein Bluetooth Modul und über eine Applikation kann ich dem jetzt verschiedene Aufgaben geben, wie er das Signal vom Empfänger verändern soll. Das wird abgespeichert und ist dann nach dem Einschalten der CableCam das aktive Programm.
Im einfachsten Fall setze ich ihn auf den Modus "Passthrough", d.h. der Controller nimmt die Eingangswerte und gibt sie wieder aus. Als würde er nicht existieren.
Es geht aber auch
* Pass' auf die Endpunkte auf. Ich sage am Sender "Vollgas" und würde daher in den Baum am Ende des Seils krachen. Der Controller ignoriert in so einem Fall den Gashebelund meint "rechtzeitig Bremsen ist wichtiger als die Benutzereingabe". Er errechnet also zu jeder Zeit aus aktueller Position und Geschwindigkeit und Fahrtrichtung ob der Anwender noch rechtzeitig bremsen könnte. Falls sich der Anwender verschätzt, bremst er von selbst.
* Beschleunigungslimiter. Der Anwender gibt aus dem Stand Vollgas, das Antriebsrad dreht durch, der Motor wird extrem beansprucht,.... dabei bin ich nur irrtümlich am Knüppel angekommen. Was der Controller also macht ist, dass er das Signal für die ESC gleichmäßig erhöht, bis das Signal den aktuellen Zielwert erreicht hat. Ergebnis ist also eine sehr schöne und gleichmäßige Beschleunigung.
* Geschwindigkeitslimiter. Fahr nie schneller als..... egal was der Anweder sagt. Keine Ahnung ob das sehr sinnvoll ist. Ich hab' das aber eingestellt wenn man nach dem Einschalten den Endpunkt anfährt. In dieser Phase, wo noch kein Endpunkt festgelegt ist, erlaube ich nur eine geringe Geschwindigkeit.
* Halte die aktuelle Position: Wenn es steil bergab geht und ich lege die Fernsteuerung zur Seite, dann rollt der Wagen langsam hinunter und fährt in das Seil-Ende hinein. Ich muss also die ganze Zeit ein wenig Gas geben, damit der Wagen nicht herunter rollt. Oder ich lasse das den Controller machen.
* Jede sinnvolle Kombination von oben.
In Zukunft lassen sich noch weiter Dinge hinzufügen, etwa
* Egal wo ich gerade bin, der Gimbal soll genau auf einen Punkt in der Landschaft zeigen. Ich kenne ja die Position der Cablecam, also weiß ich um wie viele Grad der Gimbal bewegt werden muss um weiterhin das Motiv im Bild zu haben.
* Zeichne eine Fahrt auf, dann wiederhole sie, wann immer ich es sage, vollkommen automatisch.
Lasst mich das mal ein wenig zusammenfassen.
Aktuell steckst Du den RC Empfänger an die ESC und den Gimbal und steuerst damit die Cablecam und die Blickrichtung.
Diesen Controller kannst Du jetzt dazwischen hängen. Also Empfänger an Controller, der Controller ist mit ESC und Gimbal verbunden. Wobei die Gimbalansteuerung natürlich weiterhin auch direkt über den Empfänger laufen kann.
Am Controller hängt ein Bluetooth Modul und über eine Applikation kann ich dem jetzt verschiedene Aufgaben geben, wie er das Signal vom Empfänger verändern soll. Das wird abgespeichert und ist dann nach dem Einschalten der CableCam das aktive Programm.
Im einfachsten Fall setze ich ihn auf den Modus "Passthrough", d.h. der Controller nimmt die Eingangswerte und gibt sie wieder aus. Als würde er nicht existieren.
Es geht aber auch
* Pass' auf die Endpunkte auf. Ich sage am Sender "Vollgas" und würde daher in den Baum am Ende des Seils krachen. Der Controller ignoriert in so einem Fall den Gashebelund meint "rechtzeitig Bremsen ist wichtiger als die Benutzereingabe". Er errechnet also zu jeder Zeit aus aktueller Position und Geschwindigkeit und Fahrtrichtung ob der Anwender noch rechtzeitig bremsen könnte. Falls sich der Anwender verschätzt, bremst er von selbst.
* Beschleunigungslimiter. Der Anwender gibt aus dem Stand Vollgas, das Antriebsrad dreht durch, der Motor wird extrem beansprucht,.... dabei bin ich nur irrtümlich am Knüppel angekommen. Was der Controller also macht ist, dass er das Signal für die ESC gleichmäßig erhöht, bis das Signal den aktuellen Zielwert erreicht hat. Ergebnis ist also eine sehr schöne und gleichmäßige Beschleunigung.
* Geschwindigkeitslimiter. Fahr nie schneller als..... egal was der Anweder sagt. Keine Ahnung ob das sehr sinnvoll ist. Ich hab' das aber eingestellt wenn man nach dem Einschalten den Endpunkt anfährt. In dieser Phase, wo noch kein Endpunkt festgelegt ist, erlaube ich nur eine geringe Geschwindigkeit.
* Halte die aktuelle Position: Wenn es steil bergab geht und ich lege die Fernsteuerung zur Seite, dann rollt der Wagen langsam hinunter und fährt in das Seil-Ende hinein. Ich muss also die ganze Zeit ein wenig Gas geben, damit der Wagen nicht herunter rollt. Oder ich lasse das den Controller machen.
* Jede sinnvolle Kombination von oben.
In Zukunft lassen sich noch weiter Dinge hinzufügen, etwa
* Egal wo ich gerade bin, der Gimbal soll genau auf einen Punkt in der Landschaft zeigen. Ich kenne ja die Position der Cablecam, also weiß ich um wie viele Grad der Gimbal bewegt werden muss um weiterhin das Motiv im Bild zu haben.
* Zeichne eine Fahrt auf, dann wiederhole sie, wann immer ich es sage, vollkommen automatisch.
So, ab jetzt sind die Gimbal Halterungen der DSLR CableCam mit den beiden 25mm entfernten Bohrungen versehen, damit der Motion Compound Ronin Schnellwechseladapter direkt montiert werden kann.
Jetzt müsste nur noch der Weihnachtsmann, das Christkind und der Osterhase zusammenlegen, damit ich so einen Gimbal auch bekommen würde. :snüff:
Jetzt müsste nur noch der Weihnachtsmann, das Christkind und der Osterhase zusammenlegen, damit ich so einen Gimbal auch bekommen würde. :snüff:
