Polskie Forum FPV

Super! Czekam cierpliwie :)

Na wstępie kilka założeń/uwag odnośnie funkcjonalności "acro".
Jako punkt wyjścia przyjmuję założenia podobne do ArduPlane, czyli:
-szybkość rotacji (w osi pitch/roll) jest proporcjonalna do wychylenia drążka wysokości/lotek.
-Model obraca się bez ograniczeń, lub opcjonalnie do zadanej wartości max kąta (tryb "nauka")
-Maksymalna szybkość rotacji jest parametryzowana (domyślnie 180stopni/sekundę).
-Po puszczeniu drążków model nie wraca do poziomu ale zachowuje swoje położenie (przestaje się obracać). Opcjonalnie model może wolno wracać do pozycji poziomej (parametr)
-Autopilot nie ingeruje w poziom gazu i nie próbuje utrzymać wysokości ani nie kontroluje przeciągnięcia
-Autopilot nie stabilizuje kierunku lotu (heading/Yaw)
-Dobrze byłoby, gdyby w locie "na żyletkę" autopilot używał steru kierunku do utrzymania pochylenia modelu (nie wiem jak jest teraz, kiedyś ardupilot tego nie miał)
-wybór trybu z przełącznika trybów (widzę dwie opcje: rozpoznajemy 4 stany wysterowania kanału MODE, albo z menu wybieramy zestaw OFF/STAB/AUTO albo ACRO/STAB/AUTO lub OFF/ACRO/AUTO).

Czy to odpowiada Twoim oczekiwaniom?

Zbig pisze:-Dobrze byłoby, gdyby w locie "na żyletkę" autopilot używał steru kierunku do utrzymania pochylenia modelu (nie wiem jak jest teraz, kiedyś ardupilot tego nie miał)

Nie jestem przekonany że to dobra opcja (a w skrzydle niewykonalna), zauważ że w jednym z punktów masz podobna sytuację z headingiem/ yawem i również nie chcesz jej zapobiegać... Acro to taki manual na sterydach troszkę (zawsze się śmieje że to manual z wyłącznikiem wiatru ;)

Reszta super - dokładnie tak to ma działać :)

Edit: oczywiście szybkość rotacji definiowana osobno dla pitch i osobno dla roll

rychoo pisze:

Zbig pisze:-Dobrze byłoby, gdyby w locie "na żyletkę" autopilot używał steru kierunku do utrzymania pochylenia modelu (nie wiem jak jest teraz, kiedyś ardupilot tego nie miał)

Nie jestem przekonany że to dobra opcja (a w skrzydle niewykonalna), zauważ że w jednym z punktów masz podobna sytuację z headingiem/ yawem i również nie chcesz jej zapobiegać... Acro to taki manual na sterydach troszkę (zawsze się śmieje że to manual z wyłącznikiem wiatru ;)

Reszta super - dokładnie tak to ma działać :)

Edit: oczywiście szybkość rotacji definiowana osobno dla pitch i osobno dla roll

W sumie masz rację, to ma stabilizować obroty w osiach modelu (local frame), a nie samo położenie modelu w stosunku do ziemi (global frame).
Szybkości definiowane osobno.

Rozpoznałem temat, trochę rzeczy trzeba będzie ogarnąć w OSD, autopilocie i FPV_managerze. Ale nie powinno być problemów.

Przyjęte do realizacji. Możesz składać zamówienie

Wprawdzie idzie długi weekend (wyjeżdżam), ale zanim wszystko poskładasz powinienem być już gotowy z wersją testową.

pięknie, zamowienie poszlo, czekam na sprzet, instaluje i bedziemy testowac :)

Zbyszku pamiętaj proszę o możliwości wpłynięcia na siłę stabilizacji w zależności od prędkości modelu ,oraz jeśli to możliwe o dodatkowym kanale podpinanym z menu głównego do regulacji siły stabilizacji poszczególnych osi.
Pozdrawiam Piotr

Kompenasacja od prędkości jest już od dawna w zaawansowanych ustawieniach stabilizacji. Dodatkowy kanał do regulacji siły stabilizacji wpisuję na listę TODO, ale nie wiem jeszcze kiedy wejdzie do realizacji.

Pierwsza wersja trybu ACRO już zrobiona, teraz testy i szlifowanie funcjonalności.

Beta5 z trybem ACRO jest gotowa:
http://www.bigaj.com.pl/fpvsystem/
Doszły dwa parametry do konfiguracji max. szybkości obrotów w osi pitch i roll, oraz konfiguracji przełącznika trybów lotu.
Menu autopilota zostało przegrupowane - opcje RTH/AUTO mają teraz swoje submenu AUTO flight (nazwa robocza)

Ja w tym tygodniu powinienem skończyć przerabiać kabelki i mocowanie auto0ilota, w weekend będę testował

Edit: właściwie mam jedno pytanie, będę podpinal czujnik acs dwukierunkowy, miałem go zasilonego z 3v3 w kfc32f3, chciałbym tutaj także go zasilić takim napięciem żeby nie dobierać ponownie offsetu/skali, z tego co widziałem mógłbym się wlutowac kabelkiem w pole 3v3 ze zwory zasilania gps... Powinno działać bo ten czujnik nie potrzebuje tyle prądu co gps do zasilania...??

Mozesz wykorzystac 3v3 ze zwory zasilania. Ale i tak będziesz musiał go skalibrować w OSD.

Zagadnienia odnośnie BuddyFlight:
- widzimy się na radarku po wspólnym starcie. Po jakimś czsie oddalam się dość znacznie, powiedzmy że modele są ponad 8km od siebie. Modemy się nie widzą a na radarze "zapamiętana" jest ostatnia znana pozycja drugiego modelu (wyświetlana literka na zmianę z X) - zakładam że tak ma być ponieważ pozwala potencjalnie znaleźć "kreta".
- po znacznym oddaleniu modele się zbliżają do siebie, powiedzmy że praktycznie w punkt np baza (wspólna). Na radarze mam nadal namiary na punkt utraty komunikacji. Pozycja drugiego modelu jest "zamrożona", nie aktualizuje się - to chyba nie jest OK.

Zbyszku, głównie chodzi mi o wyjaśnienie sytuacji opisanej w drugim punkcie, czy tak ma być czy to jakiś błąd?

Jeśli wróci komunikacja modemów, pozycje powinny znów się zacząć aktualizować. Przerwa w komunikacji (nieważne jak długa) nie ma znaczenia.

Skoro już wiadomo jak powinno być, to jak zdiagnozować co jest nie tak:
- jak zdiagnozować czy modemy się komunikują, w szczególności że ponownie się komunikują?

Na modemach nie ma żadnych diodek informujących o stanie pracy modemu. Czy jest jakaś możliwość diagnozy stanu pracy modemu, np. po wylądowaniu i podpięciu do FPV Managera, a może jakiś test w menu serwisowym?

Czy informowanie o pozycji modelu przez modem jest rozgłaszany czy na żądanie innego modemu (może jest jakiś problem z jednym z modemów) ?

diody led są ale zakryte koszulką termokurczliwą