Tau Labs Software unterstützt vielfältige Hardware

E

ernieift

Erfahrener Benutzer
#101
#101
Hallo zusammen,
mittlerweile habe ich ein bisschen mit dem Source gespielt. SUMD/H Protokoll für das flyingf3 sollte nun gehen. Bei mir habe ich es auf einem nackten discoveryf3 zu laufen. Einzig die Checksummenprüfung ist noch nicht drin. Derzeit habe ich einen GR-12 mit SUMDFS08 am laufen. Die gcs musste ich auch anfassen, da das Ding sonst bei der Auswahl des neuen Protokolls ausgestiegen ist.
Im Moment kann ich mir über "Data Object/ManualControlCommand/Channel[0..8]" die Empfangsdaten ansehen. Soweit so gut.
Ein Problem habe ich aber noch. Vielleicht kann ja jemand mit mehr Erfahrung dabei helfen. Wenn ich irgendeinen Servokanal zu schnell bewege, dann macht das Board einen Reboot. Das passiert aber nur, wenn ich es via USB User anschliesse. Wenn ich den STlink-Port benutze dann geht es.
Mein Code ist an dem DSM angelehnt. Falls jemand einen Satelliten hat, wäre es schön das damit mal zu testen. Übrigens muss dazu nicht einmal die gcs laufen.
Danke
ernieift
 
cGiesen

cGiesen

Erfahrener Benutzer
#103
#103
Hallo Jörg,

SUMO ist normales PPM das dürfte keine Probleme machen, da hätten schon andere geschrien ;)
Wir reden hier von SUMD und SUMH die sich im Prinzip nur durch das CRC unterscheiden.

Aber was hat das Betriebssystem der Dev. Umgebung mit dem Reboot des Boards zu tun?

@ernieift
Hast Du das Datenblatt von den Protokollen?
Oder fummelst Du Dich so da durch?
Ich könnte Die das datenblatt zukommen lassen, zumal es ein Failsafe Flag im Protokoll gibt!

Gruß
Carsten
 
J

joergrohde

.
#104
#104
Hallo Carsten,
mit der Frage nach Ubuntu war seine Entwicklungsumgebung gemeint sonst nichts. Ich kämpfe immer noch mit meiner und bin da zur Zeit ziemlich gefrustet. Mir ist es egal unter welchem Betriebssystem ( W7, MAC Linux ), Hauptsache ich muss keine Doktorarbeit daraus machen. Ich wollte meine Zeit lieber in die Anpassung einiger mir wichtigen Funktionen stecken - Failsafe mit Graupner PPM funktionierend äh SUMO, Armen per Schalter, etc.

Die Unterschiede SUMO - PPM und SUMD / SUMH - serielles Signal ala DSM.. mit unterschiedlicher Prüfsummenbildung kenne ich schon. Auch ich habe mir vom Graupner Support die Unterlagen zu SUMD, SUMH und Telemetrie schicken lassen.
vg jörg

PS: ich hätte im vorigen Post eventuell etwas mehr tippen sollen.
 
Zuletzt bearbeitet:
J

joergrohde

.
#106
#106
Vor allen Dingen wurmt es mich das OP einfach geht, unter W7, und mit Taulabs es nicht geht.
Wenn der make Lauf funktioniert wäre das schön genug, aber da klemmts es ja schon. Womit ich dann Code ist egal, Eclipse gibt es für alle Betriebssysteme. Ich muss keine Compilerlauf aus dem Editor heraus anstoßen können, man ist ja bescheiden.
 
E

ernieift

Erfahrener Benutzer
#107
#107
Hallo,
also der Compilerlauf geht bei mir einfach mit make. Entweder mit 'fw_xxxx' oder einfach 'all'. Hin und wieder ist ein angehängtes '_clean' vorher wichtig. Also unter Linux sollte es kein Problem sein. Man kann sich die arm-toolchain und andere wichtige Dinge einfach über die 'Tool Installers' holen. Die werden dann im Tool Ordner abgelegt und beim make gefunden. Es ist also nicht nötig für jeden Kram einen $PATH zu haben.

@Carsten: Die Graupner Unterlagen habe ich schon. In meiner Include habe ich mal versucht im Kommentar alles zusammenzutragen. Im Moment wird die CRC noch nicht berechnet und geprüft. Der Rest vom Protokoll schon. Den Switch dafür habe ich auch schon drin. Der Code dafür ist auch kein Problem. Ich wollte erstmal eine lauffähige Implementierung haben. Über Quick&Dirty bin ich schon hinweg.

Es funktioniert ja auch. Wenn ich die Knüppel laaaangsam bewege geht auch alles. Ich vermute es hat etwas mit der übergeordneten Struktur zu tun. Failsafe geht ja auch schon. Das RC-Feld wird gelb bei Failsafe und grün bei Signal.
Die Kanalanzeige geht auch. Werte sind 1000..2000µs wenn ich meine Gleitkommaformel vom Multiwii nehme. Wenn ich einfach bit-shift mache, dann sind es die Werte laut Datenblatt (1100..1900) für +-100%.

@joerg: Ich brauche auch noch keinen jtag-debugger mit breakpoints im code. Früher ging das auch nicht. Einfach den Editor nach Wahl und in der Kommandozeile ein make. Das reicht für den Anfang völlig. Die Variablen kann man sich dann über die gcs ansehen. Versuch mal ein make mit V=1 und achte mal darauf woher die tools kommen. Bei Taulabs scheint die Version der arm-toolchain wichtig zu sein. Wenn Du nicht weiter kommst, dann schreib mal wo es hackt. Vielleicht kann ich als Einäugiger helfen.

Grüsse
ernieift
 
cGiesen

cGiesen

Erfahrener Benutzer
#108
#108
Compilieren klappt bei mir auch schon.
Allerdings muss man erstmal ein Release machen.
Nur Eclipse bekomme ich nicht hin.
Der meckert immer tausend Sachen an. Da stimmt was mit den Includes nicht.
 
E

ernieift

Erfahrener Benutzer
#109
#109
Was meinst Du mit Release?
Die Includes sind nicht falsch. Einige werden aus xml-files erzeugt. Das geht nur über das eingebaute makefile
 
Zuletzt bearbeitet:
cGiesen

cGiesen

Erfahrener Benutzer
#110
#110
Die includes für Eclipse! Der findet manches nicht.

Release: der normale make macht nur Debug. Da gibt es einen Befehl für Release. Habe ich irgendwo im Readme gelesen
 
J

joergrohde

.
#111
#111
Die UAVO Objekte werden mit der GCS per .xml Dateien synchron gehalten. Die Verzahnung ist hier einfach größer. Das kann mit Eclipse dann so einfach nicht funktionieren.
Der Unterschied zwieschen Release und Debug sind nur die extra Informationen für den Debugger, fliegen tut das sicherlich auch.
 
cGiesen

cGiesen

Erfahrener Benutzer
#112
#112
Ich hatte halt vorher immer Fehler und hinterher nicht mehr.
Aber warum soll das mit Eclipse nicht gehen?
Wie machen es denn die Anderen?
 
E

ernieift

Erfahrener Benutzer
#113
#113
Tja,
das würde mich auch mal interessieren. Ich denke mal, dass man dieses RTOS sowieso nicht einfach debuggen kann. So ganz bin ich durch die Struktur auch noch nicht gestiegen.
 
E

ernieift

Erfahrener Benutzer
#114
#114
Es geht!
Habe den Fehler gefunden. Er war nicht in meinem Code. Damit der Receiver funktioniert muss man ihn noch in der transmitter_control.c einfügen. Sonst kann man ihn zwar lesen, aber das Channelupdate funktioniert nicht und das Teil läuft in den Watchdog. Jetzt nur noch die beiden CRC Checks einpflegen und dann kann man damit fliegen. Leider habe ich noch kein Adapterboard.
War hier nicht jemand, der den Quantonsource pflegt? Oder hat jemand einem solchen am Start?
 
cGiesen

cGiesen

Erfahrener Benutzer
#115
#115
Ich glaube <lilvinz> liest hier mit. Ich habe ihm aber gerade im IRC Bescheid gesagt.

ich finde das Cool, kann man doch jetzt die kleinen benutzen. Allerdings haben die keine Telemetrie :(
 
J

joergrohde

.
#116
#116
Livinz pflegt den Quanton Source, aber falls Du es auf so einem Board testen möchtest habe ich eines.
Ich habe auch ein flying F3 inklusive einem Shield von dasdboot.
Livinz ist derzeit, so ich weiß, im Ausland. Ich hoffe das er bald wieder da ist und uns ein bisschen unter die Arme greifen kann.
vg jörg
 
J

joergrohde

.
#118
#118
Wieso die Akkuspannung übermitteln sie Dir auch, außerdem sind sie eh nur für Zimmerflieger gedacht:)
Ernie hat auch SUMD drin, richtig? Für die Großen dann noch ein Arduino Mavlink - Graupner Adapter und gut ist.
 
cGiesen

cGiesen

Erfahrener Benutzer
#120
#120
@Jörg

hast Du auch Graupner?
Dann könntest Du bitte mal ein Test machen.

Failsafe mit Quanton und mit FF3
Bei Quanton perfekt (bei mir), ein Anderer hat aber auch FF3 ein Problem und ist nicht sicher ob es der Empfänger ist.
Den schließe ich aber aus, da er es mit zweien getestet hat und beide keinen Erfolg haben.
 
Um antworten zu können musst du eingeloggt sein.
FPV1

Banggood

Oben Unten