-
-
Neuer Benutzer
Öfters hier
Hi Willa,
Erstmal will ich ne Fc1.3 nutzten, die hab ich hier noch liegen.
Ab er ich werde auf alle Fälle auch noch deine Hardware verbauen, da iats ja noch so einiges zu erwarten. Und ich kann selbst Hand anlegen, Basic kann ich
, C nicht.
Die neuen Konverter von dir sehen ja gut aus. Warum keine Jumpe mehr, alles fest in der Hardware?
-
Erfahrener Benutzer
Roboter Genie
ja, es ist einfacher ne neue firmware aufzuspielen als einen Lötjumper zu setzen... Finde ich jedenfalls. Und für die Wiederholrate braucht es auch keinen Jumper, wenn mal jemand nur 50Hz will, muss halt die Firmware angepasst werden.
-
Erfahrener Benutzer
Roboter-Spezialist
Hi Willa,
als ich deine Konverter (die alte Version) das erste Mal gesehen habe, dachte ich spontan, an Stelle des 32-Hufers einen Tiny zu verwenden.
Damals dachte ich noch, dass du für die Komm zur TriGUIDE den Hardware-I2C-Bus verwendest und habe die Idee fallen gelassen.
Inzwischen weiß ich ja, dass zumindest in der TriGUIDE Software für die I2C-Comm verantwortlich zeichnet(e), so dass ich mal kurz darüber nachdachte, den Mega8 auf dem Konverter durch einen Tiny1323 oder was Ähnliches zu ersetzen, der ebenfalls einen PWM-Ausgang hat.
Da so ein 8-Pinner gewisse Einschränkungen in Sachen IOs hat, hatte ich den Plan gefasst, die Parametrierung für die unterschiedlichen Adressen und Updatrates per Analog-Eingang durchzuführen, dafür würde je Freiheitsgrad (Adresse, Rate) ein Eingang reichen. Einfach ein dedizierter Analogpegel für jede Einstellung und fertig.
Mit deiner oben beschriebenen Vereinfachung in Sachen Einstellerei spricht eigentlich nichts mehr gegen die Verwendung der Tinys für die Konverter. Die Platinen werden dann noch kleiner, die Löterei ist Ratzfatz erledigt (8 Pins gegenüber 32) und die Dinger sind auch noch billiger als die Megas.
Das klappt natürlich nur, wenn Bascom I2C per Software auch auf einem Tiny unterstützt. Programmspeicher sollten die Tinys genug haben.
Der ATtiny13A hat 1k Programmspeicher, den ATtiny25 gibt es ab 2k Speicher. Sollte möglich sein, oder?
Nur so als Idee für die nächste Charge an Platinen
-
Erfahrener Benutzer
Roboter Genie
Hallo Harald, daran dachte ich auch als ich die Konverter entworfen habe. Aber leider ging es nicht so einfach, und dann hatte ich keine Lust mehr mich mit dem Tiny rumzuplagen...
Hier gibts einen längeren Beitrag zu meinen damaligen Versuchen:
https://www.roboternetz.de/phpBB2/ze...ag.php?t=51434
-
Erfahrener Benutzer
Roboter-Spezialist
Hi Willa,
ich habe mir den Thread durchgelesen. Exakt meine Ideen, nur 1 Jahr früher, prima 
Kurz vorher hatte ich das (aktuelle) Datenblatt des Tiny25 (kleiner Bruder des 45) durchgeschaut und versucht, alles zum Thema TWI zu verstehen.
Prinzipiell, so habe ich verstanden, hat der tiny25 sowohl Hardware TWI (=I²C) als auch Hardware PWM.
Deinen aktuellen Code für den Mega8 glaube ich in der verbalen Beschreibung aus dem Thread wieder erkannt zu haben. Nur das wirkliche Problem habe ich nicht geschnallt.
Liegt es daran, dass der Tiny nur 8 MHz (mit internem Clock) kann? Oder am 8bit-Timer?
Aber eigentlich reicht mir die Aussage, dass es wohl nicht funktioniert. Du musst nicht nochmal in die Einzelheiten abtauchen, um es auch mir klar zu machen
-
Erfahrener Benutzer
Roboter Genie
Naja, das Problem damals war, dass ich nicht wusste wie man bei einem Tiny Werte per I2C empfängt. Das weiss ich immer noch nicht. I2C ist für mich aber auch ein etwas unverständlicher Hokuspokus. Es geht bestimmt, und hier steht vielleicht sogar wie:
http://www.atmel.com/dyn/resources/p...ts/doc2560.pdf
-
Erfahrener Benutzer
Roboter-Spezialist
Ja, denke ich auch, aber momentan habe ich andere Prioritäten als Atmels programmieren lernen.
Z.B. habe ich gerade versucht, meinen ESCs den Stellbereich meines Fernsteuersenders beizubringen. Der Sender stand dabei auf 150%. Weil die TriGUIDE (bzw. der Konverter) sehr ähnliche Werte ausgibt, dachte ich, das ist der richtige Weg. Leider sind da meine ESCs anderer Meinung, nach Umstellung auf die 150%-Werte haben mich die Kerlchen nur noch böse angepiept und die Zusammenarbeit verweigert.
Erst als die Wege neu mit 100% am Sender eingelernt waren, funktionierte alles wieder wie vorher. Magie, vermute ich 
Nochmal kurz zu Tiny-Konvertern: Verwendest du in den Konvertern jetzt eigentlich eine LIB oder die Hardware des Mega8. Ich vermute Letzteres, denn ich konnte den Code mit der Freeware-Version von Bascom compilieren (vorher den Tippfehler korrigieren) und ich habe gelesen, dass die Software-Slave-LIB Kaufware ist (die ich nicht gekauft habe).
-
Erfahrener Benutzer
Roboter-Spezialist
Ja, denke ich auch, aber momentan habe ich andere Prioritäten als Atmels programmieren lernen.
Z.B. habe ich gerade versucht, meinen ESCs den Stellbereich meines Fernsteuersenders beizubringen. Der Sender stand dabei auf 150%. Weil die TriGUIDE (bzw. der Konverter) sehr ähnliche Werte ausgibt, dachte ich, das ist der richtige Weg. Leider sind da meine ESCs anderer Meinung, nach Umstellung auf die 150%-Werte haben mich die Kerlchen nur noch böse angepiept und die Zusammenarbeit verweigert.
Erst als die Wege neu mit 100% am Sender eingelernt waren, funktionierte alles wieder wie vorher. Magie, vermute ich 
Nochmal kurz zu Tiny-Konvertern: Verwendest du in den Konvertern jetzt eigentlich eine LIB oder die Hardware des Mega8. Ich vermute Letzteres, denn ich konnte den Code mit der Freeware-Version von Bascom compilieren (vorher den Tippfehler korrigieren) und ich habe gelesen, dass die Software-Slave-LIB Kaufware ist (die ich nicht gekauft habe).
Als Nächstes ist die Trimmerei der Horizontalen angesagt. Theoretisch sollte es doch möglich sein, die dazu notwendige Verbindung zwischen PC und TriGUIDE per Funkmodulen herzustellen. Ich habe irgendwo im Thread gelesen, dass du sowas in die Tat umgesetzt hast. Was für Funkmodule hast du dafür verwendet?
Das müssen Module mit UART-Eingang sein, stimmts? Irgend welchen Code in der TriGUIDE um mit z.B. (nicht intelligenten) RFM12-Modulen zu arbeiten hast du sicher nicht implementiert, oder?
-
Erfahrener Benutzer
Roboter-Spezialist
Moin,
so bin wieder zurück aus Ostfriesland...
Hab heute nochm al etwas probiert, nachdem ich das Chassis fertig hatte:
Zu allererst: Willa, danke für den Tipp mit der Funke...
Folgendes Passiert jetzt:
Wenn ich in den Hovermode gehe, dann kippt der Servo schon mal ziemlich weit (von hinten gesehen) nach links, in der Luft muss ich schon voll gegenlenken aber der Tricopter dreht sich trotzdem wie blöde im Kreis.
Wenn ich mit der hand gegenwirke, kippt der Servo schon in die richtigen richtungen um das auszugleichen, die Regelung funktioniert also richtig rum (Der Servo liegt ja bekanntlich bei mir im Center und nicht am drehenden Ende).
Von oben betrachtet drehen sich die Pros wie folgt: VL:CW, VR: CCW, H:CCW der ganze Tricopter rotiert CW, was für den Drehmoment des hinteren Propps spricht, den er nicht ausgleichen kann.
Sollte der servo nicht in Nullposition gehen, wenn ichd en Hovermode aktiviere? also gerade anch oben zeigen? Ich hatte das extra mit dem servo direkt am Empfänger eingestellt...
In den Realtimedaten ist mir wie vorher schon gesagt aufgefallen, das die drehrichtung falschrum ist (habt ihr das auch?) wenn ich Yaw Gyro Reserve anhake dann funktioniert der Servo auch falschrum, das heisst, dass er eine ungewollte drehbewegung noch verstärkt.
[edit]
der Servo Nullpunkt war mal wieder nicht korrekt eingestellt, jetzt gehts besser, ich bin mal kurz draussen: Fliegen!!!!!!!!!!! [/edit]
-
Erfahrener Benutzer
Roboter-Spezialist
Ich bin eindeutig zuviel im Keller, draußen regnets ja in strömen
Stichworte
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- Anhänge hochladen: Nein
- Beiträge bearbeiten: Nein
-
Foren-Regeln
Lesezeichen