Quadrocopter-sprawdzenie schematu

[Sabre]

Dżony, a przemyślałeś chociażby podłączenie tego imu? Czy I2C wydoli z prędkością przesyłu danych z co najmniej żyra i akcelerometru? Od tego powinieneś zacząć.

[KD93]

To ja zaproponowałem Dżonemu napisanie posta na forbocie, po ostatniej decyzji w sprawie quadrocopterów.

Miał problem, ponieważ odwrotnie podłączył gniazdko USB, później nie umiał się porozumieć z procesorem. Zaproponowałem mu żeby zwarł RX i TX, wychodzi na to że FT pracuje prawidłowo, wysyła i odbiera dane. Bobby znalazł kolejny błąd, MISO/MOSI zamiast PDI/PDO. Dżony to poprawił, ale dalej jego układ nie działa. Programowanie ma przebiegać w taki sposób.

Osobiście widziałem już żadnych błędów, poleciłem napisanie posta na forbocie, ponieważ, że pozwolę sobie zacytować fragment decyzji:

Wskazane tematy rozmów:

- dodawania autonomii do quadrocopterów

- czujniki i algorytmy wspomagające sterowanie

- komputery pokładowe quadrocopterów

Wchodzę na następny dzień na forum i oczom nie wierzę. Pierwsza odpowiedź:

Chyba nie o to chodziło Trekerowi 😉

A później cała strona postów, których treść można zamknąć w jednym sformułowaniu: "nie rób sam, nie opłaca się". Jeden Mirek udzielił odpowiedzi pomocnej i na temat. Najpierw narzekanie, że opisuje się roboty zrobione z gotowców, a później jak ktoś planuje sam powalczyć ze sterownikiem, to się go odsyła.. do gotowców. Gdzie logika?

Poza tym, pytanie jest proste. Czy schemat zawiera błędy. Jeśli nie zawiera, to chyba układ powinien się dać uruchomić (zaprogramować procesor). Nie da się, więc coś jest nie tak, więc powinno się pomóc znaleźć problem i go rozwiązać.

Wiem że się nie znam, wiem że program do quadro jest cholernie skomplikowany i że dla kogoś, kto chce mieć małego quadrocoptera opłacalniejsze jest kupienie gotowego sterownika. Ale Dżony, jak wyraźnie napisał, mimo wszystko chce się podjąć budowy własnego sterownika. A wy w kółko to samo. Nie prosi nikogo o pomoc w programie, tylko o sprawdzenie poprawności połączeń na schemacie. Nie umiecie pomóc - nie piszcie.

Dla mnie 3/4 tego tematu to po prostu spam i brak związku z tematem. Widocznie Forbot nie jest jednak gotowy na tematykę quadrocopterów w kontekście robotyki, co czyni całą niedawną dyskusję bezsensowną.

[Sabre]

KD93, masz rację, ale jest też drugie dno. Skoro Dżony ma problem ze schematem to nie wiem czy sobie poradzi z oprogramowaniem chociażby. Ja jako osoba, która walczyła z mikrokopterem, mam jakieś doświadczenie w tym temacie i powiem szczerze, że gdybym miał zaczynać raz jeszcze, a na pewno wrócę do mojego mikrusa, to poszedłbym inną drogą. Skoro można kupić naprawdę niezłą elektronikę i to taniej niż zakup osobno części to jednak zdecydowałbym się na gotową a skupił bardziej na chociażby oprogramowaniu. U mnie całe imu i jego soft są autorstwa naszego forumowicza grabo, więc można powiedzieć, że poszedłem na łatwiznę. Nie mniej i tak nie było i nie jest łatwe złożenie naprawdę niewielkich rozmiarów kopterka. Nie wspominając już o kosztach, które w moim przypadku sięgnęły chyba nawet ponad 1000zł.

Będę się trzymał dalej mojego zdania, gdyby to jeszcze był kopter na bezszczotkowcach to popieram w 100% inicjatywę budowy własnej elektroniki, ale nie dla silników szczotkowych. Nie bez powodu ja wybrałem miniaturowe silniki 3f, fakt, że są droższe, pobierają większy prąd i wymagają regulatorów 3f, ale za to są prawie nieśmiertelne o ile kopter nie zaliczy kreta lub ściany i to dość mocno. Szczotkowce trzeba bardzo często wymieniać, jakbyś poczytał po innych forach to ludzie kupują nawet po 10szt. na zapas, bo one bardzo krótko wytrzymują, a wierz mi, że dobranie później 1 silnika do pozostałych jest w zasadzie niemożliwe i musisz wymienić cały komplet.

[Dżony]

No i fajnie z pomocą KD93, udało się już większość rzeczy uruchomić 😉 teraz już tylko dostać się do procka..

[ Dodano: 13-07-2013, 15:08 ]

Pragnę poinformować, że już wszystkie błędy wyeliminowałem 😉 Za uwagi i sugestie dziękuję 😉

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[marek1707]

Pewnie już za późno by przyłączyć się do dyskusji o schemacie ale chciałbym jeszcze dorzucić kilka zdań od siebie.

Urządzenia współpracujące z USB mogą być dwojakiego rodzaju: bus-powered i self-powered. Te pierwsze - jak sama nazwa wskazuje korzystają z zasilania prowadzonego kablem USB i muszą spełniać dość restrykcyjne warunki jeśli chodzi o pobór prądu. Najważniejszy z nich to ograniczenie poboru do 100mA chyba, że zostanie uzgodnione inaczej. "Dogadywanie się" przeprowadzane jest w fazie enumeracji urządzenia, gdzie host odczytuje informacje zaszyte w pamięci konfiguracyjnej. Jednym z parametrów jest właśnie maksymalny pobór prądu. Urządzenie może zeznać, że potrzebuje np. pełnych 500mA a host może to żądanie odrzucić. Duże komputery raczej tego nie robią bo mają duże zapasy ale już np. laptop może uznać, że przekracza to jego budżet mocy i takiego urządzenia nie dopuścić do pracy. Dopiero gdy wszystko jest OK można załączyć większe obciążenie. Do sygnalizacji tego stanu układy FTDI mają specjalne wyjścia. Na Twoim schemacie widzę ładowarkę akumulatora podpiętą wprost do USB (czyli jest to właśnie bus-powered device) i czerpiącą prąd bez żadnej kontroli - to niedobrze. Powinna być załączana sygnałem #PWREN dostępnym z FT232. Pamięć konfiguracji, czyli m.in. sposób zasilania, pobór prądu oraz sygnały CBUS tego układu ustawiasz za pomocą prostej aplikacji dostępnej na stronie FTDI.

Kolejną sprawą która rzuca się w oczy na dzień dobry to dziwny sposób zasilania układu FTDI. Zrobiłeś zasilanie interfejsu USB z szyny z jednoczesnym podtrzymywaniem drugiej strony - czyli procesora i jego sygnałów, z akumulatora. Taka konfiguracja spowoduje, że w czasie odłączenia kabla USB układ FT232 będzie widział na swoich pinach sygnały wyższe niż własne - brakujące w tej chwili - zasilanie. To niedopuszczalne. Powinieneś zasilać FT232 tak jak w konfiguracji self-powered z napięcia obecnego zawsze, czyli z VCC z jednoczesnym podpięciem jego wejścia #RESET przez dzielnik do VBUS. Niestety dane katalogowe układu FT232R są przygnębiające: aby korzystać z dobrodziejstwa wewnętrznego generatora musisz zapewnić zasilanie tego układu w granicach 4.0-5.25V a więc praca na 3.3V odpada.

Szyna CBUS jest dowolnie programowana więc możesz tam wypuścić dowolne sygnały z zestawu przewidzianego przez producenta. Jaką więc rolę pełni R15? Mam nadzieję, że nie napiszesz "nie wiem, schemat przerysowałem z netu"..

Skoro programator używa tylko sygnałów sterowania modemem to może warto przepuścić pozostały UART przez USB i mieć jakąś kontrolę przy uruchamianiu kodu? Chyba zamieniłeś też sygnały RXD z TXD na UART1.

Czy dynamika sterowania silnikami w kopterkach nie wymaga by mieć aktywne hamowanie? Może warto dać jednak bardziej skomplikowane sterowanie i odżałować jeszcze po jednym tranzystorze na silnik?

Jakieś oporniczki szeregowe w bramkach - jak już pisał jeden z Kolegów, też by się przydały. Obecnie do każdego wyjścia PWM masz podłączony de facto kondensator ładowany przez procesor w każdym cyklu PWM od zera. A wiesz skąd weźmie się energia do jego naładowania? Z zasilania. Pracujące z tego samego timera trzy wyjścia PWM będą jednocześnie załączać lub wyłączać trzy kondensatory co na wewnętrznych liniach zasilania procesora będzie widoczne jak poważne spadki napięcia VCC lub - odpowiednio - wzrost napięcia GND. Chyba tego nie chcesz, prawda? W szczególności, że źródłem zasilania jest dość "miękka" pompa ładunkowa.

Przewidziałbym jednak kwarc - inaczej nie wyjdziesz poza 8MHz a nigdy nie wiadomo, czy to wystarczy dla ciekawych algorytmów jakie z pewnością wymyślisz 🙂

Wiem, że brzydzimy się tutaj zdalnym sterowaniem ale kopterek nie będzie od razu pierwszego dnia superautonomicznym robotem zwiadowczym zatem może jednak choć wejście z odbiornika podczerwieni? No bo jak to będzie, włączysz go i rzucisz w powietrze? Może warto położyć na ziemi, oddalić się dwa kroki (lub nawet przy starcie z ręki) i dopiero wtedy pilotem IR odpalić.. no właśnie te inteligentne algorytmy poszukiwania, detekcji i bezlitosnego zniszczenia celu..

Przemyśl sobie rozwój tej konstrukcji, co Ci będzie potrzebne w kolejnych krokach i jakie podsystemy powinieneś umieścić na pokładzie by je zrealizować. Nie od razu Kraków.. no wiesz.

EDIT: Acha, zapomniałem dodać, że programowanie ATmegi w ten sposób (sygnały modemowe przesyłane przez USB) będzie wprost tragicznie wolne. Będziesz potrzebował dużo herbaty i cierpliwości. Może warto jednak zrobić lokalne złącze SPI żeby tylko wgrać jakiś bootloader szeregowy a potem już kolejne wersje aplikacji wpychać przez UART na USB?

[Dżony]

marek1707, po pierwsze dzięki za tak dogłębne przeanalizowanie schematu! 😉

Do dyskusji wcale nie za późno, cały czas sobie jeszcze różne rzeczy sprawdzam na PCB, które nie jest już wstanie się wzbić w powietrze 😉 .

Bardzo mnie zainteresował drugi akapit Twojej wypowiedzi odnośnie bus-powered. Faktycznie dobrze by było kontrolować takie rzeczy. Zajrzałem do noty FT232RL i właśnie myślę jak można by pogodzić uruchomienie na pinie CBUS3 sygnał #PWREN zarówno z ładowarką, która jest na 5V i resztą układu, który jest na 3.3V? Niestety żaden konkret mi nie przychodzi do głowy... Obecna wersja działa bez problemu ale lepiej by było żeby quadzik był bardziej profesjonalnie wykonany. Programikiem FT_Prog do ustawiania rożnych rzeczy już się bawiłem 😉

Odnośnie trzeciego akapitu domyślam się w tej kwesti nie jestem w stanie niczego poprawić, skoro self-powered jest od 4V?

Tak, będę korzystał z UART1, bo nie mam już miejsca zbytnie na kolejny scalak przełączający UART z ISP. A oporniki na bramkach jeszcze się zmieszczą więc je dodam i miejsce na kwarc również się znajdzie.

Co do sterowania to zamierzam kontrolować go BT-112 za pomcą komputera, tak że jakieś dodatkowe rzeczy do startowania go myślę nie będą potrzebne, ale jakieś wolne piny wyprowadzę.

[marek1707]

Sterowanie ładowarki możesz zrobić bardzo prosto. Sygnałem #PWREN wysteruj tranzystor pnp zawieszony emiterem na plusie lokalnego +3.3V. Z kolektora daj opornik np. 10k do masy i z tego punktu wysteruj bramkę małego N-MOSFETa. W jego drenie daj szeregowo opornik i podłącz go do PROG łądowarki równolegle do istniejącego już opornika R2. Jednocześnie zmień jego wartość tak, by bez załączonego MOSFETa prąd ładowania był np. 80mA a dopiero po poprawnej enumeracji i załączeniu tranzystorów wzrastał do 500mA. Gdybyś chciał być absolutnie poprawny powinieneś też wykrywać stan suspend szyny USB (kolejny sygnał na CBUS) i wtedy w ogóle wyłączać ładowarkę ale o ile pamiętam możesz zażądać w konfiguracji FT232, by ta gałąź nigdy nie była "zawieszana" przez hosta.

No niestety zasilanie zrobione jak obecnie na schemacie nie może zostać. Rozwiązaniem jest konfiguracja self-powered (VCC i VIO układu podłączone do VCC=3.3V procesora) z kwarcem zewnętrznym. Tracisz dużego plusa FT232R - generator wewnętrzny, ale zyskujesz możliwość poprawnego działania w szerszym zakresie napięć - właśnie od 3.3V.

Mógłbyś też:

a) wziąć te 12MHz z kwarcu procesora (ale to zmusza do takiego a nie innego kwarcu dla ATmegi + jakiś bufor)

b) zasilać interfejs w trybie bus-powered (VCC=VIO=5V z USB) a między FTDI a procesor wstawić w odpowiednią stronę kilka buforów trójstanowych np. 74LVX125 zasilanych z 3.3V. W jedną stronę odcinały by sygnały procesor→FT232 gdy ten ostatni nie ma zasilania a te w drugą stronę robiły by konwersję 5V/3.3V dla sygnałow FT232→procesor. No trudno, systemy z wieloma zasilaniami "same" się jakoś komplikują..

Nie do końca zrozumiałem to o przełączaniu UARTów ale pamiętaj, że masz dwa. To nic, że jeden będzie chwilowo zużyty na złącze programatora SPI. Potem, po wgraniu bootloadera te same piny mogą obsługiwać UART.

Jeżeli będziesz używał tego samego UARTa do ładowania kodu przez bootloader i do późniejszej komunikacji przez BT z PC to może warto zrobić jakąś zworkę przełączającą tryb "ładujemy nowy kod" na "uruchamiamy aplikację". Wtedy bootloader wiedział by, czy ma się przez BT zgłaszać czy sobie odpuścić i odpalić docelowy, wgrany wcześniej program.

Jeżeli będziesz miał BT to po co Ci USB? Do samej ładowarki wtyczkowej, dostarczającej samej "mocy" FT232 nie jest potrzebny.

Co z driverami silników (hamowanie)? Nie dyskutuję to o sensowności szczotkowych. Widocznie na każdego czekają gdzieś w trawie jego własne grabie..

[Dżony]

marek1707, potem wrzucę już cały poprawiony schemat jak już ten fragment będzie poprawny, czy tak jest dobrze(pomijając już zasilania, tylko czy sam sposób jest poprawny)?

[marek1707]

Wiem, że pośpiech itp ale.. nie osłabiaj mnie - liczyłem na coś więcej. Bramkę podłączyłeś do masy? To jak chcesz włączać prawy tranzystor? On ma brać sygnał z kolektora pnp. A oporniki? Przecież jeden powinien być wprost do masy i wyznaczać prąd 100mA a drugi ma być załączany przez MOSFETa i zwiększać prąd do 500mA. VSS ładowarki musi być zawsze twardo podłączone do masy a tu co, przez tranzystor? VCC tranzystora pnp musi być tym samym z którego zasilasz VIO FT232. Inaczej będziesz przez złącze BE pompował do wyjścia CBUS prąd, gdy zasilania zabraknie. Zasadzasz się na procesory i jednostki inercyjne a dwóch tranzystrów nie umiesz sklecić? Lekka porażka, nie sądzisz?

I zamiast wrzucać cały "poprawiony schemat" opisz najpierw które rozwiązanie wybrałeś i dlaczego. USB czy BT? Jak będziesz programował procesor? Itd. Schemat narysujesz jak już będziesz przekonany co i jak chcesz zrobić.

[Dżony]

marek1707, chcę zostać przy programowaniu procesora z USB za pośrednictwem FT232RL-to rozwiązanie jest używane w zestawach uruchomieniowych i nawet przy dużych programach nie zauważyłem żeby było to wolne, wręcz przeciwnie. Poza tym jest bardzo proste i nieskomplikowane. BT wykorzystam tak jak już wcześniej pisałem do sterowania kopterkiem za pomocą komputera i kto wie może do jakiś danych zwrotnych.

Tu fragment tego co z rana było źle:

[marek1707]

Znacznie lepiej. Zamiast R3 możesz dać LED z opornikiem szeregowym kilkaset omów - będziesz wiedział czy i kiedy FT232 "zalogował" się do USB.

Chyba wszystkie rozwiązania programowania AVRów są "proste i nieskomplikowane". Nie widzę przewagi dwóch różnych interfejsów nad jednym w układzie, gdzie będziesz liczył każdy gram. Wywalając FT232 zostałoby tylko gniazdo USB do podłączenia zewnętrznej ładowarki np. od jakiegoś telefonu wyposażonego we wtyczkę mini-B i odpadły by problemy z przełączaniem prądów ładowania. Za to moduł BT mógłbyś umieszczać na pokładzie w przewidzianym dla niego złączu gdybyś chciał ładować nowy kod lub mieć telemetrię on-line stanu kopterka a gdyby już wszystko działało - mógłby latać bez tej dodatkowej "smyczy". Najprostszych modułów BT w ogóle nie trzeba programować jakimiś komendami. Włączasz takiemu zasilanie 3.3V i pojawia się tunel transmisyjny jakbyś miał UART podłączony wprost do portu COM PCta.

[Dżony]

Dzięki za pomoc, bo Twoje uwagi są naprawdę trafione i dają do myślenia ( co poprawić, żeby było jeszcze lepiej) 🙂 Moduł BT już mam gotowy i działa 😉 z diodkami LED informującym o stanie modułu. To on będzie podłączony do UART1. Jutro wezmę się dalej za poprawianie schematu i wyprowadzenia wolnych pinów 🙂

[Marooned]

Wchodzę na następny dzień na forum i oczom nie wierzę. Pierwsza odpowiedź:

Chyba nie o to chodziło Trekerowi 😉

Errare humanum est. Widać to ja miałem błędne pojęcie o tym o co chodziło górze.

Ot, w innych wątkach spotykałem się już z rozważaniem, czy "sprawdzanie schematu" kwalifikuje się na wartościowy wątek.

Rozważałem też usunięcie posta, ale Forbot nie zezwala mi na to.