Hallo zusammen,

ich habe eine bitte an die Elektroniker hier im Forum, ich möchte einen Atmeg8 einsetzen um meine Stereocam anzusteuern (Nick/Gier über HeadGyro, Augenwinkel über Ultraschallsensor).

externer Link:
externer Link:


externer Link:


Funktionsbeschreibung:

Die Cam hat einen eigenen RC-Empfänger um unabhängig vom Piloten agieren zu können.
Diesen Empfänger möchte ich per Summensignal an den Atmega8 (PB1) anschließen.

Der Ultraschallsensor SRF10 (über I2C – PC4 und PC5) steuert das „Servo_Angle“ (PC0) (die beiden Linearservos auf dem Bild, parallel) um den Winkel beider Cams zu regeln (ab einem bestimmten Abstand zum Objekt, soll sich der Winkel ändern).
Jumper1 (PD7) schaltet die Funktion aus/ein.

Das „Servo_Nick_Cam“ (PC1) soll über J7 von der FC (PB0) ausgeglichen werden (Nickausgleich).
Kanal1 des RC-Empfängers der Cam soll Nick übersteuern können (so wie es auch bei der FC ist).
Jumper2 (PD6) schaltet den Nickaugleich der FC aus/ein.

Das „Servo_Gier_Cam“ (PC2) wird durch Kanal2 des RC-Empfängers der Cam angesprochen.

2x LED (PD0 und PD1) für div. Statusmeldungen.

ISP Schnittstelle

Grundbeschaltung


Ist die Schaltung so OK?

Würde mich sehr über Hinweise / Tipps freuen.

Grüße
Uwe

Hi Uwe,

UweP meinte

Hallo zusammen,

ich habe eine bitte an die Elektroniker hier im Forum, ich möchte einen Atmeg8 einsetzen um meine Stereocam anzusteuern (Nick/Gier über HeadGyro, Augenwinkel über Ultraschallsensor).

externer Link:
externer Link:


externer Link:


Funktionsbeschreibung:

Die Cam hat einen eigenen RC-Empfänger um unabhängig vom Piloten agieren zu können.
Diesen Empfänger möchte ich per Summensignal an den Atmega8 (PB1) anschließen.

Der Ultraschallsensor SRF10 (über I2C – PC4 und PC5) steuert das „Servo_Angle“ (PC0) (die beiden Linearservos auf dem Bild, parallel) um den Winkel beider Cams zu regeln (ab einem bestimmten Abstand zum Objekt, soll sich der Winkel ändern).
Jumper1 (PD7) schaltet die Funktion aus/ein.

Das „Servo_Nick_Cam“ (PC1) soll über J7 von der FC (PB0) ausgeglichen werden (Nickausgleich).
Kanal1 des RC-Empfängers der Cam soll Nick übersteuern können (so wie es auch bei der FC ist).
Jumper2 (PD6) schaltet den Nickaugleich der FC aus/ein.

Das „Servo_Gier_Cam“ (PC2) wird durch Kanal2 des RC-Empfängers der Cam angesprochen.

2x LED (PD0 und PD1) für div. Statusmeldungen.

ISP Schnittstelle

Grundbeschaltung


Ist die Schaltung so OK?

Würde mich sehr über Hinweise / Tipps freuen.

Grüße
Uwe

Very Interesting, are you thinking to produce a board? a kit? or what?
The camera mount hardware?

Cheers
Dommy

Hi Uwe,

Brauchst Du nicht noch nen 5V Zweig für die Servos? Vielleicht auch gleich ne Spannungsstabilisierung für die Kameras?

Kriegt die Kameraservosteuerung einen eigenen Akku oder kommt sie mit an den Flugakku?

Bin gespannt!

EDIT:
Was mir noch einfällt:

Da die Kamerasteuerung sowieso mit der FC verbunden werden soll (J7), könnte man nicht gleich eine serielle Schnittstelle nehmen und sowohl Nick- als auch Gier-lage senden?

Man spart sich das Dekodieren des J7-PPM Signals, und hat auch gleich noch eine Gierlageinformation (mit Kompass), so dass ein Gierausgleich stattfinden kann (MK dreht sich, CAM führt nach und bleibt gleich).

EDIT2: Der SRF10 braucht auch 5V, hab eben nochmal nachgekuckt.

EDIT3: Die Programmierschnittstelle + ggf. Serielle sollte PIN-kompatibel zu der auf der FC sein. Dann kann man die Sercon zum Programmieren benutzen.

Dein Empfängeranschluss sollte wie der am Empfänger sein:
1-Signal
2-Plus
3-Masse/Minus

Pangu hat Recht, Stromversorgung fehlt. Nimm nen Spannungsregler mit mind. 1A.
Und er auch recht, dass du die Daten des Neigungswinkel aus der seriellen Schnittstelle der FC bekommst. Das du nen 2. Empf. nimmst, denke ich,
geht darauf hinaus, dass du schon alle 8 Kanäle belegt hast, oder?

Warum willst du eigentlich den Winkel der Cam zueinander verstellen. Dann schielt man doch?! Und kann man mit nem Ultraschallsensor die Bewegung überhaupt messen?, Was ist, wenn du die Augenlider zumachst (unbewusst)?

Ich denke Uwe möchte den Abstand zu Objekten vor dem MK messen. Was würd mehr Sinn machen...

Hallo zusammen,

dommy meinte

Hi Uwe,

Very Interesting, are you thinking to produce a board? a kit? or what?
The camera mount hardware?

Cheers
Dommy

Hello Dommy,

no, I would like to make sure that the circuit is ok, since I am not the specialist for electronics.

pangu meinte

Hi Uwe,

Brauchst Du nicht noch nen 5V Zweig für die Servos? Vielleicht auch gleich ne Spannungsstabilisierung für die Kameras?

Kriegt die Kameraservosteuerung einen eigenen Akku oder kommt sie mit an den Flugakku?

Bin gespannt!

EDIT:
Was mir noch einfällt:

Da die Kamerasteuerung sowieso mit der FC verbunden werden soll (J7), könnte man nicht gleich eine serielle Schnittstelle nehmen und sowohl Nick- als auch Gier-lage senden?

Man spart sich das Dekodieren des J7-PPM Signals, und hat auch gleich noch eine Gierlageinformation (mit Kompass), so dass ein Gierausgleich stattfinden kann (MK dreht sich, CAM führt nach und bleibt gleich).

EDIT2: Der SRF10 braucht auch 5V, hab eben nochmal nachgekuckt.

Hallo Stephan,

5V ist klar, hab es nur nicht gezeichnet.

Da ich auch die Kameras und Videosender (beides ebenfalls 5V) über den Flugakku betreiben möchte, muss ich hier noch testen.

Schaltregler mit 3A, hier ist die Gefahr für Störungen der 35Mhz, ist aber weit entfernt vom Empfänger der FC, oder eben ein Festspannungsregler 3A, mal schauen ob ich das Bild störungsfrei bekomme, Teile für beide Varianten sind bestellt.

Wegen der seriellen Schnittstelle, ich habe keine mehr frei, da hängt das Bluetooth Modul dran (wobei ich auch testen muss, ob das noch funzt bei zwei Videosendern, bei meinen letzten Flügen mit der Stereocam hatte ich noch kein BT).

Den Ausgleich auf Gier finde ich nicht so wichtig, da die Cam eh durch den Betrachter gesteuert wird.
Eigentlich müsste man noch Roll ausgleichen – aber dies wäre eine andere Geschichte (mechanisch und Code FC).

Aber eine Überlegung ist es wert, auch für zukünftige Geschichten.
Kann der Atmega8 überhaupt 2xPPM dekodieren?
Ich fände es halt schön, wenn man nix an der FC Firmware ändern müsste.

Hoppel meinte

Dein Empfängeranschluss sollte wie der am Empfänger sein:
1-Signal
2-Plus
3-Masse/Minus

Pangu hat Recht, Stromversorgung fehlt. Nimm nen Spannungsregler mit mind. 1A.
Und er auch recht, dass du die Daten des Neigungswinkel aus der seriellen Schnittstelle der FC bekommst. Das du nen 2. Empf. nimmst, denke ich,
geht darauf hinaus, dass du schon alle 8 Kanäle belegt hast, oder?

Warum willst du eigentlich den Winkel der Cam zueinander verstellen. Dann schielt man doch?! Und kann man mit nem Ultraschallsensor die Bewegung überhaupt messen?, Was ist, wenn du die Augenlider zumachst (unbewusst)?

Hallo Hoppel,

stimmt, die Belegung am Empfänger und den Servos stimmt nicht, muss ich noch ändern.

Klar, wie schon geschrieben, die Stromversorgung kommt da noch dazu.
Wegen der seriellen Schnittstelle habt ihr mich glaub ich überzeugt.

Der zweite Empfänger hat den Grund, dass die „Bodenstation“ völlig unabhängig vom Piloten ist.
Ich habe einen Rucksack gebaut (Guggst du hier) , dieser beinhaltet 2xVideoempfänger, 1xRC-Sender mit HeadGyro, Stereovideobrille, Spannungsversorgung für alles.
Und klar, die Kanäle am Flugempfänger würden eh nicht reichen.

Ich habe die Erfahrung gemacht, dass ein fixer Winkel der Cams zueinander nur ein Kompromiss ist.
Man stellt den Winkel fest auf z.B. entfernte Objekte ein, kommt man nun an nahe Objekte stimmt der Winkel nicht mehr und es wird sehr schwer fürs Hirn das noch als Stereobild hinzubekommen.
Daher möchte ich ab einem bestimmten Abstand zu einem Objekt vor dem MK (so ab 6m, muss noch getestet werden) den Winkel ändern.
Natürlich macht das nicht ewig Sinn, nur in einem kleinen Bereich.

Der Ultraschallsensor wird hier eingebaut:

externer Link:



Grüße
Uwe

So, nun die geänderte Schaltung.

- Kommunikation mit der FC seriell
- ISP nun gleiche Belegung wie bei der FC
- Empfänger Belegung richtiggestellt

Könnte das nun so funktionieren, ist alles richtig beschaltet?

externer Link:


Grüße
Uwe

Ich würde das Summensignal vom Empfänger an PB0 (ICP1) anschließen, dann ist die Dekodierung ein Kinderspiel.

PB1 wäre nicht mal meine zweite Wahl. Als zweite Wahl würde ich PD2 (INT0) nehmen. Das geht auch noch einigermaßen gut und die LED kann man mit egal welchem anderen freien Port ansteuern.

tschüss
quax

Weil du geschrieben hattest: "Augenwinkel über Ultraschallsensor"
hatte ich das mit dem U-Schallsensor missverstanden.

Das mit dem Summensignal an Pb1 habe ich übersehen. Mach es nach Quax vorschlag und du kannst den Code der FC übernehmen.

Gruß,
Hoppel

für die servo ansteuerung, währen wohl die hardware-pwm
am geeignetsten um jitterfreie signale zu erzeugen.

.

Quax meinte

Ich würde das Summensignal vom Empfänger an PB0 (ICP1) anschließen, dann ist die Dekodierung ein Kinderspiel.

PB1 wäre nicht mal meine zweite Wahl. Als zweite Wahl würde ich PD2 (INT0) nehmen. Das geht auch noch einigermaßen gut und die LED kann man mit egal welchem anderen freien Port ansteuern.

tschüss
quax

Hallo Quax,

danke für den Tipp, hab es auf PB0 geändert.

Hoppel meinte

Weil du geschrieben hattest: "Augenwinkel über Ultraschallsensor"
hatte ich das mit dem U-Schallsensor missverstanden.

Hallo Hoppel,

Stimmt, Augenwinkel ist missverständlich, Kamerawinkel trifft es wohl eher.

Hoppel meinte

Das mit dem Summensignal an Pb1 habe ich übersehen. Mach es nach Quax vorschlag und du kannst den Code der FC übernehmen.

Gruß,
Hoppel

So ist es natürlich einfacher, an den Code der FC hatte ich nicht gedacht, bzw. sind mir die Unterschiede der Ports nicht wirklich klar.
Die Schaltung hab ich praktisch zusammenkopiert, habe mit Mikrocontrollern noch nie was gemacht.

JUERGEN_ meinte

für die servo ansteuerung, währen wohl die hardware-pwm
am geeignetsten um jitterfreie signale zu erzeugen.

.

Hallo Juergen,

habe eben mal etwas gegoogelt, ok, verstanden mit der Hardware PWM.
Beim Atmega8 müssten es die Ports PB1-3 sein – richtig?
PB1 und 2 habe ich frei, nur PB3 wird ja schon für ISP (Mosi) benötigt.
Kann man den Port parallel nutzen oder hab ich da Pech.
Zur Not könnte ich das Gierservo auch direkt am Empfänger betreiben, für Gier muss ja nichts gerechnet werden, wird ja nur 1:1 durchgeschleift.

Besten Dank und Grüße
Uwe

Man kann den Port parallel nutzen Normalerweise gar kein Problem. Ggf. PB3 während der Programmierung per Jumper vom Rest der Schaltung 'abklemmen'.

Hallo borax,

danke für die Info, werde gleich mal den Schaltplan auf HW-PWM abändern .....

Grüße
Uwe

Hallo zusammen,

hier nun die 3. Version, alle Tipps sind berücksichtigt.
Hat noch jemand Einwände/Tipps/Anregungen?

externer Link:


Grüße
Uwe

UweP meinte

Hallo zusammen,

hier nun die 3. Version, alle Tipps sind berücksichtigt.
Hat noch jemand Einwände/Tipps/Anregungen?

Hi Uwe,

ich hab mir nochmal Gedanken zur Übertragung der Nick-Info von der FC gemacht. Ich sags ja ungern, aber vielleicht lagst Du da mit J7 gar nicht so verkehrt.

1. muss nur Nick übertragen werden, Gier hast Du ausgeschlossen
2. für eine flotte Reaktion ist ein PPM vielleicht doch geeigneter als RX/TX.
3. J7 liegt an jeder FC an, Nick auf RX1/TX1 müsste man explizit legen (die Debug-Ausgabe an RX/TX ist definitiv zu lahm)
4. RX1/TX1 ist dann nicht für andere Anwendungen verfügbar

Also doch den J7 abgreifen?

Hallo Stephan,

eben, Gier ist unwichtig, es geht nur um Nick.
Ich würde es schon besser finden, wenn man nix am FC Code ändern muss.
Wegen der Geschwindigkeit der Debugausgabe hast du recht, so würde es nicht gehen.

J7 würde mir auch besser gefallen, ist halt nur die Frage ob der Atmega8 mit 2xPPM klarkommt.
J7 an PD2 (INT0), so wie Quax geschrieben hat, würde ja gehen (LED kommt halt z.B. an PD4).

Grüße
Uwe

Hallo Uwe,

C3,C4 und den 8MHz Quarz könnte man weglassen, da der AT-Mega8 auch einen internen Oszillator hat, der mit 8MHz laufen kann (siehe BL-Ctrl).

Gruß,
Reinhard

ReinhardZ meinte

....
C3,C4 und den 8MHz Quarz könnte man weglassen, da der AT-Mega8 auch einen internen Oszillator hat,
....

Ich würde den Quarz drauflassen. Der kostet nicht viel und bringt ein mehr an Betriebessicherheit, weil das gesamte Timing sehr viel genauer ist, Stichwort: Empfängersignal.


tschüss
quax

ReinhardZ meinte

C3,C4 . . . . . . könnte man weglassen,. . .

und den...,
http://www.reichelt.de/?;ARTICLE=42491
. . . als option vorsehen.

mann weiss nie, wozu mann mal eine genaue referenz braucht.

.

ReinhardZ meinte

Hallo Uwe,

C3,C4 und den 8MHz Quarz könnte man weglassen, da der AT-Mega8 auch einen internen Oszillator hat, der mit 8MHz laufen kann (siehe BL-Ctrl).

Gruß,
Reinhard

Quax meinte

ReinhardZ meinte

....
C3,C4 und den 8MHz Quarz könnte man weglassen, da der AT-Mega8 auch einen internen Oszillator hat,
....

Ich würde den Quarz drauflassen. Der kostet nicht viel und bringt ein mehr an Betriebessicherheit, weil das gesamte Timing sehr viel genauer ist, Stichwort: Empfängersignal.


tschüss
quax

Hallo Reinhard, Hallo Quax,

ich habe mir im WWW div. Schaltungen und Erklärungen dazu angeschaut.
Und wie Quax schon schreibt, soll es grade bei Timingrelevanten Dingen mit dem internen Oszillator zu ungenau sein.
Und so banne ich auch die Gefahr, dass ich mich Aussperre <g>.

Hier nun die nochmals aktualisierte Schaltung, so müsste es ja nun passen.
Bezüglich der 2xPPM, hat da jemand Erfahrung mit dem Atmega8, kann er zwei Empfängersignale gleichzeitig verarbeiten?

externer Link:


Grüße
Uwe

JUERGEN_ meinte

ReinhardZ meinte

C3,C4 . . . . . . könnte man weglassen,. . .

und den...,
http://www.reichelt.de/?;ARTICLE=42491
. . . als option vorsehen.

mann weiss nie, wozu mann mal eine genaue referenz braucht.

.

Hallo Jürgen,

das ist ja geil, spare ich mir C3, C4, und der Quarz ist auch noch kleiner als da was ich rausgesucht hatte.

Besten Dank für den Tipp!

Edit:

Im Datenblatt steht was von Input/Output, ist das nicht egal?
Wenn nein, was ist den was beim Atmega PB6/PB7


Grüße
Uwe

In/Out kommt an PB6/PB7 (Reihenfolge sollte egal sein) und Gnd an Masse.

Auf der Murata Seite wird der 8MHz Typ als non preferred angegeben, wird wohl bald auslaufen.
http://www.murata.com/ und dann CSTCC8M00 in die Suchmaske eingeben

edit:
Im Datenblatt des AT-Mega8 steht
"XTAL1 and XTAL2 are input and output, respectively, of an inverting amplifier which can
be configured for use as an On-chip Oscillator, as shown in Figure 11. Either a quartz
crystal or a ceramic resonator may be used."

Also XTAL1=PB6=In und XTAL2=PB7=out

Gruß,
Reinhard

ReinhardZ meinte

Auf der Murata Seite wird der 8MHz Typ als non preferred angegeben, wird wohl bald auslaufen.
http://www.murata.com/ und dann CSTCC8M00 in die Suchmaske eingeben

gibt noch andere hersteller, die baugleiche fabrizieren.

und ob der bei reichelt, gerade von Murata ist, ist auch noch die frage.
; . (bei reichelt hat in der beschreibung schon oft mist gestanden)

.

Hab es oben im letzten Layout schon geändert, nun mit CSTCC 8.0.

Grüße
Uwe

UweP meinte

Bezüglich der 2xPPM, hat da jemand Erfahrung mit dem Atmega8, kann er zwei Empfängersignale gleichzeitig verarbeiten?

Was meinst du mit Empfängersignale gleichzeitig verarbeiten? Alle Kanäle kommen ja über das Summensignal rein, der Empfang ist also kein Problem.

Was die Erzeugung des Sendesignals für 2 Kanäle angeht, könnte es schon eher Probleme geben das jitterfrei hinzubekommen. Über den 16-Bit Time1 kann man 2 PWM-Signale an OC1A (PB1), OC1B (PB2) erzeugen. Das hast du in deinem Schaltbild ja schon entsprechend angeschlossen. Der Timer1 wird aber auch benutzt um das Summensignal an ICP auszuwerten. Da er hier nur ausgelesen wird, sollte das aber kein Problem machen.

Ich würde den AT-Mega168 einsetzen. Der ist pinkompatibel zum AT-Mega8 und bietet mehr Möglichkeiten bei den Timern. Alle Timer (2x8Bit, 1x16Bit) können 2 PWM Signale erzeugen. Damit sollte es keine Probleme geben. Zusätzlich hast du 16k statt 8K FlashRom.

Gruß,
Reinhard