Skocz do zawartości

Tablica liderów


Popularna zawartość

Pokazuje zawartość z najwyższą reputacją 05.03.2020 we wszystkich miejscach

  1. 2 punkty
    W artykule masz o rezystancji wewnętrznej baterii - można to zamodelować rezystorem i tyczy się to jakości użytych środków chemicznych. Im szybsze reakcje tym więcej elektronów przepłynie - da się uzyskać większy prąd. Rezystancja ta zwiększa się wraz ze zużyciem baterii (reakcje chemiczne dążą do stanu ustalonego). Dlatego jest możliwe, że bateria ma jeszcze kilka woltow (gdy mierzysz ją nieobciążoną) ale amperów to z niej wiele nie wyciśniesz - co więcej po podłączeniu czegokolwiek zobaczysz duży spadek napięcia. Tu wchodzę jeszcze na pkt .1. Możesz mieć mniejsze/większe napięcia na baterii ale nie sugeruj się, że prąd będzie adekwatny - po to ten przykład z baterią 12V i akumulatorem. Pojemność jest ważna, ale mamy tu też inny parametr: wydatek (moc jaką dysponujesz równoważna z prądem jaki da się uzyskać). Bateria 9V jest stosunkowo mała do swojej pojemności i wykonana jest z bezpieczniejszych acz mniej wydajnych substancji, stąd ma małą pojemność i niewielki prąd maksymalny. Bateria 1,5V zależnie od jakości może oddać do 3V na ogniwo, łącząc je w szereg uzyskasz 6V a nawet 9V (jak dodasz jeszcze 2) i 3A. Ale jak rozładujesz bateryjki to zamiast N x 1,5V 3A będziesz miał np. N x 1,2V 0.5A. Skąd to? Rezystancja wewnętrzna, reakcje chemiczne ustają, bateria jest rozładowana. Offtop: dlatego przy pomiarze zużycia baterii dość dobrym wyznacznikiem jest prąd zwarciowy - im większy tym bateria ma się lepiej. Zatem czym różni się bateria 12V od akumulatora? Gabarytami, pojemnością, mocą, gęstością energetyczną, mocą -> maksymalnym prądem. I tu skok do 3pkt. Dla źródeł zasilania podaje się napięcie i prąd (ale tu podkreślam maksymalny prąd). Na ładowarce do smartphona masz 5.1V i jakieś 2A. Zależnie czy telefon jest mocno rozładowany to będzie inny prąd ładowania: 10% baterii to zapotrzebowanie jest większe i ładowarka odda może 2A, 99% baterii to ładowarka odda może 500mA. To samo tyczy się baterii o których piszesz, mają swój limit ale nie zawsze go wykorzystujesz. Dlatego na tej samej baterii jedno urządzenie działa godzinę, inne lata. Konkretnie do pytań: pobieranie prądu (A) oznacza jaki jest w danym momencie przepływ elektronów w czasie. Nomenklatura podobna co w motoryzacji: z jaką prędkością jedziesz? 120km/h. urządzenie nie pobiera całego prądu bo nie potrzebuje, można zamodelować to rezystorem podłączonym do źródła zasilania, małe zapotrzebowanie -> duża rezystancja i mały prąd. Ale gdy pojawi się coś co nie stawia dużego oporu (jest w stanie przepuścić większy prąd, ma większe zapotrzebowanie) to ładunki pomiędzy 2 chemicznymi elektrodami nie mają niczego co im bardzo przeszkada i mogą płynąc w większej liczbie (zmierzone w czas to prąd).
  2. 1 punkt
    Cześć! Powoli zauważam, że roboty tego typu zaczynają wymierać i odchodząc na lf-ową "emeryturkę" chciałbym zostawić jakiś ślad po swoim projekcie. Choć na zawodach nigdy nie szczędzę informacji na temat swojego robota i chętnie dzielę się wiedzą oraz doświadczeniem w temacie, to mam wrażenie, że ilość lepszych robotów w konkurencji nie zwiększa się, a nawet spada. Na zawodach starzy bywalce ścigają się między sobą, a młodzi pewnie zniechęcają się do konkurencji, ze względu na wysoki próg wejścia do walki o nagrody. Cukiereczek - LineFollower bez turbiny (Nazwa nawiązuje do mojej poprzedniej konstrukcji - Candy). Jest to robot, którego zbudowałem w ramach pracy przejściowej magisterskiej między styczniem a marcem 2018r. Debiutował na zawodach Robomaticon 2018 w Warszawie, gdzie zajął 3 miejsce, zaraz za Candy (zabrakło czasu na napisanie sensownego programu). Później rozwijane było oprogramowanie, które zostało tematem pracy dyplomowej. Wydaje mi się, że jest to obecnie najszybszy robot w swojej kategorii w Polsce, aczkolwiek scena LF od 2018r. mocno się uszczupliła - być może o potencjalnie szybszą konstrukcję. Główne cechy: 12 czujników linii Mikrokontroler STM32 F7 IMU: żyroskop + akcelerometr RGB Lidar ToF USB karta µSD Bluetooth 4.2 Własny mostek H Enkodery magnetyczne 1. Konstrukcja mechaniczna Wydaje mi się, że kształtem przypomina robota Fuzzy, którym swego czasu mocno się inspirowałem przy robocie Candy. Mam nadzieję, że nikt tutaj nie uzna robota za bezpośrednią kopię - kształt jest zdecydowanie inny, podyktowany konkretnymi założeniami i doświadczeniami z poprzednich konstrukcji. Podwozie stanowią 2 moduły PCB: płytki głównej oraz płytki z czujnikami linii, połączone ze sobą taśmą FFC i usztywnione węglową listewką modelarską. Ślizg przedniej listewki zapewniają 2 ścięte łby nylonowych śrubek, z doklejoną podkładką teflonową. Z tyłu robota doklejony jest wheelie bar, w postaci kawałka listewki węglowej ze śrubką oraz teflonem. Wielokrotnie przerobiony temat - gdyby nie podpórka, robot wywracałby się do góry dołem oraz podskakiwał na każdym zakręcie. Napęd: 2 silniki szczotkowe Pololu HPCB 10:1 z obustronnym wałem, na który nałożono magnes 6x2.5 do enkodera magnetycznego. Koła to felgi wydrukowane na drukarce 3D z oponami Mini- Z. Nie dają takiej przyczepności jak poliuretan, ale nie udało mi się dobrać lepszych kół przy samodzielnym odlewaniu. Silniki zostały odrobinę podniesione podkładkami z PCB o grubości 1mm oraz kauczukiem tłumiącym wibracje. Do ich montażu wykorzystałem standardowe, plastikowe mocowania Pololu. Waga konstrukcji to 55.5g (66g z akumulatorem). Nie była priorytetem. 2. Elektronika Wszystkie płytki PCB zostały wykonane w firmie Techno Service z Gdańska. Płytka główna oraz płytka z czujnikami to płytki 4-warstwowe, pozostałe: płytki enkoderów oraz płytka IMU, 2-warstwowe. Schemat oraz layout stworzyłem w programie Altium Designer. Robot może być zasilany z akumulatora li-po 2-4S (6-17V) lub bezpośrednio z USB (bez możliwości uruchomienia silników). Oprócz pomiaru napięcia wejściowego, dodatkowo wstawiono układ pomiaru prądu pobieranego przez robota. Robot startuje obecnie z akumulatorami 2S, 180mAh, 50C. Sekcję zasilania (oprócz sekcji silnikowej) stanowi przetwornica 5V 1A, oraz układy LDO na napięcie 3.3V (osobne dla MCU, sekcji analogowej oraz czujnika IMU). Na płytce czujników znalazło się 12 transoptorów KTIR0711S. Są gęsto ułożone w jednakowych odstępach tworząc delikatny łuk. Zdecydowano się na proste rozwiązanie hardware'owe, dające równomierne odczyty z trasy. Przekombinowany układ czujników mógłby powodować dodatkowe komplikacje (różne odczyty na odsuniętych czujnikach, wpływ nierówności trasy - odległości sensorów od podłoża), więc wszelkie wykrywania dziwnych elementów na trasie realizowane są software'owo. Moduł IMU został zamocowany na padzie kauczukowym tłumiącym wibracje. Użyto sensora Invensense ICM-20602. Jak widać na zdj. poniżej, bardzo poważnie potraktowałem kwestię wibracji, które mają spory wpływ na odczyty. Wykorzystany czujnik posiada wysoką czułość i jest wrażliwy na wibracje i naprężenia. Sensor posiada dedykowaną linię zasilania z oddzielnego LDO o wysokim PSRR. Mostki H zbudowano na układach przekształtnikowych TI DRV8703 oraz tranzystorach N-FET: Toshiba TPWR8503NL. Taki układ mimo, że skonstruowany mocno na wyrost, pozwala na dowolne wysterowanie silnika, w tym zmianę kierunku obrotu bez żadnych dodatkowych opóźnień. Poprzednio stosowane mostki, popularne TB6612 wymagały łączenia kanałów i stosowania opóźnień. Wydajność takiego mostka szacuję na ok. 10A ciągłego prądu (z prądem chwilowym sięgającym +100A), sensownie byłoby lepiej dopasować mostek do wykorzystanych silników, jednak ze względu brak czasu na testowanie i chęć zamknięcia projektu w jednej rewizji PCB, postawiłem na "zero kompromisów". Dodatkowym założeniem była chęć ewentualnej zmiany silników na mocniejsze. Enkodery to AS5047P zamontowane na pionowych płytkach PCB. Podłączone zostały magistralą SPI. Dokonują pomiaru kąta absolutnego, z rozdzielczością 14 bitów. Uwzględniając przekładnię mechaniczną, można uzyskać ponad 160 tysięcy jednostek na obrót koła. Mikrokontroler zastosowany w projekcie to STM32F722 w LQFP64. MCU taktowany jest z częstotliwością 216MHz. Wszystkie piny procesora zostały wykorzystane. Posiada bardzo duży zasób obliczeniowy, znacznie większy od F1, dzięki czemu algorytmy sterujące mogą być skomplikowane i nie trzeba rezygnować z obliczeń na floatach. Karta µSD podłączona została pod SDMMC, na 4-bitowej szynie SDIO. Czujnik odległości to ST VL53L1X, laserowy czujnik Time of Flight, podłączony pod magistralę I2C. Został umieszczony na mocowaniu silnika, w celu uniknięcia dodatkowej bezwładności na listewce robota. Posiada spory zasięg, więc utrata długości z listewki nie jest problemem. Niestety czujnik domyślnie posiada spory field of view, który można odrobinę zmniejszyć tracąc również na zasięgu. Mam z tym czujnikiem sporo problemów. Na zawodach w Rzeszowie wyłapywał patyczki znaków drogowych postawionych przy trasie (inni zawodnicy nie mieli z nimi problemu) oraz bardzo często zdarza mi się, że silnik potrafi zawiesić czujnik podczas przejazdu. Rozwiązania w tej formie nie polecam. 3. Oprogramowanie Przy prowadzeniu projektu wspomagałem się programem CubeMX, a kod pisany był w środowisku Atollic TrueStudio. Poza bibliotekami CubeHAL, z których korzystam, całość własnego kodu została napisana w języku C++. Kod został podzielony na klasy, często wykorzystując przy tym mechanizm dziedziczenia. Użycie C++ pozwoliło wygodnie operować kodem, którego fragmenty wykorzystuję również w innych swoich projektach. Zrezygnowano z wykorzystania RTOSa (FreeRTOS w tym przypadku), ze względu na spory koszt samego OS przy pętlach rzędu 10kHz. STM serii F7 posiada wystarczająco dużo timerów, aby poszczególne zadania podzielić w niezależne pętle z własnym priorytetem. Do obsługi czujników linii, wykorzystano "tylko" 1 przetwornik ADC. Łączenie kilku przetworników w celu uzyskania szybszych pomiarów uznałem za bezcelowe, gdyż prawdopodobnie i tak musiałbym wyzwalać pomiary timerem, aby nadążyć z przetwarzaniem pomiarów. Obecnie pomiary wykonują się z częstotliwością ok. 56kHz i każda próbka brana jest pod uwagę podczas przejazdu. Pozycja linii wyznaczana jest w prosty sposób, przy pomocy średniej z wag przypisanych do każdego czujnika. Wagi czujników są u mnie odrobinę nieliniowe. Osobno rozpatrywane są "przypadki specjalne", gdy pod czujnikami brakuje linii itp. Osobny przetwornik wykorzystano do pomiaru napięcia i prądu. Liczona jest także zużyta pojemność baterii. Pętla sterowania silnikami z regulatorami PID wykonuje się z częstotliwością 8kHz. Nastawy zostały dobrane po części w Matlabie, później dostrojone empirycznie. Pętla żyroskopu również wykonuje się z częstotliwością 8kHz, taktowana jest przerwaniem dataready czujnika. Żyroskop wykorzystuję obecnie do omijania przeszkód oraz w odometrii. Główna pętla - podążania za linią wykonuje się z częstotliwością 400Hz. Sterowanie odbywa się poprzez typowy regulator PD, którego nastawy dobrane zostały metodą prób i błędów, bazując również na poprzedniej konstrukcji - przyspieszony proces. 4. Dodatki Sygnalizacja RGB - Zamiast niezależnych diod LED, wykorzystałem 4 diody WS2812B, które mogłem podłączyć do 1 pinu mikrokontrolera (a zużyłem wszystkie). Na diodach sygnalizowany są stany poszczególnych elementów robota, np. kalibracji żyroskopu, stanu baterii, stanu załączenia silników czy błędu regulatora linii. Interfejs USB - Jedyne złącze użytkowe w robocie. Jako, że interfejs SWD programowania wyprowadziłem w postaci padów do lutowania, "codzienne" programowanie robota odbywało się przez interfejs USB w trybie DFU. Napisany został kod umożliwiający przejście mikrokontrolera do wewnętrznego bootloadera, a następnie wgranie nowego programu. USB służył także do debugowania poprzez port COM. Karta µSD do logowania danych podczas przejazdu. Logowanie odbywa się w tle, w czasie wolnym procesora. Dane zbieram z częstotliwością ~1kHz i zapisuję binarnie w pliku (system FAT32). Logi dostarczyły mi sporo informacji "ukrytych" w robocie i przydały się w pracy magisterskiej. Poniżej przykładowe wykresy dla poboru energii, sterowania, czy utworzonej mapy trasy z uwzględnieniem omijania przeszkody. Aplikacja na smartfon pod moduł BT 4.2. Stosując moduł inny niż HC-05, zmuszony byłem stworzyć własną aplikację smartfonową do zmiany nastaw robota oraz zdalnego startu. 5. Osiągnięcia: 1 miejsce, LineFollower bez turbiny, Robomaticon 2019 w Warszawie , 9 marca 2019 1 miejsce, LineFollower Standard, XI Robotic Arena – Wrocław, 12 stycznia 2019 1 miejsce, LineFollower Enhanc3D, XI Robotic Arena – Wrocław, 12 stycznia 2019 1 miejsce, LineFollower Standard, Bałtyckie Bitwy Robotów w Gdańsku, 26-27 maja 2018 3 miejsce, LineFollower 3D, Bałtyckie Bitwy Robotów w Gdańsku, 26-27 maja 2018 1 miejsce, LineFollower Standard, Zawody ROBO~motion w Rzeszowie, 19 maja 2018 3 miejsce, LineFollower bez turbiny, Robomaticon 2018 w Warszawie, 3 marca 2018 Poniżej kilka filmów:
  3. 1 punkt
    Cześć, przedstawiam licznik G-M mojej konstrukcji. Mierzy promieniowanie β i γ w zakresach 1-15µS i 10-150µS (wersja fizycznie wykonana, z powodu usunięcia jednego dzielnika posiada tylko zakres 1-15µS, Licznik został porównany z rosyjskim licznikiem soeks 01M wykazując różnice 5-10% dla promieniowania β 10-15µS (siateczka żarowa lampy gazowej). Niestety z powodu użycia mało czułej lampy G-M [3G8B prod. XERAM] miernik nie nadaje się do pomiaru standardowego promieniowania tła, jednak możliwe jest podłączenie innej lampy poprzez złącze BNC, oraz ustalenie innego napięcia pracy z zakresu 300 - 700V, użyta lampa osiąga poprawne parametry pracy pracy przy 445V. Układ składa się ponadto z układu wykrywania impulsów generowanych przez lampę, oraz licznika cyfrowego na układach cd4026 (prod. TI) Układ wychwytywania impulsów nie jest prawdopodobnie optymalny, lecz działa poprawnie i jest w całości mojego pomysłu. Zliczone impulsy przelicza się według wzoru : x/6 impulsów/minutę = yµS/godzinę ( w przypadku wyższego zakresu dzieli się przez 0.6 zamiast 6. Opracowanie i wykonanie miernika zajęło mi ok. 2 - 3 tygodnie. w mierniku została użyta przetwornica wysokiego napięcia z rosyjskiej lampy stroboskopowej. Załączam schemat oraz film prezentujący działanie. W razie pytań lub rad zapraszam do dyskusji schemat:
  4. 1 punkt
    Jeśli jest na wszystkich 0v względem czarnego przewodu to znaczy, że BMS włącza terminal po podaniu stanu wysokiego na którymś z tych dwóch pozostałych przewodów trudno jednak stwierdzić ile volt powinien mieć ten stan wysoki. Ten drugi to być może wyście analogowego czujnika temperatury pakietu ale żeby mieć pewność trzeba by zajrzeć do dokumentacji. Otwieranie pakietu niewiele Ci wyjaśni. Możesz spróbować 3v przez jakiś większy rezystor dać na ten żółty lub zielony sprawdzając jednocześnie napięcie na czerwonym. Może też być koniecznym podłączenie jakiegoś wstępnego obciążenia na terminalu, jak masz jakiś większy rezystor to możesz nim połączyć czerwony i czarny i dopiero próbować. Jeśli BMS lub sam pakiet nie jest uszkodzony to jest duża szansa, że da się go uruchomić takim sposobem. * Większy rezystor w sensie mocy do obciążenie terminalu. Terminal jest wyprowadzony w parach przewodów żeby wydajność prądowa przewodu była większa.
  5. 1 punkt
    Witam chciałbym zrobić powerbanka z paru ogniw 18650 które wyciągnęłam z innych powerbanków którym nie działały przetwornice . Tylko pojawią się problem : Czy wszystkie ogniwa muszą mieć taką samą pojemność . Jeżeli nie to jaka może być różnica między pojemnościami ?
  6. 1 punkt
    Powinny być. Ale jak się chcesz upierać to możesz próbować, jakoś działać pewnie będzie ale bez pewności jak długo. Jeszcze raz powtarzam, że nie powinno się łączyć ogniw o różnych pojemnościach, różnych typów a nawet różnych producentów, kropka.
  7. 1 punkt
    Nie ma sprawy, miałem przy okazji ;) Owocnego debugowania życzę! :D
  8. 1 punkt
    @Gieneq Bardzo dziekuje za pomoc Wreszcie wszystko jest jasne i moge isc dalej
  9. 1 punkt
    A racja, jednak włącza przerwania, mój błąd, akurat nad czymś nieco innym siedzę. Wstaw sobie break pointa w debugerze i zobacz czy wchodzi do callbacka i do irq w pliku stm32xx....it.c. Trudno zgadywać w ciemno dlaczego nie wchodzi do callbacka skoro przerwania jednak włączyłeś. Być może funkcja hala wybiera na tą okazję inny callback, warto natomiast zobaczyć czy wchodzi do tej funkcji od irq. Jest to pierwsza funkcja wykonywana po wykryciu przerwania w której jest wywoływana funkcja wybierająca odpowiedni callback. Jak wstawisz breaka do obu to zobaczysz czy do nich wchodzi w ogóle czy nie. Wystarczy kliknąć 2 razy przy nr. linii to się nowy brak point doda i puść program niech leci ( tą pausostrzałką) i zmień stan pinu czy to fizycznie czy bitem w rejestrze w debugerze (view -> fsr czy coś, nie mam jak w tej chwili tam zajrzeć). Sprawdź też jeszcze w ustawieniach MX czy te przerwania są na pewno włączone.
  10. 1 punkt
    Jak chcesz używać przerwań kiedy ich nie włączasz???? NVIC to kontroler przerwań właśnie. Mam najnowszego MXa i nie robi mi żadnych błędów tego typu. Włącz MXa i zaktualizuj program i wszystkie biblioteki, których potrzebujesz (tam masz różne zakładki). Chodzi mi on jako stand alone i generuje nim projekty do atolic trueSTUDIO i SW4STM32, nie mam z nim żadnych tego typu problemów. Może używasz jakiejś wtyczki do eclipsa?
  11. 1 punkt
    a gdzie nvic init???? Może włącz przerwania w mx i spróbuj raz jeszcze. Poza tym po co Ci ta własna konfiguracja pinów? wyklikaj to w cubeMX i daj generate code i ewentualnie dodasz tylko co potrzeba. Zamiast pins() będzie gpio init wygenerowane przez cubeMX. a dokładnie MX_GPIO_Init(); i MX_NVIC_init();
  12. 1 punkt
    tam gdzie jest 5v na tym switchu daj kolektor tranzystora, emiter podłącz do masy a bazę przez rezystor 1k do esp i teraz jak dasz stan wysoki na pinie esp to będzie to emulowało fizyczne naciśnięcie switcha. Trzeba tylko masy połączy na obu płytkach. Czasami w ten sposób podłączałem do arduino różne urządzenia, o ile wykrywanie naciśnięcia przycisku nie jest skanowane w jakiś synchroniczny sposób to działa to dokładnie tak jakby ktoś przycisnął switch fizycznie. Tranzystor NPN, rzecz jasna.
  13. 1 punkt
    Układy scalone zostały wymyślone by zwiększyć niezawodność.Im mniej lutowań tym większa niezawodność.W przyrodzie obowiązuje prawo odkryte jakieś 170 lat przez wielkiego fizyka angielskiego Williama Rowan Hamiltona zwane zasadą Hamiltona czyli zasadą najmniejszego działania(dobrze opisana w książce Mechanika Teoretyczna autorów Rubinowicz,Królikowski).To prawo obowiązuje także w stosunku do nas, ludzi.ATmegi mają swoje przewagi nad STM-ami bo do obsługi jest proste,darmowe oprogramowanie.Hardware jest dostępny w niskiej cenie i jest niezawodny.W STM-ie jest odwrotnie.Wystarczy wejść na stronę Raisonance i zobaczyć ile kosztuje software.Syn poświęcił całe 5 minut w sprawie portu USB i nie rokował pozytywnego rozwiązania.Jako programista twierdzi,że hardware który,ma problem z komunikacją w zasadzie należy wyrzucić do śmietnika.Bo albo programujemy albo zajmujemy się naprawianiem komunikacji.Czy ma rację?Ma rację.Zaproponował STMCube32 jako narzucające pierwsze z brzegu rozwiązanie. STMCube32 jest programem z 2004r. 16 lat to w elektronice i informatyce to epoka albo dwie a może cztery albo i więcej.Dlatego najlepsze środowisko programistyczne to takie,które jest proste w obsłudze i działające w powszechnie używanych systemach(patrz zasada Hamiltona).Mikrokontrolery w istocie niewiele się różnią między sobą,w zasadzie różnią się rdzeniem a może i nie,peryferia są w zasadzie identyczne chociaż STM32 ma USB . W zastosowaniach do sterowania różnymi procesami wykorzystywane jest może 5-10% możliwości środowiska programistycznego.W swej istocie zwyczajowo program to kilkadziesiąt linijek a wiadomo im krótszy program tym krótsza pętla programu a to przekłada się na czas.W procesach sterowania 1ms czy 2ms w zasadzie nie ma znaczenia bo bezwładność elementów wykonawczych elektromechanicznych i niektórych elektronicznych jest wiele razy większa. Pewnie,że warto mieć kontroler który, taktowany jest np.72Mhz a nie 16Mhz i nie 8 bitowy a 32 bitowy.Miałem kiedyś w dyspozycji graficzny program Realizer.Miał fantastyczny symulator i był przez pewien czas polecany przez STM ale był dosyć topornym narzędziem programistycznym ale bardzo skutecznym.Raisonance rekomendowany też kiedyś przez STM ma namiastkę symulatora i język programowania C,C++.Arduino nie ma symulatora ale jest najlepszy bo jest ogólnie dostępny.Jak ktoś chce przetestować program może uruchomić Visual Studio dopisując odpowiednie interfejsy wejścia i wyjścia. STM wszedł w porozumienie z Arduino ze względów biznesowych gdyż zauważył jak wielkim rynkiem są wyroby oparte na ATmedze. Szwankująca komunikacja USB w STM32 kładzie się cieniem na STM.Przecież port USB jest portem podstawowym przy wymianie informacji .USB w STM-e daje jeszcze większą przewagę nad ATmegą i dziwi,że STM nie poświęca więcej uwagi na ten element. Mam nadzieję,że STM usunie problem kompleksowo poprzez włączenie odpowiednich sterowników do Arduino.Na razie widzimy dynamiczny rozwój STM-ów w Arduino bo STM postawił na Arduino. Marzeniem jest by nie trzeba było pisać artykułów "jak rozwiązać problem komunikacji poprzez port USB " tylko w sposób naturalny korzystać z ułatwień.
  14. 1 punkt
    Patent fajny, tylko jeszcze do kompletu potrzebujesz małe CNC do wycinania formy z aluminium. Chyba, że formę będziesz odlewać metodą wosku^Wplastiku traconego z wydruku drukarki 3D.
  15. 1 punkt
    Ten wpis bierze udział w konkursie na najlepszy artykuł o elektronice lub programowaniu, którego partnerem jest firma PCBWay (popularny producent prototypów PCB). W puli nagród karty podarunkowe Allegro o wartości 2300 zł. Sprawdź więcej informacji na temat konkursu » Protokół HTTP jest bardzo często uzywany w zastosowaniach IoT. Przede wszystkim decyduje tu prostota implementacji, dostępność bibliotek oraz możliwość współpracy z typowymi serwerami WWW bez konieczności instalacji dodatkowego oprogramowania. Szczególnie ta ostatnia cecha może być szczególnie przydatna z uwagi na ilość darmowych usług hostingowych, których nawet ograniczone parametry pozwalają na stworzenie prostej aplikacji niewielkim nakładem środków i przy użyciu minimalnej wiedzy. Niestety - z tą minimalna wiedzą nie jest już tak słodko. Autorzy popularnych bibliotek zakładają pewne minimum wiedzy u użytkowników i pomijają sprawy dla nich oczywiste. Użytkownicy zaś nie mogąc znaleźć jakichś informacji na temat podstaw - próbują coś zrobić metodą prób i błędów, co nikomu na zdrowie nie wychodzi. Spróbuję więc przybliżyć owo "minimum konieczne", aby nie trzeba było przekopywać się przez dokumenty typu RFC po ty tylko, by przesłać do serwera zmierzoną temperaturę na balkonie. Spis treści serii artykułów: Protokół HTTP w zastosowaniach IoT - część 1: trochę teorii Protokół HTTP w zastosowaniach IoT - część 2: budujemy serwer Protokół HTTP w zastosowaniach IoT - część 3: tworzymy klienta Zacznijmy jednak od czegoś prostszego, mianowicie od tego... czym jest URL. Każdy z pewnością zna to słowo, i większość z czytelników pewnie rozumie (nawet intuicyjnie) co to takiego. Aby jednak uniknąć jakichkolwiek nieporozumień proponuję zapoznać się z budową URL-a. URL (czyli Uniform Resource Locator) to znormalizowany sposób określania położenia dokumentu (zasobu) w Internecie. Ponieważ dla różnych schematów mogą istnieć różne części, skupmy się wyłącznie na protokole HTTP. Taki URL składa się z następujących części: Schemat - sposób, w jaki nasz dokument będzie przesyłany. W naszym przypadku będzie to zawsze http; Użytkownik - nazwa użytkownika, dla zasobów które mogą być serwowane różnie w zależności od użytkownika. Jeśli nie jest potrzebna, można ją opuścić wraz następujący po niej ewentualnym drukropkiem i hasłem oraz znakiem @; Hasło - jak sama nazwa wkazuje, hasło dostępu do dokumentu. Może wystąpić tylko wtedy, gdy podajemy użytkownika, a jeśli nie jest potrzebne, można je opuścić wraz z poprzedzającym dwukropkiem; Host - nazwa (lub adres IP) komputera, na którym umieszczony jest nasz dokument. Mimo, że dopuszczalne jest podanie w tym miejscu adresu IP, nazwa hosta wymagana jest jeśli serwer hostuje więcej niż jedną stronę www na tym samym adresie IP (czyli praktycznie wszędzie oprócz naszego domowego Arduino czy Raspberry); Port - port TCP, na którym nasłuchuje serwer. Jeśli jest to domyślny port (w przypadku http będzie to port 80) - może być pominięty wraz z poprzedzającym dwukropkiem; Ścieżka - czyli miejsce, gdzie na serwerze znajduje się nasz dokument. Zawsze rozpoczyna się znakiem '/', składa się z członów rozdzielonych znakiem '/' i może zawierać wyłącznie 7-bitowe znaki; Zapytanie - czyli parametr przesłany do skryptu na serwerze, jeśli ścieżka wskazuje na wykonywalny program a nie fizyczny dokument. Jeśli nie jest potrzebne, może być opuszczone wraz z poprzedzającym znakiem '?'. Używając popularnej pochodzącej z BNF notacji można to zapisać tak: <schemat>://[<użytkownik>[:<hasło>]@]<host>[:<port>]<ścieżka>?[<zapytanie>] Już słyszę pytanie: a co z fragmentem? Przecież wpisując adres do przeglądarki możemy zakończyć go znakiem '#' i etykietą informującą, który fragment ma się pokazać na ekranie... Otóż trzeba sobie uświadomić że to, co wpisujemy do przeglądarki nie jest tak naprawdę URL-em. Przeglądarki rozumieją pewien swój zapis - np. brak schematu, narodowe znaczki w ścieżce czy właśnie ten '#' i fragment. Pamiętać należy jednak, że w przypadku braku schematu przeglądarka użyje domyślnego 'http', narodowe znaczki zakoduje w pewien określony sposób a fragmentu w ogóle nie wyśle do serwera, będzie on potrzebny wyłącznie przeglądarce przy wyświetlaniu. Ponieważ dalej będziemy posługiwać się uproszczoną wersją URL-i, przyjmijmy że jego składnia będzie w większości przypadków następująca: http://<host><ścieżka>[?<zapytanie>] Należy tu wspomnieć o czymś jeszcze: o ile składnia URL-a nie narzuca żadnego specjalnego formatowania dla części "zapytanie", przyjęto zunifikowany zapis par <nazwa>=<wartość>, oddzielonych znakami '&'. I tu uwaga: w dalszej części będę posługiwał się również pojęciem URI (Unified Resource Identifier). Nie chcę wnikać w szczegóły, przyjmijmy więc uproszczenie, że URI identyfikuje zasób w obrębie serwera i składa się ze ścieżki oraz opcjonalnego zapytania (czyli de facto stanowi fragment URL-a). Tak więc wiemy już z czego się składa adres w Internecie, spróbujmy przyswoić sobie... podstawy protokołu HTTP Przede wszystkim musimy wiedzieć, że połączenie http składa się zawsze z zapytania wysłanego do serwera i odpowiedzi serwera. I koniec. Nie ma żadnej dalszej komunikacji, szczególnie po wysłaniu odpowiedzi serwer nie będzie pamiętać, o co go poprzednio prosiliśmy. Taki protokół nazywany jest bezstanowym, gdyż każde zapytanie rozpatrywane jest przez serwer niezależnie od innych. Oczywiście - serwer może wprowadzać dodatkowe mechanizmy zapewniające jakieś tam zależności (choćby mechanizm ciastek i sesji), ale nie należą one do protokołu ale do konkretnych wykonywanych na serwerze skryptów. Zacznijmy od zapytania - czyli tego, co klient (np. przeglądarka) przesyła do serwera. Zapytanie składa się z linii zakończonych parą znaków CRLF (czyli w notacji C++ "\r\n") i zawsze rozpoczyna się linią w postaci: <metoda> <URI> <protokół> Nas interesuje na razie metoda GET czyli "pobierz zawartość zasobu wskazanego przez URI" oraz obowiązujący protokół HTTP/1.1. Tak więc początkowa zawartość zapytania pobierająca np. zawartość głównej strony forum Forbota będzie miała postać: GET /forum/ HTTP/1.1 Następne linie stanowią nagłówki zapytania. Może ich być wiele - np. podających język przeglądarki czy rozpoznawane kodowanie, zawsze w postaci: <nazwa>: <wartość> Nas interesuje przede wszystkim nagłówek "Host" podający nazwę serwera. Warto również poinformować serwer, że oczekujemy na zakończenie połączenia po przesłaniu dokumentu, co załatwia nam nagłówek "Connection". Co prawda wartość "Close" jest dla tego nagłówka domyślną, ale warto przyswoić sobie zasadę podawania serwerowi wszystkiego co jest potrzebne do zwrócenia odpowiedzi - i niczego poza tym. Tak więc pełne zapytanie będzie wyglądać tak: GET /forum/ HTTP/1.1 Host: forbot.pl Connection: Close Każde zapytanie musi kończyć się pustą linią, aby poinformować serwer że już skończyły się nagłówki i teraz oczekujemy odpowiedzi. Możemy teraz spróbować przetestować najprostsze połączenie. W tym celu musimy jednak zaopatrzyć się w jakieś narzędzie, umożliwiające połączenie z siecią i przesłanie w obie strony tekstowych komunikatów. Mamy tu dwie możliwości. W przypadku Linuksa najwygodniejsze będzie użycie konsolowego narzędzia. Takim narzędziem może być telnet lub netcat. Ponieważ nie we wszystkich dystrybucjach są one zainstalowane na dzień dobry, może wystąpić konieczność doinstalowania. Dla Debiana i pochodnych (Raspbian, Ubuntu, Mint itp.) będzie to: sudo apt install telnet lub sudo apt install netcat I tu uwaga: w większości przypadków ostatnie polecenie zainstaluje nam netcat-traditional, czyli tradycyjną wersję programu. Z różnych przyczyn (szczególnie przy testach połączeń UDP) lepsza może by wersja openbsd, tak więc jeśli mamy taką możliwość warto ją zainstalować: sudo apt install netcat-openbsd Składnia obu poleceń dla naszych celów jest podobna: telnet <adres> <port> lub nc -C <adres> <port> Opcja -C w drugim przypadku włącza tryb przekazywania sekwencji CRLF zamiast LF (czyli po naciśnięciu ENTER) - co jak wspomniałem wcześniej jest wymagane dla połączeń http. Inną możliwością jest użycie znanego programu PuTTY. Nie będę tu opisywać procedur instalacji dla wszystkich możliwych systemów operacyjnych, należy jednak wspomnieć o ustawieniach: W ustawieniach sesji należy zaznaczyć "Connection type: RAW" (czyli "surowe" połączenie, bez żadnych dodatkowych protokołów) i "Close window on exit: Never" (bo nie chcemy, aby okno zamykało się od razu po odebraniu danych nie dając nam czasu na przeczytanie). W ustawieniach terminala natomiast "Implicit CR on every LF" (inaczej linie na terminalu "rozjadą się"). Takie ustawienia możemy sobie zapisać pod jakąś mądrą nazwą (np. tak jak w moim przypadku "raw http") i używać w wielu następnych testach. Spróbujmy więc na początek połączyć się z jakimś ogólnodostępnym serwerem. Na początek spróbujmy serwera Google. Wpisujemy więc następujące polecenie (lub łączymy się poprzez PuTTY z serwerem): nc -C www.google.pl 80 Oczywiście musimy sporo przewinąć w górę aby dojść do początku transmisji (przy okazji widać, że pozornie prosta strona Google wcale nie jest taka prosta). Możemy teraz zobaczyć dwa najważniejsze nagłówki odpowiedzi: HTTP/1.1 200 OK Taki nagłówek będzie zawsze pierwszą linią wysyłaną przez serwer. Składa się z trzech części: Protokół - w tym przypadku HTTP/1.1 Kod odpowiedzi - w tym przypadku 200 (czyli "wszystko w porządku"). Spis wszystkich kodów możemy znaleźć np. w Wikipedii. Opis odpowiedzi - w tym przypadku "OK" Drugi nagłówek to Content-Type. Musi być zawsze obecny w odpowiedzi i zawiera po prostu typ mime przesłanego dokumentu. Spróbujmy teraz wymusić na serwerze inną odpowiedź. Jak wiemy, wpisując do przeglądarki "google.pl" w jakiś magiczny sposób adres zmienia się na "www.google.pl" - zobaczmy dlaczego: Jak widzimy - serwer odpowiedział informacją o tym, że dokumentu należy szukać pod innym adresem, podając go przy okazji w nagłówku Location. A co będzie, jeśli w ogóle nie podamy nagłówka Host? Przecież w wielu przypadkach (np. domowy RPi) na serwerze jest tylko jeden serwis... spróbujmy. Tym razem zamiast z Google (który trochę nietypowo traktuje błędy) połączymy się z serwerem Forbota: Jak widać - serwer traktuje to jako błąd. Ale co z protokołem HTTP/1.0? Wtedy przecież, w początkach Internetu, wystarczył adres IP... Spróbujmy! Widzimy więc, że tym razem serwer nie uznał naszego zapytania za błędne. Natomiast to, że nic konkretnego nam nie napisał oprócz tego, że działa - wynika z faktu, że bez nagłówka Host nie jest w stanie stwierdzić do którego serwisu wysłane jest zapytanie! I to na dziś tyle - w następnej części spróbujemy zrobić prosty serwer. Spis treści serii artykułów: Protokół HTTP w zastosowaniach IoT - część 1: trochę teorii Protokół HTTP w zastosowaniach IoT - część 2: budujemy serwer Protokół HTTP w zastosowaniach IoT - część 3: tworzymy klienta
  16. 1 punkt
    Używanie bibliotek Arduino na STM32, jak i dowolnym innym mikrokontrolerze ma jak najbardziej sens. Wbrew nazwie użytej przez ST, ich HAL nie zapewniaja właściwie żadnej abstrakcji sprzętu, a teoretycznie powinien bo w końcu HAL to skrót od Hardware Abstraction Layer. Przykra prawda jest niestety taka, że używając STM32 HAL trzeba nadal dobrze znać sprzęt, nie możemy zmienić mikrokontrolera na inny bez modyfikacji wyższych warstw programu, a nawet biblioteki HAL dla różnych rodzin STM32 nie są ze sobą w pełni zgodne. Natomiast Arduino - niezależnie od oceny jakości kodu, zapewnia prawdziwą abstrakcję sprzętu, czyli prawdziwy HAL. Dzięki tym bibliotekom można ten sam program np. blink uruchomić zarówno na stm32, atmedze, czy esp8266. Jak napisałem wcześniej, nie jest to szczyt osiągnięć sztuki programistycznej, ale zawsze jakiś standard. Więc jak chodzi o sens to po pierwsze jest łatwiej, po drugie mamy niezależność od sprzętu. Warto też pamiętać, że kod biblioteki STM32 HAL jest również bardzo daleki od optymalnego, natomiast to co generuje CubeMX nie dość że jest paskudne, to jeszcze nie zawsze działa.
  17. 1 punkt
    Przetestowałem już wcześniej rozwiązanie bez rezystorów i takie tutaj zastosowałem. Może jest niepoprawne i powinien być rezystor 1-5R, ale nie miałem problemów z takim układem i w praktyce Vf oraz If diody wychodzą książkowo bez żadnego dobierania KTIR'ów. Niestety nie mam porównania z układem z rezystorami i nie zachęcam do powielania tego niepodręcznikowego rozwiązania, i jeśli ktoś próbuje minimalizować ilość elementów na PCB - nie gwarantuję, że zawsze zadziała
  18. 1 punkt
    1. W poprzedniej konstrukcji postanowiłem w pewnym momencie umożliwić robotowi zmianę kierunku obrotu kół w trakcie jazdy - bez żadnych dodatkowych modyfikacji. Mostek spalił się w pierwszym przejeździe. Jakiś czas później wróciłem do tematu z podwójnym mostkiem i dodatkowym opóźnieniem - nie spalił się do dnia dzisiejszego, a zmiana poprawiła pokonywanie zakrętów prostych. Wiadomo, że wchodzi tu wiele czynników, w tym prawdopodobnie nieoptymalne sterowanie tym silnikiem, możliwe oscylacje regulatora itd. Ale chodziło głównie o to, że miałem potrzebę móc zrobić z silnikiem dowolnie wszystko, bez późniejszego awaryjnego lutowania w stresie, na zawodach. W tym momencie, jeżeli silnik potrzebuje do zmiany prędkości, z 3m/s do 0m/s, zmiany PWMa z +70% na - 80%, by za chwilę zadać +50%, a całość wykonuje się z częstotliwością 8kHz, to ja nie muszę się tym martwić i nakładać ograniczenia. Liczę się z tym, że silnik ulegnie znacznie szybszemu zużyciu. Mostek TB6612 odpadał z miejsca, gdyż moim zdaniem jest mocno przestarzały. DRV8837 odpadł ze względu na ograniczone napięcia zasilania do 11V. Postawiłem na przesadzony mostek ze względu na brak czasu na testy potrzebne by dobrać bardziej optymalny. Tranzystory w obudowach 5x6mm widuje się w mostkach +300W. Chyba uznałem, że łatwiej takie lutować niż 3x3mm. 2. Puste miejsce bierze się stąd, że miałem problem z dostawą modułu z aliexpress. Około 6 miesięcy czekałem aż przyjdzie, no i oczywiście nie przyszedł - dostałem zwrot. Dlatego robot debiutował z modułem HC-05 na kabelkach i właściwy moduł wstawiłem dopiero później. Jest to moduł, który podpatrzyłem u konstruktora GreenYe (micromouseusa.com), w jego micromousie Green Giant 5.19V - HJ580. Do tej pory nie wiem w jaki sposób zastosował ten moduł, gdyż ja musiałem programować układ DA14580 i męczyć się z custom'ową aplikacją pod nietypowy protokół bt. Typowy Bluetooth Low Energy. Gdy zapytałem GreenYe mail'owo o ten moduł, odpisał że swojego modułu nie musiał programować i używał go jako port COM, przez zwykły terminal. Z zalet: baaardzo niewielkie rozmiary, znacznie szybszy od HC-05, pobiera niewiele prądu. Wady: Krótki zasięg < 10m z obecną anteną, wymagał programowania OTP, trudna dostępność, brak dokumentacji i footprintu modułu, wymaga znajomości BLE. Rozważałem jeszcze wykorzystanie modułu SPBTLE-1S od STMicroelectronics. Jest również niewielkich rozmiarów i teraz posiada dość spore wsparcie, ze sporą ilością przykładów do wykorzystania oraz gotowe biblioteki.
  19. 1 punkt
    Osobno wydzieliłem zasilanie części analogowej pod czujniki linii - ma wpływ na dokładność pomiarów adc. Podobnie z imu. Część cyfrową projektu mam bardzo rozbudowaną i na pewno pojawia się sporo zakłóceń. Izolacja zasilań częściowo eliminuje wpływ tych zakłóceń. Pod STM32 użyłem ldo spełniające kryterium zużycia prądu, układ 500mA. Pod analog oraz imu kryterium był poziom szumów i tłumienie zakłóceń. Czynnikiem była również przetwornica 5V, która pulsuje - ldo z wyższym pssr lepiej tłumi takie pulsacje (o ile przy 2MHz przetwornicy da się to zauważyć, każde może tłumic praktycznie tak samo)
  20. 1 punkt
    Dzięki za pozytywny odzew! Ad. 1. 4-warstwowa płytka ma swoje zalety. Możliwe, że dla płytki z czujnikami była troszkę przesadą, ale miałem wizję schować sygnały analogowe pomiędzy ekran (pomijając tasiemkę). Przede wszystkim znacznie wygodniej projektuje się taką płytkę, nie musiałem się martwić o nieoptymalnie poprowadzone zasilanie - w tym przypadku zasilania umieściłem na wewnętrznych warstwach i zadbałem, aby zbiegały się w odpowiednich miejscach. Obecnie zasilanie jest "czyściutkie" przy zastosowaniu po jednym 33uF na silnik. Przy 4 warstwach możliwe jest również pilnowanie impedancji dla sygnałów różnicowych USB, choć często przy takich długościach jak u mnie, można to olać. Na koniec wydaje mi się, że bez 4 warstw mógłbym nie zmieścić się w takich wymiarach pcb. Ad. 2. Miałem większy plan z tym żyroskopem, jednak zdziwiony, że robot idealnie śmiga po linii bez niego, używam go w trakcie jazdy tylko do omijania przeszkód. Zabrakło czasu na dalszy rozwój. Był zamiar eliminowania wpływu poślizgu na zakrętach, a nawet oparcie całego poruszania robota na danych z odometrii i zastąpienie pełnego regulatora PD linii, jedynie członem proporcjonalnym. Dorzucam wykres, jak wygląda trasa wg. robota przy bezpośredniej zamianie kąta z enkoderów na kąt z żyroskopu. Ad. 3. Większość prób z mapowaniem wykonałem na logach w Matlabie. Wyszacowałem dość spory zysk z mapowania dla tras z dużą ilością prostych odcinków. Przygotowałem prosty algorytm, który nadawałby się do przejazdu z jedynie 1 przejazdem mapującym i faktycznie zdawało to egzamin w warunkach domowych, na małej trasie. Znowu, zabrakło czasu doimplementować interfejs, który wymagałby kilku przeróbek w programie i zmian w aplikacji na smartfon i cały czas odsuwam wykorzystanie mapowania na zawodach. Po każdym przejeździe zostają mi "suche" informacje na temat trasy o długości, zakrętach i odcinkach prostych. Być może na kolejnych ostatnich zawodach... Ad. 1. Przekładnię w Pololu uważam za idealnie dobraną, kolejna z szeregu - 30:1 nie pozwoli na uzyskanie wymaganej prędkości przy li-po 2S. Bardziej poszedłbym w zmniejszenie średnicy kół z ~25 do 20mm. Dodatkowy moment obrotowy i tak pójdzie w poślizg. Nawet teraz przy ruszaniu z miejsca 0-2.5m/s słychać pisk opon (przy idealnie wyczyszczonych kołach). Kolejny poślizg widać już od pierwszego zakrętu. Przy takiej masie konstrukcji bez turbiny, momentu nie brakuje. Ad. 2. Nie tylko I2C ma problemy z zakłóceniami. Jak widać ze zdjęć, próbowałem skręcania przewodów, nic nie dawało również zmniejszanie prędkości z 400kHz do 100kHz. Przestałem grzebać przy i2c, gdy zorientowałem się, że sam czujnik po wysypce wymaga odłączenia zasilania, nie odpowiada na dalszą komunikację. Co drugi przejazd czujnik działa bez zarzutu i tak zostało. Ad. 3. Enkodery zamówiłem chyba w 2016 roku, gdy pojawił się pierwszy pomysł na nowego robota. Czekały w pudełku na tę konstrukcję . Również stwierdzam, że obecnie ciężko je zdobyć i wymagają zakupów np. z mousera, z magnesami pewnie jeszcze gorzej. Ad. 4. Przeszkodę omijam łukiem złożonym z dwóch sinusoid. Parametry łuku dobieram przed przejazdem i takie podejście również wymaga prób i błędów aby dograć parametry pod warunki na torze. Ad. 5. Do tej pory nie wykonałem na zawodach żadnego przejazdu odtwarzanego z mapy. Obecnie próbowałem najprostszego podejścia z nałożeniem maksymalnej prędkości jedynie na odcinki proste, tak aby nie wystąpił poślizg. Ad. 6. Czujnik z myszy musiałby mieć wysoką prędkość maksymalną (z 5m/s) i sprawdzić sie w warunkach drgań, nierówności, podskoków itd. Swego czasu poddałem się z takim czujnikiem, przy próbie kupna, nawet uszkodzonej myszki. Ad. 7. Chciałem zostać przy ułożeniu pary nadajnik-odbiornik w pionowej linii i mieć pewność, gdzie znajduje się środek czujnika. Dodatkowo ustawiłem sobie limit 12 czujników i dalsze zmniejszanie odstępów mogłoby sprawić, że robotowi zabraknie pola widzenia.
  21. 1 punkt
    Zaintrygowany pomysłem Oldskulla zanurzyłem rękę w szufladzie i ku mojemu zaskoczeniu wyciągnąłem prawie pełną szynę procesorów tiny13. A co będą się marnować, zostały z jakiegoś projektu więc może niech chociaż jeden trochę popracuje. Szybko dospawałem mu driver diody LED na tranzystorze pnp, podłączyłem TSOP34838 z jakimś filtrem na zasilaniu i kilka pinów do programowania ISP. Acha, dwa potencjometry analogowe podłączone do wolnych wejść przetwornika A/C umożliwiły mi regulację prądu diody IR (poprzez wypełnienie PWM) oraz regulację czułości samego odbiornika, ale o tym za chwilę. Prosty programik właściwie nie ma nic do roboty. Programuje piny protu B, kilka rejestrów timera 0, przetwornik A/C i tyle. Ponieważ tiny13 ma tylko jeden timer, wykorzystałem go do generacji fali nośnej o zadanej częstotliwości w trybie fast-PWM. Za okres fali odpowiada rejestr OCR0A a liczba tam wpisywana jest obliczana w czasie kompilacji wprost z częstotliwości. U mnie jest to 38kHz: #define IR_FREQUENCY 38000 #define TIMER0_PERIOD (F_CPU/IR_FREQUENCY) Potrzebowałem jeszcze jakiejś podstawy czasu do produkowania paczek i przerw a ponieważ jedyny timer już został zużyty (jedyny pożytek z niego to byłyby przerwania 38kHz, ale uznałem, że to przesada) to mogłem wykorzystać albo watchdoga albo ADC. Z watchdoga zrezygnowałem, bo to osobny generator i jego przerwania byłyby niesynchroniczne w stosunku do fali IR. Tak więc padło na ADC. Puściłem go w trybie autorun z podzielnikiem 1/128 co daje przerwania z częstotliwością ok. 2.9kHz (4.8MHz/128/13). Całość roboty odwala obsługa przerwania od przetwornika: odlicza czas paczek i przerw a także oblicza na bieżąco (na podstawie pomiarów ADC) wypełnienie PWM dla diody IR oraz czułość odbiornika. Zarówno długość grupy jak i odstęp między grupami są parametrami z którymi można samodzielnie eksperymentować kompilując program z innymi ustawieniami: #define GROUP_SPACE 30 #define GROUP_LENGTH 8 Każda paczka IR ma długość jednego przerwania od ADC (ok. 360us). Przerwy między paczkami są takie same. Czułość reguluję w ten sposób, że liczę ile paczek w danej grupie dostało z TSOPa aktywną odpowiedź. Np, jeżeli w grupie mam 8 paczek, to mogę regulować czułość w 8 poziomach: - na najwyższej czułości wystarczy, by tylko jedna paczka z grupy wygenerowała impuls na wyjściu TSOPa - na kolejnych podwyższam limit koniecznych odpowiedzi TSOPa - najniższa czułość jest wtedy gdy potencjometr podkręcimy aż do Vcc co ustawia limit równy długości grupy, czyli w tym przypadku 8 co oznacza, że każda paczka musi dostać odpowiedź z TSOPa. Zakres potencjometru jest automatycznie skalowany i zawsze jako minimum czułości (maksymalne napięcie z potencjometru) przyjmowana jest aktualnie skompilowana długość grupy. Najwyższa czułość zawsze wynosi jeden. Wyjście jest uaktualniane po każdym liczeniu odpowiedzi całej grupy, czyli w moim przypadku co ok. 25ms. Oczywiście w docelowej konstrukcji, zamiast każdego z potencjometrów można wmontować dzielnik z dwóch oporników lub nawet zewrzeć odpowiednie wejście do plusa lub do masy - jeśli chcemy mieć skrajne napięcie i odpowiednią do tego czułość i/lub wypełnienie. Na średnim poziomie czułości (ok. 4-5) i wypełnieniu diody IR rzędu 10% (można je regulować od wąskiej szpilki do 50% okresu fali IR) mój czujnik wykrywa mnie w białej koszulce z odległości ponad 3m. Prąd diody w impulsie nie przekracza 35mA, ale dzięki usypianiu procesora w IDLE i małemu wypełnieniu prąd zasilania jest < 10mA Niestety taka czułość wymaga już obudowania diody IR metalową rurką z dokładnie zatkanym tyłem (od strony wyprowadzeń diody) bo tamtędy też świeci oraz zbudowania małego domku wokół TSOPa. EDIT: Mała poprawka: dioda dostała dłuższą rurkę (ok. 80mm, fi 10mm) a TSOP domek otaczający go z każdej strony + rurka z czarnego kartonu i zasięg wykrywania białego Tshirta wzrósł do ponad 4m przy PWM podkręconym do ok 25%. Tym samym skończył mi się pokój. Zasięg ograniczony jest głównie bezpośrednim wpływem diody nadawczej na TSOPa. Przy podkręcaniu czułości odbiornika albo zwiększaniu wypełnienia PWMa promieniowanie diody przełązi wprost do TSOPa i wyzwala go. Nie jestem w stanie zrobić metodami domowo-garażowymi lepszej separacji i na tej odległości kończę zabawę. Prąd diody w impulsie to wciąż 35mA Na koniec schemat: oraz program (źródło i hex): tiny13sens1.zip
  22. -1 punktów
    Jest kilka sposobów manipulacją GPIO i jak dobrze kojarze ten stosowany przez bibliotekę pigpio nie działa z sudo adduser pi gpio
Tablica liderów jest ustawiona na Warszawa/GMT+01:00
×
×
  • Utwórz nowe...