Hi,
Nein, der Hauptcontroller schickt seine Werte einfach los und überprüft nicht ob die abgefragt werden. Er wird also nicht langsamer.Die Loop wartet auf eine Antwort auf dem I2C-Bus, richtig?
Kommt da nix, bleibt das Programm dort hängen und wartet.
Ja, da sind nur die Konverter von betroffen. Es ist ja auch egal, der Copter fliegt auch mit dem Tippfehler im Konverter sehr gut. Ich kann mir gut vorstellen, dass man den Unterschied gar nicht merkt. Die Firmware bekommt man mit einem ISP-Programmer auf die Konverter.das betrifft jetzt alles die Firmware der Converter oder?
Wie kriegen wir die denn dann auf die Comverter?
Viele Grüße, William
-> http://william.thielicke.org/
Hi Willa,
gibst du uns bitte Bescheid, wenn du das Konverter-Programm im Blog aktualisisert hast?
Danke!
Die Geschichte mit der Hardware-I2C-Comm interessiert mich. Welche Pins hast du verwendet bzw. umgewidmet?
Ich möchte die nächste Version der TriGUIDE smd entsprechend auslegen, wenn du diese Variante für die Allgemeinheit zugänglich machen willst.
So ich habe mich jetzt dazu entschlossen die Reger in ein Gehäuse an die
Arme zu montieren.
Bild hier
Hier der Regler. Damit man die Status LEDs draußen sieht, habe ich zwei
Zapfen aus transparenten Kunststoff eingearbeitet.
Bild hier
Ein komplett montierter Arm.
Die Kabel sind durch den Arm geführt.
Bild hier
Die Unterseite, das Gehäuse habe ich mit Schmirgellein abgeschliffen.
Meint Ihr, ich sollte den Reglern ein paar Luftlöcher im Gehäuse spendieren?
Ich habe noch keine Erfahrung wie warm die Regler werden.
Gruß Ingo
Meine Webseite
http://www.pc-braunschweig.de
huhu,Zitat von deHarry
da A4 und A5 die nativen I2C pins sind, tipp ich mal auf A6 und A7 per Kupferlackdraht direkt vom atmega geholt.
@willa: hast du schonmal drüber nachgedacht einen ACC per spi anzuschließen? dann könnte man sich den Kupferlackdraht sparen, hätte hardware I2C und sogar noch ne ACC-achse mehr falls du die vllt. in zukunft einbauen willst:
Batterieüberwachung, Gyro-x, Gyro-y, Gyro-z auf A0...A3;
I2C für Motorregler auf A4 und A5;
SPI für ACC auf 10-13;
viele grüße
amigo
Hallo Leute,
wir (Rasmus, Robert und ich - aus Hamburg, Münster und Bremen) wollen uns ein Quadrocopter auf Wiliams Basis bauen. Wir sind drei Laien und wollen uns je ein Quadcopter bauen. Erstmal einaml um zu fliegen und dann vieleicht daran herum zu tunen
Die TriGUIDE-PCB für den Hauptrechner und die I2C-PWM-Wandler haben wir schon von William gekauft.
Alu für den Rahmen ist bestellt.
Den Rest bestellen wir diese Woche.
Nun ist der Gyro ADXRS610 ist momentan nicht lieferbar. Was können wir statt desssen für das IMU nehmen. deHarry hat am 16.01.2011, 00:48 Uhr über den SD746 SingleChip-IMU geschrieben.
Gruß und Dank,
Chris
Hi, willkommen im Forum!!!
Mit dem adxrs610 ist das ein problem. der ist nicht nur momentan nicht lieferbar, sondern abgekündigt und wurde deshalb günstig ausverkauft...
der nachfolger adxrs620 ist komplett baugleich was pins und elektrik angeht - da muss man aber noch auf die version auf breakout board warten.
die triguide ist darauf ausgelegt genau diese gyros anzuschließen. andere gyros mit analogem output, 5V Vcc und 300°/s sollten aber auch gehen.
(müsste willa aber noch abnicken)
z.B. http://www.sparkfun.com/products/8372
die werden erfolgreich beim ng-uavp eingesetzt.
dann viel spaß beim tüfteln!!!
Hallo,
@scotch: deine unterbringung würde ich als sehr ineffiktiv einstufen. den du hast den riesen klötz direkt in den luftstrom gelegt. das ist doch eher suboptimal. warum amchst du das net wie viele anderen und hängst den einfach so mit einem schrumpfschlauch außen dran. da hast dann auhc genug kühlung.
@chriscopter:
da gibt es noch die 6DOF Razor IMU. Diese habe ich am anfang benutzt aber fand die nicht wirklich gut. ABER nun hbae ich mitbekommen das wnen der high-pass-filter entfernt wird dass, das teil dann fliegbar sein soll.
meinen umbau der triguide findest du in willas blog.
wenn da zu speziel fragen sind mir einfach eine mail streiben. diese findest du auch in dem blog.
@all:
meine shreddi ist nun völlig hin. hatte am freitag nen üblen crash. alle drei props (meine letzten) auseinander gerissen unddas gesammte chassis ist verzogen. aber neues chassis ist ja in arbeit.
Gruß, Sven
Hi Willa
Veto!
Ich ziehe den Stecker des Kabels zwischen TriGUIDE und dem I2C-Eingang am Konverter ab und das Geblinke der LEDs hört auf, das leise Ticken des Servo verstummt. Alles geht weiter, wenn ich den Stecker wieder drauf stecke.
I2C ist ein Protokoll mit Acknowledge, ich vermute das Handshake zwischen Master und Slave wird in der Library transparent (=unsichtbar) für den Anwender abgewickelt.
Unter diesem Aspekt wird die Verarbeitung sehr wahrscheinlich doch gebremst.
Wenn du in den Konvertern die Bearbeitung des I2C-Bus Interrupt gesteuert abwickelst, trifft das aber möglicher Weise doch nicht zu, da dann die Bearbeitung der Kommunikation mit dem Hauptcontroller immer sofort erfolgt (solange die Interrupts nicht wegen irgend was anderem gerade gesperrt sind).
Edit:
Ich habe gerade die Erleuchtung gehabt und muss demütig einen Rückzieher machen
Der abgezogene Stecker bei meinem Test war der zwischen ESC und Konverter (nicht der zwischen TriGUIDE und Konverter, wie ich oben behauptete), in Folge war der betreffende Konverter stromlos und hat offenbar den Bus gestört, was die Blockade des Hauptcontrollers bewirkte.
Ich habe nicht gemessen, was auf dem Bus exakt passiert, aber auf jeden Fall läuft der Hauptcontroller weiter, wie Willa das angegeben hat, wenn ein Konverter nicht antwortet. Sorry.
Hi Willa,
noch ein anderes Thema (im gleichen Kontext).
Ich habe in deinem Konverter-Code gesehen, dass dort eine Stelle existiert, an der während der Initialisierung ein Wert von -105% für drei Sekunden an den ESCs ausgegeben wird.
Im Thread weiter oben wurde die Idee erörtert, die ESCs beim Power up die Min/Max-Werte über den Konverter lernen zu lassen.
Wäre das die korrekte Stelle?
Ist das überhaupt möglich?
Da ich meine Konverter ohnehin nochmal programmieren muss (will), dachte ich, dieses Thema ebenfalls gleich anzugehen.
Edit:
Auch hier war ich vorschnell.
Der Einlernvorgang für den Gasweg funktioniert bei meinen ESCs so:
Gas am Sender auf Vollgas, DANACH den ESC an Spannung legen. Tüdeldi piep.
Dann Gas auf Null. Piieeep. Jetzt hat er den Gasweg gelernt.
Da nicht sicher gestellt ist, wer von beiden zuerst mit seiner Initialisierung fertig ist (der ESC oder der Konverter), kann nicht davon ausgegangen werden, dass ein Vollgas-Wert vom Konverter bereits als PWM-Signal ausgegeben wird, wenn der ESC nach PowerOn bereit für erste Signale ist.
Im Zweifelsfall ist der ESC schneller, tut was er vom Konverter gesagt bekommt und schaltet den Motor auf Vollgas. Das dürfte nicht gewollt sein [-(
Also doch Einlernen nach Altväter Sitte direkt am Kanal 3 des Empfängers... Glück für den, der seine Verbindungen überall steckbar ausgeführt hat
Uff, mein Beileid! Ich dachte bisher, die Tris sind auf Grund der ausgebufften Steuerung unkaputtbar(Stecklandungen nach missglückten Loopings mal ausgenommen).
Aber wo ein Wille, da ist auch ein Weg, oder wie?
Wie ist das denn passiert (was muss ich also bei meinen Flugversuchen tunlichst vermeiden?)?
Du schreibst, die Props sind zerrisssen. Hast du an den Props irgend etwas verändert (Loch aufgebohrt, Material abgetragen um Masse zu reduzieren, ...), oder muss man mit sowas jederzeit auch am unveränderten Original-Prop rechnen?
Ich gehe davon aus, dass du nicht mit 100000 rpm fliegst, so dass nicht alleine die Fliehkraft schuld war.
Gut
Berechtigungen
Zitieren
Lesezeichen