Diskussion:Multikopter

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. --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. --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. --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 --S4sh4 11:34, 23. Jan. 2013 (CET)