Diskussion:Multikopter - Versionsgeschichte

Terminar am 23. Januar 2013 um 12:01 Uhr

2013-01-23T12:01:23Z

Terminar: /* Eigenes PCB? WLAN faehige SoC wie bspw. RT3050 */

2013-01-23T12:00:40Z

‎Eigenes PCB? WLAN faehige SoC wie bspw. RT3050

S4sh4: /* Eigenes PCB? WLAN faehige SoC wie bspw. RT3050 */

2013-01-23T10:34:02Z

‎Eigenes PCB? WLAN faehige SoC wie bspw. RT3050

Terminar: Verschoben nach Diskussion

2013-01-23T09:56:53Z

Verschoben nach Diskussion

Neue Seite

== Eigenes PCB? WLAN faehige SoC wie bspw. RT3050 ==

Waere es vielleicht sinnvoll WLAN faehige SoC zu evaluieren? Erratick faengt mal mit dem RT3050 an, hoffentlich finde ich auch was vergleichbares aber ARM basierendes. --[[Benutzer:S4sh4|S4sh4]] 15:02, 21. Jan. 2013 (CET)

Wäre es da nicht ggf. sinnvoll Kommunikation/Navigation und Flugkontrolle zu trennen? ggf. etwas OpenWRTfähiges nehmen und dafür nutzen, da hat man dann wenigstens funktionierendes Linux mit etwas Support, außerdem kommt man SEHR günstig an sowas ran…
Der Flugrechner kann dann ja weiterhin etwas dediziertes sein… z.B. mit ARM usw. --[[Benutzer:DooMMasteR|DooMMasteR]] 15:07, 21. Jan. 2013 (CET)

Ja, ich experimentiere auch mit dem TP-Link MR3020 mit OpenWRT als Serial Bridge. Das Problem ist aber schlichtweg WiFI. Für eine Kameraübertragung ja und für "Spielkram", aber bei einem Acro-flugfähigen Gerät möchte ich nicht irgendwelche Abrisse haben, daher RFM12BP, die Reichweite ist schlichtweg höher. Es geht aber auch um ein Platzproblem denn - eine Cortex-M3/M4 oder sonstwas Platine mit RFM12BP hat erheblich weniger Platzbedarf als ein "großes" ARM basierendes System was Linux stemmen kann. Linux ist ebenfalls bedenklich wegen fehlendem nativen Realtime. Ja, man könnte da mit RT rumwurschteln, effektiv ist das aber nicht, eher mit Kanonen auf Spatzen geschossen ;) Die Frage ist auch ob man die Leistung überhaupt braucht (Stromverbrauch kommt da auch noch dazu). Auf jeden Fall hat das nichts mit dem NG-UAVP zu tun. @DoomMaster: ich halte es ebenfalls für extrem wichtig, die Arbeit vom FlightController selbst mit der Kommunikation/Navigation zu trennen! :) Der FlightController hat sowieso schon genug zu tun. --[[Benutzer:Terminar|Terminar]] 10:56, 23. Jan. 2013 (CET)

← Nächstältere Version		Version vom 23. Januar 2013, 12:01 Uhr
Zeile 15:		Zeile 15:
	Ich warte schon drauf das jemand mit einem rPI einen Copter baut, allerdings dürften die wenigen GPIO's und Linux-Treibergeraffel ein Problem werden...		Ich warte schon drauf das jemand mit einem rPI einen Copter baut, allerdings dürften die wenigen GPIO's und Linux-Treibergeraffel ein Problem werden...
	AVR8: da sind wir ja schon wieder beim Thema MultiWii/Arducopter/* Arudino based Systemen - oder ein Projekt von einem Freund der gerade auf einem Atmega32U4 nativ einen WingStabi baut ( http://www.sth-tech.de/joomla/index.php/projects/wingstabi ). Den XMEGA finde ich persönlich zwar sehr interessant, aber viel zu teuer in Relation zu den 32bittern. Beim AVR32 bin ich noch zurückhaltend weil die Verbreitung vom STM32 gefühlt erheblich größer ist (wobei, Augenmerk auf den Teensy 3.0 das Board ist interessant). STM32: das wäre dann die Plattform vom NG-UAVP oder OpenPilot. ARM/Cortex halte ich auch für sinnvoll, auch aus Preisgründen... Ich bin gespannt wie es die nächsten Monate auf dem Markt so weitergeht. Immer weiter erwähnen, ist bei mir ja ähnlich! :) --[[Benutzer:Terminar\|Terminar]] 13:00, 23. Jan. 2013 (CET)		AVR8: da sind wir ja schon wieder beim Thema MultiWii/Arducopter/* Arudino based Systemen - oder ein Projekt von einem Freund der gerade auf einem Atmega32U4 nativ einen WingStabi baut ( http://www.sth-tech.de/joomla/index.php/projects/wingstabi ). Den XMEGA finde ich persönlich zwar sehr interessant, aber viel zu teuer in Relation zu den 32bittern. Beim AVR32 bin ich noch zurückhaltend weil die Verbreitung vom STM32 gefühlt erheblich größer ist (wobei, Augenmerk auf den Teensy 3.0 das Board ist interessant). STM32: das wäre dann die Plattform vom NG-UAVP oder OpenPilot. ARM/Cortex halte ich auch für sinnvoll, auch aus Preisgründen... Ich bin gespannt wie es die nächsten Monate auf dem Markt so weitergeht. Immer weiter erwähnen, ist bei mir ja ähnlich! :) --[[Benutzer:Terminar\|Terminar]] 13:00, 23. Jan. 2013 (CET)
−
−	~~--[[Benutzer:Terminar\|Terminar]] 13:00, 23. Jan. 2013 (CET)~~

← Nächstältere Version		Version vom 23. Januar 2013, 12:00 Uhr
Zeile 12:		Zeile 12:
	weil dies doch eher eine Architektur mit Zukunft darstellt, desweiteren ist's natuerlich jedem frei gestellt Experimente mit Plattformen der Wahl zu machen. Ich wollte nur alternative		weil dies doch eher eine Architektur mit Zukunft darstellt, desweiteren ist's natuerlich jedem frei gestellt Experimente mit Plattformen der Wahl zu machen. Ich wollte nur alternative
	Moeglichkeiten aufzeigen, bzw nur erwaehnen, dass ich damit experimentieren moehte --[[Benutzer:S4sh4\|S4sh4]] 11:34, 23. Jan. 2013 (CET)		Moeglichkeiten aufzeigen, bzw nur erwaehnen, dass ich damit experimentieren moehte --[[Benutzer:S4sh4\|S4sh4]] 11:34, 23. Jan. 2013 (CET)
		+
		+	Ich warte schon drauf das jemand mit einem rPI einen Copter baut, allerdings dürften die wenigen GPIO's und Linux-Treibergeraffel ein Problem werden...
		+	AVR8: da sind wir ja schon wieder beim Thema MultiWii/Arducopter/* Arudino based Systemen - oder ein Projekt von einem Freund der gerade auf einem Atmega32U4 nativ einen WingStabi baut ( http://www.sth-tech.de/joomla/index.php/projects/wingstabi ). Den XMEGA finde ich persönlich zwar sehr interessant, aber viel zu teuer in Relation zu den 32bittern. Beim AVR32 bin ich noch zurückhaltend weil die Verbreitung vom STM32 gefühlt erheblich größer ist (wobei, Augenmerk auf den Teensy 3.0 das Board ist interessant). STM32: das wäre dann die Plattform vom NG-UAVP oder OpenPilot. ARM/Cortex halte ich auch für sinnvoll, auch aus Preisgründen... Ich bin gespannt wie es die nächsten Monate auf dem Markt so weitergeht. Immer weiter erwähnen, ist bei mir ja ähnlich! :) --[[Benutzer:Terminar\|Terminar]] 13:00, 23. Jan. 2013 (CET)
		+
		+	--[[Benutzer:Terminar\|Terminar]] 13:00, 23. Jan. 2013 (CET)

← Nächstältere Version		Version vom 23. Januar 2013, 10:34 Uhr
Zeile 7:		Zeile 7:

	Ja, ich experimentiere auch mit dem TP-Link MR3020 mit OpenWRT als Serial Bridge. Das Problem ist aber schlichtweg WiFI. Für eine Kameraübertragung ja und für "Spielkram", aber bei einem Acro-flugfähigen Gerät möchte ich nicht irgendwelche Abrisse haben, daher RFM12BP, die Reichweite ist schlichtweg höher. Es geht aber auch um ein Platzproblem denn - eine Cortex-M3/M4 oder sonstwas Platine mit RFM12BP hat erheblich weniger Platzbedarf als ein "großes" ARM basierendes System was Linux stemmen kann. Linux ist ebenfalls bedenklich wegen fehlendem nativen Realtime. Ja, man könnte da mit RT rumwurschteln, effektiv ist das aber nicht, eher mit Kanonen auf Spatzen geschossen ;) Die Frage ist auch ob man die Leistung überhaupt braucht (Stromverbrauch kommt da auch noch dazu). Auf jeden Fall hat das nichts mit dem NG-UAVP zu tun. @DoomMaster: ich halte es ebenfalls für extrem wichtig, die Arbeit vom FlightController selbst mit der Kommunikation/Navigation zu trennen! :) Der FlightController hat sowieso schon genug zu tun. --[[Benutzer:Terminar\|Terminar]] 10:56, 23. Jan. 2013 (CET)		Ja, ich experimentiere auch mit dem TP-Link MR3020 mit OpenWRT als Serial Bridge. Das Problem ist aber schlichtweg WiFI. Für eine Kameraübertragung ja und für "Spielkram", aber bei einem Acro-flugfähigen Gerät möchte ich nicht irgendwelche Abrisse haben, daher RFM12BP, die Reichweite ist schlichtweg höher. Es geht aber auch um ein Platzproblem denn - eine Cortex-M3/M4 oder sonstwas Platine mit RFM12BP hat erheblich weniger Platzbedarf als ein "großes" ARM basierendes System was Linux stemmen kann. Linux ist ebenfalls bedenklich wegen fehlendem nativen Realtime. Ja, man könnte da mit RT rumwurschteln, effektiv ist das aber nicht, eher mit Kanonen auf Spatzen geschossen ;) Die Frage ist auch ob man die Leistung überhaupt braucht (Stromverbrauch kommt da auch noch dazu). Auf jeden Fall hat das nichts mit dem NG-UAVP zu tun. @DoomMaster: ich halte es ebenfalls für extrem wichtig, die Arbeit vom FlightController selbst mit der Kommunikation/Navigation zu trennen! :) Der FlightController hat sowieso schon genug zu tun. --[[Benutzer:Terminar\|Terminar]] 10:56, 23. Jan. 2013 (CET)
		+
		+	Also die TPD eines Linux faehigen SoC inkl. passendem SDRAM + WLAN PHY sind natuerlich verglichen mit der der BLDC Motoren inkl. Schaltverlusten an den Bruecken der Treiber fast schon verschwindend gering. Desweiteren wuerde ich natuerlich die Motorregelung und die Lageregelung auf dedizierten Mikrocontrollern auslagern. Hier kaemen beispielsweise ARM Cortex M0 und
		+	M3 der Familie STM32 von ST in Frage, alternativ koennte man sich natuerlich auch ueberlegen AVR8, XMEGA oder AVR32 einzusetzen, aber ich glaube man sollte hier ARM den vorzug lassen,
		+	weil dies doch eher eine Architektur mit Zukunft darstellt, desweiteren ist's natuerlich jedem frei gestellt Experimente mit Plattformen der Wahl zu machen. Ich wollte nur alternative
		+	Moeglichkeiten aufzeigen, bzw nur erwaehnen, dass ich damit experimentieren moehte --[[Benutzer:S4sh4\|S4sh4]] 11:34, 23. Jan. 2013 (CET)