Hallo,
ich hab jetzt die Zeile auskommentiert - das Problem, dass das [/DATA] fehlt besteht weiterhin. Aber wie gesagt, nur mit Funk.
lg
Michi
Hallo,
ich hab jetzt die Zeile auskommentiert - das Problem, dass das [/DATA] fehlt besteht weiterhin. Aber wie gesagt, nur mit Funk.
lg
Michi
Hm... Das ist aber merkwürdig...Dann liegts vielleicht doch am Funk...
Über kabel kommen auch Mikrofonwerte rein? (wenn dus wieder einkommentierst natürlich nur)
ja, über Kabel bewegt sich der Mikrofonzeiger wenn ich es antippe.
Ich habe das Programm mit dem RP6+M32+M128 getestet und vermute noch einige Bugs.
Die Version auf dem Basis board scheint gut zu laufen. Mir gefällt jedoch die Anzeige bzw. Steuerung der Motorfunktion nicht, der Motorbefehl wird erst abgesetzt wenn man den Regler loslässt. Man sieht auch die eigentlich interssanten Messwerte der Motordaten aus dem Überwachungsfenster nicht oder nur indem man zwischen den Reitern umschaltet. Das lässt sich besser lösen. Der Regler ganz rechts hat irgendwie keine Funktion? Aber zur Motorsteuerung gleich noch mehr.
Zunächst testete ich ausgiebig Base+M32
Bedient man den Motorenmittelregler, werden zwar die Regler der Einzelmotoren mit bewegt, der Befehl an beide Motoren scheint aber manchmal verloren zu gehen bzw. nur manchmal an der Base anzukommen. Die Einzelregler funktionieren aber wohl - da hatte der Bot noch keine Aussetzer.
Dann ist mir aufgefallen, das die LEDs auf der M32 falsch angesteuert werden. Die Reihenfolge von LED 1-4 ist vertauscht, also wenn ich LED4 anschalte geht LED1 an, usw. Ich weis nicht ob das ein Bug in der Firmware oder im Programm ist, es ist jedenfalls sicher reproduzierbar.
Mein M32 Board ist leider eines aus der Charge wo die Diode D1 fehlt, demnach schlägt der Microfontest fehl - dazu kann aber die Software nix.
Leider liest das Programm die Werte für die ADC0/1 auf dem Baseboard nicht aus, ich habe mir da ein Linesensormodul angeschlossen und würde natürlich gerne auch die Daten am ADC sehen.
Gleiches gilt für die ADC Werte des M32 Boards (die ich aktuell noch nicht nutze).
Dann hab ich versucht das Log im Programm zu stoppen um es mit c&p hier einzubauen.. zum meinem erstaunen stoppt das log aber nicht... auch läuft es nicht so das die jeweils aktuelle Zeile sichtbar ist.... sondern ab der ersten im log... das macht wenig Sinn.
Was ich nämlich dokumentieren wollte ist, das der Bot verbunden ist, es auch Werte für die Batterie und die LDRs gibt (oder zumindest was angezeigt wird - ich bezweifele dass es sich um aktuelle Daten des Bot handelt), jedoch das auslesen weiterer Daten scheinbar fehlschlägt.
[INFO] 00:13:14: 'RP6SensorReader.RefreshSensors': Heartbeat
[INFO] 00:08:10: 'RP6AsyncControler.EnqueueCommand': Trying to start command: #9:1:67*
[INFO] 00:13:15: 'RP6SensorReader.RefreshSensors': Heartbeat
[INFO] 00:08:10: 'RP6AsyncControler.EnqueueCommand': Trying to start command: #9:1:68*
Im Programm ist wärend dessen auch das Selbsttestfenster eingegraut. Anscheinend funktioniert die I2C Bus Kommunikation nicht mehr richtig worauf hin auch das Programm durcheinander gerät. Trennt man im Programm die Verbindung, bleibt der Button trennen aktiv und eine Widerverbindung ist nicht möglich.
Dann.. Test mit Base+M32+M128
Die I2C Kommunikation war nur nach mehrmaligem Booten mit Glück hinzubekommen, die M128 konnte das LCD welches auf der M32 aufgesteckt war z.b. nicht beschreiben (per i2clcdtest sollte das doch gehen), Messwerte wie für die LDR gingen verloren, die LEDs auf dem m32 Board waren ebenfalls verdreht usw usw... geschätzt sind ca. 40% aller Daten verloren gegangen, letztlich hatte ich massenweise Schwierigkeiten das Ganze ansatzweise zum Laufen (oder sagen wir besser zu einer Reaktion) zu bringen. Es war offensichtlich das beide kleinen CPUs im Slave Mode liefen und teilweise Daten ankamen... aber eben nicht durchgängig und nicht immer 100%ig reproduzierbar.
Es scheint dabei evtl. Timingprobleme auf dem ic2 sowie auch Programmfehler bei unerwarteten Antworten des Bot auf Sensorabfragen zu geben. Bei der M128 jedoch mehr als mit der M32.
Meine Meinung: An dem Programm sowie an den Libs und "Firmware" muss noch viel gemacht werden bevor das eine sinnvolle nützliche Software ist, für einfache Tests ist das Ding jedoch brauchbar und für Entwickler ein schönes Beispiel was alles schief gehen kann.
Achso... und manchmal bekomme ich beim beenden des Programms auch eine Fehlermeldung das irgendwas abgeschmiert sei, das mir netterweise beim Neustart dann angezeigt wird...
Gruß RolfD
Code:See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.ComponentModel.Win32Exception (0x80004005): Der angegebenen Datei ist keine Anwendung zugeordnet at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo) at System.Diagnostics.Process.Start() at System.Diagnostics.Process.Start(ProcessStartInfo startInfo) at DiamondFramework.Logger.FormReportError.btnShowFile_Click(Object sender, EventArgs e) in H:\RP6\RP6 Remotrol\C#\DiamondFramework\Logger\FormReportError.cs:line 39 at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll ---------------------------------------- RP6 Remotrol Assembly Version: 1.3.1.251 Win32 Version: 1.3.1.251 CodeBase: file:///D:/RP6/RP6%20Remotrol%201.3/RP6%20Remotrol.exe ---------------------------------------- DiamondFramework Assembly Version: 1.1.0.37216 Win32 Version: 1.1.0.37216 CodeBase: file:///D:/RP6/RP6%20Remotrol%201.3/DiamondFramework.DLL ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Configuration Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- Microsoft.WindowsAPICodePack Assembly Version: 1.1.0.0 Win32 Version: 1.1.0.0 CodeBase: file:///D:/RP6/RP6%20Remotrol%201.3/Microsoft.WindowsAPICodePack.DLL ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box.
Hallo und danke erst mal für dein ausführliches Feedback.
Ich habe dazu einige Dinge zu sagen und zu korrigieren:
Das ist mit Absicht so. Der RP6 würde sonst tonnenweise Befehle bekommen.Zitat von RolfD
Doch, dort stellt du die Geschwindigkeit für die Pfeiltasten-Steuerung ein.
Danach in die Textbox oben klicken und mit dem Pfeiltasten fahren.
Dein Vorschlag?
Entweder hast du eben den Regler nicht losgelassen, oder es war Zufall, dass nur die vom mittleren Regler nicht ankommen. Ein Zusammenhang mit dem Regler an sich ist ausgeschlossen.
Ich würde es nicht unbedingt Bug nennen. Habe mir da keine großen Gedanken drum gemacht welche LED nun LED1 ist. Ich kann aber gerne noch mal drüber gucken, welche wann angesteuert werden.
Das war auch ein Vorschlag einer meiner Beta-Tester und steht auf der ToDo-Liste. Hast du einen Vorschlag für die grafische Darstellung?
Bin mir grade nicht ganz sicher was auf den Buttons drauf steht, die waren jedenfalls nie dazu gedacht, das Log zu "stoppen", sondern nur um das Autoscrolling zu deaktivieren. Leider ist das so wie ich mir das vorstelle nicht möglich. Daher wird lediglich der Fokus von der Textbox genommen und wenn man wieder reinklickt scrollt sie weiter.
Inwiefern schlägt denn das Auslesen fehl? Du kannst im Terminal gucken, ob aktuelle Daten ankommen.
Das hier deutet darauf hin, dass die Kommunikation zwischen Master-Modul und PC nicht perfekt klappt. In der nächsten Version habe ich die Befehlsverwaltung komplett neu geschrieben, sie ist jetzt wesentlich verlässlicher.
Woran willst du bitte erkennen das die I2C (!!!) Kommunikation nicht klappt?
Der Bot wird nicht über I2C angesprochen. Die Kommuniktion mit dem PC läuft über UART.
Nur die interne Kommunikation der Controler läuft über I2C.
I2C: s.o.
Was lässt dich vermuten, dass die M128 auf das LCD der M32 schreiben kann? Das ist momentan nicht möglich. (Aber auf der ToDo-Liste)
Der Test ist übrigens ein I2CLED-Test kein LCD-Test.
Was lässt dich denn vermuten, dass Daten verloren gehen?
Das ist eigentlich nie der Fall. Ein Befehl kann schonmal verloren gehen, Daten aber eigentlich nicht. Der RP6, bzw die M128 sendet konstant mit einer Standardübertragungsrate von 5 Übertragungen die Sekunde alle neuen Daten zum PC.
Timing-Probleme mit I2C? Da hast du glaube ich was falsch verstanden.
Der PC fragt keine Sensorwerte ab, daher kann er auch keine falschen Antworten bekommen.
Die Fehlermeldung sagt mir, dass dir eine Dateiendungsverknüpfung fehlt. Das ist interessant und sollte gefixt werden.
Ich bin mir nicht ganz sicher, ob ich diesen Satz ernst nehmen soll.
Ich finde er klingt ein bisschen arrogant. Ich stecke viel Freizeit in dieses Projekt und stelle es hier zu Anschauungszwecken zur Verfügung.
Niemand muss etwas dafür zahlen oder so, es gibt daher keinen Grund die Software schlecht zu machen. Das Feedback oben drüber ist gut, der Satz hier macht es aber irgendwie wertlos.
Das ganze hat übrigens bei unzähligen Leuten vor dir schon gut funktioniert...
PS: Informier dich doch vor dem nächsten so ausfühlrichen Beitrag etwas mehr über die Funktionsweise von Remotrol, dann kannst du dir viel Getippe bezüglich deiner Fehlinformationen sparen, im Speziellen bezüglich des I2C-Bus.
Trotzdem danke für die nützlichen Hinweise, ich werde mir folgende Punkte mal näher ansehen und entsprechend ändern:
- Pfeiltastensteuerung verdeutlichen (steht eh schon auf der ToDo-Liste)
- Reihenfolge der M32 LEDs
- Anzeige aller ADC/IO-Werte
- Dateiverknüpfung vom Fehlerlog
Liebe Grüße,
Fabian
Gern.
Mir ist klar das die Verbindung zum Master über eine UART Verbindung läuft. Tonnenweise Befehle gäbe es nur wenn Du wirklich jede Bewegung am Regler 1:1 an den Bot durchgeben würdest - natürlich würde das nicht gehen da das Windows Messaging System geringfügig schneller als ein AVR32 und auch schneller als jede UART Verbindung istIch habe dazu einige Dinge zu sagen und zu korrigieren:
Das ist mit Absicht so. Der RP6 würde sonst tonnenweise Befehle bekommen.
Ein Update 1-5 mal die Sec. wäre aber möglich und für alle Teile verkraftbar. Die Frage ist bestenfalls, lohnt sich der Aufwand dafür und das lasse ich mal offen.
Ah ok, danke.
Doch, dort stellt du die Geschwindigkeit für die Pfeiltasten-Steuerung ein.
Danach in die Textbox oben klicken und mit dem Pfeiltasten fahren.
Nun Dein Programmfenster (Überwachung) böte z.B. sicherlich auch Platz für die Motorregler und weitere Anzeigen wenn die Anzeigen etwas kleiner wären, insbesondere die Batterieanzeige muss nicht so groß sein. Dann sind analoge Anzeigen zwar stylisch aber digitale Messwerte oder Graphen / Balkenanzeigen sagen min. genau so viel aus. Ich bin mir sicher das man sogar alle Funktionen auf eine Seite unter bekommt und es nicht nötig ist, Reiter und Subwindows zu nutzen. Dann kannst Du sicherlich davon ausgehen das heute jeder über ein Display von min. 1024x768 verfügt, also kannst Du diese Größe abzüglich je ca. 20 Pixel für Schieber auch für dein Programm nutzen. Die Verbindungseinstellung kan man in ein Menu unterbringen... es gibt eine Menge Ideen wie man den Platz sinnvoll ausnutzt. Wenn du Zweifel hast, schau dir einfach mal Synthezizer wie den Thor als extremes Beispiel an...
Dein Vorschlag?
Bild hier
Aha ok.
Entweder hast du eben den Regler nicht losgelassen, oder es war Zufall, dass nur die vom mittleren Regler nicht ankommen. Ein Zusammenhang mit dem Regler an sich ist ausgeschlossen.
Da die LEDs an der Platine bezeichnet sind, macht es Sinn diese Bezeichnung im Programm zu übernehmen. Mag sein das es für Dich kein Bug ist aber wenn ich LED4 anschalte erwarte ich nun mal nicht das LED1 angeht... Als ernst zu nehmender "Funktionstest" ist das sogar ungeeignet.
Ich würde es nicht unbedingt Bug nennen. Habe mir da keine großen Gedanken drum gemacht welche LED nun LED1 ist. Ich kann aber gerne noch mal drüber gucken, welche wann angesteuert werden.
Zum Thema Grafik hab ich ja schon was gesagt, mir persönlich würde zunächst die Angabe als Zahl reichen ohne das ich sie mir aus dem Log fischen müsste... aber man kann durchaus Indikatoren wie für die Lichtsensoren nehmen... oder eine schöne kleine LED-bar ...
Das war auch ein Vorschlag einer meiner Beta-Tester und steht auf der ToDo-Liste. Hast du einen Vorschlag für die grafische Darstellung?
->Autoscrolling zu deaktivieren ... genau sowas suchte ich auch, dadurch das der Focus jedoch ans Fenster zurück geht ist es kaum möglich einen Bereich mittels Copy&Paste auszuschneiden. Das muss eine andere Lösung her und da gibts sicherlich was. Jede einfache Textbox lässt sich zu einer Log-Box umprogrammieren, das ging schon vor 10 Jahren selbst mit Visualbasic. Natürlich muss man sich bissel mit Controls beschäftigen...
Bin mir grade nicht ganz sicher was auf den Buttons drauf steht, die waren jedenfalls nie dazu gedacht, das Log zu "stoppen", sondern nur um das Autoscrolling zu deaktivieren. Leider ist das so wie ich mir das vorstelle nicht möglich. Daher wird lediglich der Fokus von der Textbox genommen und wenn man wieder reinklickt scrollt sie weiter.
Also es stand im Log genau das was ich gepostet habe, offensichtlich sendet der PC aber der RP6 nicht - warum auch immer. Ich habe mich weiter unten dann wohl zu sehr auf I2C bezogen. Vielleicht ist es mit den neuen Befehlen fürs UART ja nun stabiler.
Inwiefern schlägt denn das Auslesen fehl? Du kannst im Terminal gucken, ob aktuelle Daten ankommen.
Das hier deutet darauf hin, dass die Kommunikation zwischen Master-Modul und PC nicht perfekt klappt. In der nächsten Version habe ich die Befehlsverwaltung komplett neu geschrieben, sie ist jetzt wesentlich verlässlicher.
Das ist mir wie gesagt klar, erklärt mir aber nicht warum das Programm offensichtlich falsch reagiert - was aber ggf. durch die neuen UART Befehle behoben sein kann.
Oh da hab ich mich echt verguckt
I2C: s.o.
Was lässt dich vermuten, dass die M128 auf das LCD der M32 schreiben kann? Das ist momentan nicht möglich. (Aber auf der ToDo-Liste)
Der Test ist übrigens ein I2CLED-Test kein LCD-Test.
Trotzdem halte ich es für sinnvoll, das LCD bei vorhandener M32+M128 an die M32 anzuschließen und von der M128 aus mittels I2C beschreibbar zu machen denn nur dann können beide Prozessoren auf das Display schreiben wenn der M128 Master ist. Es liegt also nahe, so ein Test auch anzubieten. Hat die M32 keine Ausgaben, kann man es natürlich an die M128 klemmen.
Daten verloren gehen meint in dem Zusammenhang das ich Steuerbefehle an den RP6 gab und insbesondere von der M128 aus quasi nur die Hälfte der Sensoren/Aktoren funktionierten. Es kann aber gut sein, das es mit den UART Befehlen zu tun hat - wie schon geschrieben.
Ja nur warum taucht das beim beenden eines Programms auf? .net 4 ist frisch installiert.
Die Fehlermeldung sagt mir, dass dir eine Dateiendungsverknüpfung fehlt. Das ist interessant und sollte gefixt werden.
Nein Du brauchst es nicht ernst zu nehmen und ich will deine Leistung auch nicht anzweifeln - Fakt ist aber das es (wo auch immer da Fehler und Missverständnisse sitzen) derzeit nicht besonders stabil läuft und sicherlich einiges verbessert werden kann. Das ist weder arogant noch abwertend.
Ich bin mir nicht ganz sicher, ob ich diesen Satz ernst nehmen soll.
Ich finde er klingt ein bisschen arrogant. Ich stecke viel Freizeit in dieses Projekt und stelle es hier zu Anschauungszwecken zur Verfügung.
Niemand muss etwas dafür zahlen oder so, es gibt daher keinen Grund die Software schlecht zu machen. Das Feedback oben drüber ist gut, der Satz hier macht es aber irgendwie wertlos.
Das ganze hat übrigens bei unzähligen Leuten vor dir schon gut funktioniert...
Ich hatte schon geschrieben das ich warscheinlich mit dem I2C Bus flasch lag aber da es sich um ein komplexes System handelt, sucht man nun mal nach Fehlern da wo man die Effekte sieht. Und wenn ich sehe das Teile des RP6 zu steuern sind und manche Teile nicht, ist es naheliegend, an der Kommunikation von Komponenten zu zweifeln, da die Selbsttestprogramme der CD erfolgreich liefen. Ich konnte ja nicht wissen das du auch bei dem UART scheinbar Probleme siehst. Darüber hinaus halte ich nicht viel davon, ein Multimasterbus wie I2C im Single Mode zu betreiben wenn ich 3 CPUs und externe Devices zu steuern habe. Allerdings hat das nichts mit deiner Software zu tun. Vielleicht verstehst du aber das ich nicht grundlos "motze", sondern versuche zu helfen.
Ja ich freue mich auf die nächste Version.
Lieben Gruß Rolf
Okay, dann hatte ich deinen Post etwas zu "böse" verstanden.
Ich schreibe jetzt nicht überall was zu, das wäre zu viel
Die I2C-Kommunikation sollte eigentlich keine Probleme machen, das ist hauptsächlich aufgebohrter Code aus den Beispielen. In der Tat dürften die meisten Verbindungsprobleme ganz einfach in der Übertragung über UART liegen.
Speziell im Handshake des RP6 mit dem meinem Programm.
Diese Fehler sind allerdings durch ein paar radikale Änderungen nun behoben (z.B. wird die Firmware komplett von Remotrol konfiguriert)
Wenn du möchtest kannst du dir auch gerne die neuste Beta-Version runterladen. Ist zwar nur eine kleine Vorschau der neuen Verbindungsverwaltung und ist auch keine Beta sondern mehr eine Pre-Alpha, aber da sieht man das schon ganz gut.
Mehr Informationen gibt es hier: www.support.diamondback-development.de
Du kannst dich auch gerne dort registrieren und Beta-Tester werden! =)
Kritische Meinungen besonders bezüglich der GUI und der Verbindung sind immer willkommen!
Ich muss auch zugeben, dass ich nicht wirklich gut im GUI-Design bin
Hat sich mittlerweile schonmal jemmand damit auseinander gesetzt?
Oder hat schon jemmand andere Funkmodule?
/Edit
Die beiden Module von Robotik Hardware sind mir ein bischen zu teuer.
Ich weiß jetzt nicht ob das XBee Pro auch mit dem RN-Funk zusammen passt?
Oder ob es eventuell alternativen zum RN-Funk gibt?
So jetzt habe ich etwas mehr Zeit noch mal zu antworten.
- Bezüglich der M32 LEDs hast du Recht, die sind komplett falsch herum. Wird natürlich gefixt, ist ja auch keine große Sache.
- Zum Thema GUI... Ich bin ja fast tot umgefallen als das Programm da gesehen habe
Ich denke, das ist einfach Geschmackssache und mir gefällt es überhaupt nicht- Das mit der Logbox und auch dem Terminal muss ich mal überlegen... Sicherlich wäre es überhaupt kein Problem sich eine eigene Textbox mit den erforderlichen Eigenschaften zu bauen, ich weiß aber noch nicht, ob es mir den Aufwand wert ist.
Einfacher wäre es das Logging bzw. die Ausgabe einfach zu stoppen und wieder zu Starten.- Ein I2C-LCD-Test wird nicht kommen denke ich. Das Beschreiben über I2C aber sehr wohl. Ist noch nicht da, weil ich einfach kein zweites Display habe.
- In der aktuellen Version habe ich einen Stresstest eingebaut, der sagt mir, dass nahezu 100% aller Befehle auch erfolgreich sind. (die,die nicht erfolgreich sind spielen in der Praxis keine Rolle, das sind nur Auswirkungen eben dieses Stresstestes)
Sorry das ich diesen Thread nochmal ausgrabe, aber ist eine Servosteuerung nur mit der Base nicht möglich?? Ich hätte nämlich an ADC0/1 zwei Servos hängen??
Gruß Biohazard
Berechtigungen
Zitieren
Lesezeichen