Atmega8 ansteuern eines digital Servos

Der Vorteil digitaler Servos ist (aus eigener Erfahrung), dass sie ihre 
Position auch halten, wenn die PWM-Signale nicht regelmäßig kommen, weil 
sie ihre Position offenbar speichern.

Ich habe ein "pick by laserponter"- Projekt mit zwei Digitalservos 
gemacht, die wunderbar funktionieren, auch wenn sie im Arduino-Loop ihre 
Positionsdaten nur hin und wieder mal aus einer Funktion mit variablem 
ms-delay bekommen ...

Zusammengefasst: Das Impulpaket in sich muss nat. stimmen, aber es darf 
gerne auch längere Zeit ausfallen.

Patrick89 schrieb:

> Gehe ich richtig der Annahme das dieses Tut nur für analoge Servos
> ist???
> Wenn ja, wie Steuer ich denn dann ein digitales Servo an???

Genau gleich.
Schliesslich muss man ja ein digitales Servo anstelle eines analogen 
Servos in jeder bereits verbauten Fernsteuerungsanlage im 
Modellbaubereich einfach austauschen können. Kein Hersteller kann es 
sich leisten, ausschliesslich digitale Servos auf den Markt zu bringen, 
für die man die komplette Empfangsanlage austauschen müsste.

Die Begriffe 'analog' bzw. 'digital' beziehen sich auf die interne 
Regelung des Servos. Die Ansteuerung ist identisch.

> Was bedeutet denn das standard Band von 1520 Mikrosekunden
1520 Mikrosekunden sind ~ 1.5 Millisekunden. Na, klingelts?

Ein Digitalservo kann oft mehr Stellimpulse pro Sekunde verarbeiten als 
ein Analogservo. Manche Digitalservo funktionieren auch nicht an 
Analogempfängern, weil sie einen anderen Mittenimpuls haben. Futaba BLS 
251 z.B. ist so eines.

Frickelfritze schrieb:
> Karl H. schrieb:
>> 1520 Mikrosekunden sind ~ 1.5 Millisekunden. Na, klingelts?
>
> Dein Taschenrechner ist kaputt.

Sehe ich nicht ganz so. 1520 dividiert durch Tausend (Komme um 3 Stellen 
nach links verschieben) ergibt ca. 1.5
(oder störst du dich daran, dass ich grundsätzlich einen Kommapunkt 
schreibe, wie es in Programmiersprachen üblich ist?)

Patrick89 schrieb:

> Habt ihr eine Idee wie ich nein Problem lösen kann???

Sieh zu, dass du an das Summensignal deines Empfängers ran kommst oder 
besorg dir einen, der das frei Haus liefert.
Im Summensignal sind die 'Pulse' aller Servos enthalten.

Patrick89 schrieb:
> Und wenn das nicht möglich ist???

Dann hast du wohl ein Problem, so wie das aussieht.

Frickelfritze schrieb:
> Patrick89 schrieb:
>> Und wenn das nicht möglich ist???
>
> Dann ver-odere mit ein paar Gattern alle Servo Ausgänge des Empfängers
> zu einem und speise damit deinen Controller.
Das kann funktionieren, muss aber nicht.

Frickelfritze schrieb:
> Karl H. schrieb:
>> Das kann funktionieren, muss aber nicht.
>
> Warum sollte es nicht?

Weil gerade bei 2.4Ghz Fernsteuerungen, die auf WLAN Technik beruhen, 
noch lange nicht gesagt ist, dass sie ihre Servopulse tatsächlich 
nacheinander oder überlappend generieren. Gerade im Sinne von einer 
Erhöhung der Pulsrate an die Servos ist davon auszugehen, dass sie genau 
das nicht tun.

Im Prinzip: ja
Ich glaube allerdings nicht, dass er ein Oszi hat.

USART ist keine gute Idee.
Wenn ich genug Pins habe, dann würde ich SPI nehmen.
MISO, MOSI und CLK kommen an jeden Client und für jeden Client wird noch 
eine Select Leitung spendiert. Das macht dann bei 6 Eingängen 9 Pins für 
die Eingangsstufen am zentralen µC.

Achte darauf, dass deine Client-µC über einen Timer mit Input Capture 
verfügen. Sonst kriegst du Ärger beim Ausmessen der Pulse.

Wenn du kein Summensignal auftreiben kannst, dann würde ich hier 
ausnahmsweise zustimmen, auch wenn es meistens keine gute Idee ist, 
mehrere µC einzusetzen, wenn einer alleine auch reichen würde. Aber für 
den einen brauchst du nun mal das Summensignal. Probieren könnte man es, 
ob man es aus den Servoausgängen erzeugen kann.

Patrick W schrieb:
> Und das soll funktionieren mit den paar dioden???

Es kann funktionieren. Es ist ein wired-OR.
Es hängt alles davon ab, wie dein Empfänger die Servosignale generiert. 
Nacheinander oder parallel zueinander. Bei den alten Fernsteuerungen war 
es nacheinander, weil sich das ganz einfach aus dem PPM Signal ergeben 
hat, das über die Funkstrecke gegangen ist. Aber bei 2.4GHz Anlagen ist 
die Übertragung per Funk völlig anders. Bei alten Fernsteuerungen hat 
der Sender einfach das Funk-PPM Signal auf ein Schieberegister gelegt 
und an den Ausgängen sind die Servo Signale ganz von alleine richtig 
herausgefallen. Bei den GHz Anlagen geht das aber nicht mehr, hier muss 
der Empfänger die Servopulse selbst generieren. Die Frage ist nur: wie 
macht er das? Generiert er sie für n Ausgänge nacheinander oder 
generiert er alle Pulse auf den n Ausgängen parallel. Im ersten Fall 
funktionert die Dioden Lösung immer noch, sofern er eine winzige 
zeitliche Lücke zwischen den Pulsen auf den Leitungen lässt, die reicht 
um für die Input Capture Unit eine Flanke zu erzeugen.

Patrick W schrieb:
> Da ich leider kein Ozi habe, kann ich nur raten....
>
> Besser gefallen wuerde mir da die Methoe mit TWI.

TWI ist Overkill.
Du stellst dir das jetzt alles ein bischen zu einfach vor. Du wärst 
nicht der erste, der draufkommt, dass die Inter-µC Kommunikation dann 
doch nicht so einfach ist, wie ursprünglich gedacht.

Was brauchst du den wirklich von deinen Clients. Du willst die 
Pulslängen wissen. Dazu brauchst du keine 30 verschiedene Kommandos und 
aufwändiges Protokoll, sonder der Client soll seinen gemessenen Wert 
rausrücken. Und das so einfach und schnell wie möglich.
Client selektieren
1. Byte holen -> High Byte
2. Byte holen -> Low Byte
Client deselektieren

Einfacher und schneller als mit SPI und ein paar Select-Leitung geht das 
nicht.

Hi,

nee Leute, ich glaube hier haben noch nicht so viele damit gearbeitet.
Das Summensignal ist schön aber wenn man nicht rankommt bringt es einem 
nichts. Das Summensignal hat übrigens normalerweise eine Pause von 300µs 
und das Servosignal wird von Flanke zu Flanke gezählt.
Also neutral ist 300µs Pause und 1200µs high.
Das machen die meisten Funken immer noch intern, wenn sie Modulbasiert 
sind also das Summensignal ist immer noch der Standard zwischen dem µC 
des Senders und dem HF-Teil. Da allerdings invertiert.
Aus dem Empfänger (von 40MHz Multiplex, Simprop bis hin zu aktuellen 
2,4GHz Chinesen) kommen dann die Servosignale nacheinander und in der 
richtigen Reihenfolge heraus.
Hier habe ich gerade einen FrSKY Empfänger, der macht zwischen den 
Signalen sogar noch netterweise 60µs Pause. So ein Frame kommt alle 
17,5ms.
Da müsste man nichtmal Ints bemühen und könnte pollen. Verarbeitung dann 
nach dem letzten Signal. Ich will gerade sowas ähnliches machen und ich 
glaube damit mache ich mich einfach vom Acker.
Das geht natürlich auch eleganter mit PCINTs aber eben nicht mit einem 
Mega8 oder 16, die haben das noch nicht.
Die Krücke Verodern würde mit der 60µs Pause auch gehen, wäre aber ja 
gar nicht nötig.
-----
Schleife:
Warten bis Kanal 1 low (falls schon angefangen)
Warten bis Kanal 1 high
Timer nullen
Warten bis Kanal 1 low
Kanal_1_Zeit = Timer

Warten bis Kanal 2 high
Timer nullen
Warten bis Kanal 2 low
Kanal_2_Zeit = Timer
.
.
.
Warten bis Kanal n low
Kanal_n_Zeit = Timer

Dann Werte verhackstücken und wieder nacheinander ausgeben, ähnlich wie 
oben.
Das ist grausiger Stil und man lässt bei mehr als 3-4 Kanälen jeden 
zweiten Frame aus. Die Servos interessiert das aber nicht und wenn man 
das per PWM wieder ausgeben will, also mehr in Richtung Echtzeit, hat 
man nicht zuviele Ressourcen oder fängt sich Probleme mit 
Überschneidungen der Signale ein, wenn man die Signale per OCR manuell 
ausgeben will.
Bei 8 Kanälen ist der Frame einfach irgendwann voll.
Als Fehlerkompensation kann man bei jedem Kanal noch aus der Warterei 
aussteigen wenn die Zeit nicht mehr realistisch ist.

Für mich geht das jedenfalls wunderbar so wie beschrieben, da ich mit 
der Reaktionszeit überhaupt kein Problem habe und genau weiß, was der 
Empfänger macht.
Bei bestimmten Anwendungen kann so ein Delay von 50-100ms aber schon 
eine Rolle spielen.
Bei Heckservos für Helis oder der Lenkung für Glattbahner ist es schon 
ein Unterschied, ob das Servo schnell oder superschnell ist und das 
liegt in dieser Grössenordnung.
Flugregelung geht in diese Richtung aber bei der Fragestellung mache ich 
mir da wenig Sorgen, das wird sowieso nichts.

Schön, daß wir mal drüber gesprochen haben.
Ich wollte das eigentlich jetzt mit den PCINTs machen und hatte mich 
schon auf das herumgeprokel mit den Registern "gefreut" aber nun mache 
ich das so banal und schmutzig per Polling und warten.
Unelegant aber das verstehe ich auch in ein paar Monaten wieder auf 
Anhieb und für die meisten Zwecke reicht es locker.

Gruß,
Norbert

Patrick W schrieb:
> Norbert S. schrieb:
>> Flugregelung geht in diese Richtung aber bei der Fragestellung mache ich
>> mir da wenig Sorgen, das wird sowieso nichts.
>
> Was meinst du damit???

Hi,

Damit meine ich, daß Du eine Flugregelung wenn es z.B. um einen 
Multicopter geht, vermutlich nicht hinbekommen wirst.
Das ist nicht böse gemeint aber das lese ich an der Fragestellung ab.

Patrick W schrieb:
> Was passiert eigentlich, wenn sich ein Slave mal aufhaengt oder einfach
> laenger braucht als angenommen?
> Kann man die Transaktion dann auch vorzeitig beenden?

Natürlich kann man, muß man sogar.
Daß Dir der Begriff "Timeout" scheinbar nicht geläufig ist, ist so ein 
Indiz.
Das ist simples Handwerkszeug um sowas auf die Beine zu stellen.
Wenn Du Dir das jetzt erst noch alles erarbeiten musst, ist eine 
"Flugsteuerung" noch in ganz weiter Ferne.

Wie gesagt, ist nicht böse gemeint. Ich hab mich auch schon oft mit 
Projekten übernommen aber auf dem Weg dahin eine Menge gelernt.
Auch das kann Spaß machen und ein Erfolgserlebnis sein.

Gruß,
Norbert

Hi,

Vielleicht schreibst Du mal, was Du denn da bauen willst.
Mehrere µC hernehmen und sich dafür die Kommunikation antun ist 
jedenfalls erstmal nicht das Mittel der Wahl, nur weil man die normalen 
Mittel nicht beherrscht.

Und natürlich bist Du Dir sicher, daß Du Dich nicht übernimmst. Das ist 
man immer solange, bis man es selber merkt (oder auch nicht).
Lass Dich nicht aufhalten.

Die Servogeschichte per SPI oder was auch immer auf mehrere Controller 
zu verteilen ist jedenfalls eine üble Krücke, die mehr Probleme schafft 
als sie löst.

Was spräche denn dagegen, es so banal zu machen, wie ich vorgeschlagen 
habe?

Und nochwas: Wenn ich hier schon lange Texte schreibe, dann nehme ich 
mir auch heraus, Deine Ansätze zu kritisieren.
Oft ist der Ansatz schon Quatsch und das muß man sagen dürfen.
Du hast ja leider nicht erzählt, was Du da vor hast.
Wenn Du aber keine Kritik hören willt und nur noch Tipps, wie Du die 
unsinnige Kommunikation hingefrickelt bekommst, dann kannst Du Deine 
Zeit gerne alleine in diesen Schwachsinn versenken.
Ich wundere mich, daß ich der Erste bin, der hier mal etwas deutlicher 
wird.

Gruß,
Norbert

Hi,

Wenn meine simple Methode (primitiver geht es nicht) für Dich schon 
verwirrend ist dann viel Spaß.

Berichte mal wie das dann fliegt.

Gruß,
Norbert

Patrick W schrieb:

> So als grobe Zusammenfassung was meine verstanden zu haben:
>
> Master MOSI auf die Slaves MOSI
>
> Master MISO auf die Slaves MISO
>
> Master SCK auf die Slaves SCK
>
> Master irgend ein Port auf die Slaves SS
>
> Im Master und in den Slaves die ISR aktivieren und die entsprechenden
> Routinen dafuer schreiben.
>
> Der Master selektiert dann einen Slave indem er Portx (der mit dem Port
> SS vom Slave verbunden ist) von High auf Low zieht.

Ja

> Danach sendet der Master ein Byte an den Slave. Der Slave arbeitet dann
> seine ISR ab und sendet noch in dieser Methode ein Byte an den Master.

Ein Slave kann bei SPI nicht von sich aus senden.
DIe Begriffe Senden und Empfangen sind bei SPI etwas missverständlich. 
SPI ist ein Byteaustausch. Beide, Master und Slave sind gleichzeitig 
Sender und Empfänger. Ein Slave kann von sich aus überhaupt nichts tun.

SPI

> Was passiert eigentlich, wenn sich ein Slave mal aufhaengt oder einfach
> laenger braucht als angenommen?
> Kann man die Transaktion dann auch vorzeitig beenden?

Du brauchst nichts vorzeitig beenden. Der Master zieht sein Ding durch, 
egal ob der Slave bereit ist oder nicht.

Patrick W schrieb:

> Oder werden die Bytes gleichzeitig vom Master und Slave uebertragen?

Während 1 Byte vom Master zum Slave geht, geht 1 Byte vom Slave zum 
Master

Stell dir vor, du und dein Kumpel sitzen sich gegenüber.
Jeder hat einen Zettel vor sich, auf dem jeder einen Bytewert 
aufschreiben kann. Auf dein Kommando hin (du bist der Master) nimmt 
jeder seinen Zettel mit der rechten Hand und schiebt ihn zum Gegenüber 
rüber, der ihn mit der linken Hand entgegen nimmt.
Wichtig dabei: dein Kumpel kann sich nicht wehren! Wenn du das Kommando 
gibst, dann werden die Zettel ausgetauscht. Egal ob dein Kumpel fertig 
ist oder nicht.

Deshalb kann es hier auch kein Timeout geben. Denn wenn der Master 
seinen Bytetransfer anstösst, dann kommt von der Gegenstelle 1 Byte 
rein. Ob du die weitere Bearbeitung im Master mittels Interrupt machen 
willst oder nicht, ist Ansichtssache. Wenn du SPI full speed fährst, 
dann dauert die Übertragung von 8 Bit gerade einmal 16 Prozessor 
Taktzyklen. Das kann man mittels Polling erwarten.

Wenn dir die Pulsinformation als ein Wert zwischen 0 und 255 reicht (256 
mögliche Positionen) dann braucht es da überhaupt keine Sonderbehandlung 
oder Interrupts. Der Slave stellt seinen ermittelten Wert, sobald er ihn 
hat, einfach in sein SPDR Register und der Master holt sich diesen vom 
Slave bei seiner nächsten Abfragerunde, ohne dass sich der Slave weiter 
darum kümmern muss. Vergleichbar damit, dass dein Kumpel sofort nach 
Erhalt deines Zettels seinen Messwert auf den Zettel schreibt damit du 
den Wert sofort kriegst wenn du den nächsten Zetteltausch anleierst.
Lediglich wenn da für ein Datenpaket mehr als 1 Byte ausgetauscht werden 
muss (High Byte / Low Byte bei 16 Bit Werten) ist eine Behandlung 
mittels Interrupt durch den Slave vernünftig. Vergleichbar damit, dass 
dein Kumpel erst mal auf den Zettel schauen muss um zu wissen, welches 
Byte du jetzt eigentlich von ihm wissen willst.

Aus dem Bauch raus würde ich sagen, dass wenn man die Knüppelbewegung an 
einem Fernsteuersender in 256 Abstufungen auflöst (auf Trimmweg nicht 
vergessen!) dann sollte das eigentlich reichen. So fein kann kein Mensch 
seine Hand führen. Aber das ist nur IMHO und man müsste es ausprobieren.

Ulli-B schrieb:

> Ich würde Dir folgenden Ansatz empfehlen:

Ich unterstütze diesen Vorschlag, auch wenn er bei der Auswertung von im 
Endeffekt 5 Empfänger Ausgängen dann in Schwierigkeiten kommen kann. 
Aber erst mal ein wenig Erfahrung sammeln schadet nie.

Im Moment sieht es auch für mich danach aus, dass sich der TO hier etwas 
vorgenommen hat, was noch ein paar Nummern zu gross für ihn ist. Und der 
Einsatz mehrerer Prozessoren verkompliziert die Dinge insofern, weil 
dann eben noch eine Kommunikationsebene mit dazu kommt, die man nicht 
hat, wenn alles auf einem Prozessor läuft. Auch wenn es hier das Problem 
lösen würde, dass er nicht genügend Input Capture Einheiten auf seinem 
zentralen µC für alle 5 Kanäle hat.

Hi,

ich glaube PCINT wurde schonmal erwähnt.
Anbei das woran ich gerade frickel.

Die Kanäle werden mit PCINTs eingelesen in Pc_int1 und 2.
Dazu nutze ich den freilaufenden Timer2 weil mir das reicht.
Die Auflösung ist mit 16µs nicht prickelnd aber +/-31 Schritte reichen 
mir locker.
Das geht natürlich viel besser mit nem 16bit Timer wenn man will.

Die Ausgabe für das Servo ist noch schlimmer mit dem Overflow von Timer1 
aber auch das reicht mir, da das Servo nur 3 feste Positionen anfahren 
soll.
Da kommt noch einiges dazu aber das werden einfache Schaltfunkionen oder 
Motorregelungen per PWM, wo mir die Auflösung der eingelesenen Kanäle 
wiederum reicht.

Der Teil mit den PCINTS dürfte aber erstmal erklären, wie man die 
Signale bulletproof mit einem µC einliest.
Hätte ich mir das per Hardware nicht verbaut, könnte man das mit Timer1 
nahezu jitterfrei einlesen.
Ausgabe jitterfrei geht dann aber eigentlich nur per PWM und da ist bei 
der M88-Familie schnell Feierabend oder man trickst extrem herum.

Wollte ich sowas für ein Bastelprojekt machen müssen, würde ich das 
Problem mit Hardware bewerfen. Bei einem Mega640 hat man 16bit PWM mehr 
als genug.

Gruß,
Norbert