[mapache]

mam już obsługę czujnik odległości, częściowo bo jeszcze mam w planach parę rzeczy. przeszedłem dosyć długą drogę prób i błędów by to działało tak jak chcę. Słowem wstępu jeszcze są to czujniki ultrasoniczne, mają dwa piny które tutaj mnie interesują, trigger i echo. trigger nadaje sygnał dźwiękowy, a echo daje mi sygnał zwrotny w postaci stanu wysokiego, czas stanu wysokiego oznacza czas jaki potrzebował dźwięk od wyjścia do wrócenia do czujnika. Więc opiszę cała drogę po kolei

1. Miałem czujniki podpięte w ten sposób że miałem wspólny trigger dla wszystkich czujników i osobno każde echo. Taka konfiguracja potrafiła powodować zakłócenia przy pewnych sytuacjach, że wypuszczony sygnał z jednego czujnika wpływał na drugi

2. Jak słusznie zauważył @rmerrorlog stan wysoki czujniki nadają 5V a malina działa na 3.3V wejściowy, więc dałem konwertery logiczne. Załącznik 1

3. Podzieliłem triggery w ten sposób że triggerowałem dwa czujniki przeciwnie do siebie oddalone, już było lepiej ale jeszcze to nie to. Nie miałem wszystkich triggerów osobno bo nie starczało mi pinów.

4. Triggery osobno, za to echo zbierałem bramką logiczną OR zrobioną z diod. Załącznik 2. Prawie to działało. Prawie, gdyby nie to że inne czujniki mimo że nie były triggerowane to wysyłały mi syf. Ponoć innym osobom takie rozwiązanie działało, u mnie się to nie sprawdziło. Na filmiku jest trochę źle układ, wtedy nie doczytałem schematu i dałem wszędzie rezystory, potem je wyciąłem by działało poprawie.

4. Dałem multiplekser i wszystko działa cacy. Na multiplekserze są wszystkie echo i wybieram je wejściami adresowymi. Załącznik 4.

Samo zbieranie danych z czujników wygląda tak że robię 5 pomiarów na każdy czujnik, i robię domimantę z nich. Czemu tak? dlatego że te czujniki potrafią czasami rzucić jakieś wartości z kosmosu. Dominanta w odróżnieniu od średniej pozwoli mi odrzucić takie rzeczy. Jeżeli były 3 pomiary pod rząd +-1cm to przerywa pomiary. Muszę też pomyśleć nad optymalizacją by samo zbieranie trwa dosyć długo, więc mam pomysł by dawać priorytety na czujniki które potrzebuje częściej sprawdzać. Czyli jak np jadąc do przodu potrzebujesz częściej informacji co się dzieje z przodu niż to co za mną. Muszę też pomyśleć jak sprawnie rozwiązać rozpoznawanie czy coś jest za daleko lub za blisko. W obu przypadkach jest 0 bo jest timeout. Ktoś by powiedział że można zrobić tak że np sprawdza się ostatnie pomiary jakie były, otóż nie do końca. Bo jeżeli się nagle zakryje czujnik który wcześniej coś tam daleko zbierał i nagle będzie zasłonięty to nie wiadomo czy już coś bardzo daleko jest czy został zasłonięty. Przemyślę to.

Wstawiłem też mocniejsze serwo. Załącznik 5.

Plan na teraz jest taki by dopracować te czujniki i zabrać się za kolejne. Mam jeszcze do ogarnięcie żyroskop z akcelerometrem oraz magnetometr.

Tag projektu: #malinoweauto

#elektronika #majsterkowanie #arduino #diy #chwalesie #raspberrypi #tworczoscwlasna #programowanie

[loginek0]

Nie wiem czy było pytanie ale skąd masz podwozie, kółka i silniczki? Jakie to dokładnie modele?

[mcjq5]

@mapache: Planujessz wykorzystać albo interesowałeś się ROSem? Zapewni ci dużo przydatnych narzędzi do debugowania czy wizualizacji, jest mnótswo gotowych paczek które rozwiążą problemy które bankowo napotkasz i pozwoli spiąć wszystkie funkcjonalności w całość

[mapache]

@AhmedBee: to przejrzyj inne wpisy z projektu. tak skreca. nawet ma kierukowskazy ( ͡° ͜ʖ ͡°)

[mapache]

@loginek0: lego 8041 + własny częsci drukowane które projektowałem pod czujniki, silnik i serwo. silnik to silnik krokowy z drukarki w standardzie NEMA17, do tego serwo SG92

[mapache]

@mcjq5: hm nie planowałem. z tego ci widzę to jedyną rzeczą jaka by mi się przydała to wirtualne środowisko testowe, wtedy bym mógł się pobawić w AI i te sprawy. ale wolę sam wszystko zaprojektować od zera i używać gotowych rzeczy jak najmniej

[mcjq5]

@mapache: ROS nie zrobi wszystkiego za ciebie xD z samym ogarnięciem co i jak i konfiguracją będziesz miał trochę roboty, potem sam piszesz własne nody w cpp/pythonie wg. pewnych standardów i spinasz to w całość. Symulator jest zajebiście ogarnięty, przenoszenie potem aplikacji z niego na robota w większości przypadków działa 1:1

[mapache]

@mcjq5: oglądam sobie ten ROS i nawet zaczyna mi się podobać. przemyślę czy zastosować u siebie

[jeden231]

@mapache: Udostępnisz schemat podłączenia czujników? Ciekawi mnie pod kątem zakłóceń, o których wspominasz. Jakich konwerterów poziomów używasz?

Przy rozpoznawaniu za blisko/za daleko stawiałbym na dwa czujniki umieszczone z określonym przesunięciem względem siebie, np. 2cm. Dla jednego jest już za blisko, drugi jeszcze rozpoznaje. Od razu masz cross-check, czy czujniki są sprawne i pomiary wiarygodne. Problemem jest miejsce.

Pomysł z częstszym samplowaniem czujników skierowanych na aktualny kierunek jazdy ma sens jeżeli

[mapache]

@jeden231:

"zbieranie danych trwa dosyć długo"

z tym mi chodzi że te czujniki są dosyć wolne bo dźwięk jest wolny. im dalej przeszkoda tym dłużej to wszystko

[jeden231]

@mapache:

z tym mi chodzi że te czujniki są dosyć wolne bo dźwięk jest wolny. im dalej przeszkoda tym dłużej to wszystko trwa

Zmiana częstotliwości wyzwalania czujnika nie zmienia czasu trwania pomiaru czujnika, bo jak sam napisałeś, jest to cecha czujnika.

Nie ma w dokumentacji czujnika opóźnień między wyzwoleniem pomiaru, a wypuszczeniem fali przez czujnik i czasu od wypuszczenia fali do wystawienia stanu wysokiego. Można oszacować, że cały cykl trwa 10us puls wyzwalający + 200us generowanie fali + maks 38ms sygnału zwrotnego = 40ms żeby było łatwo liczyć. Załóżmy niedorzeczne opóźnienia, które nie są podane, rzędu długości całego cyklu, czyli masz co 80ms informację o odległości. Zaokrąglając 10x na sekundę. Na oko przy tej prędkości co na filmie masz pomiar co 4cm

[mapache]

@jeden231: pomnóż to razy 8 czujników razy 5 pomiarów na każdy + jeszcze przerwa w wątku by nie zżerał 100%

[Filip69]

@mapache: Co kontuzja i brak siłowni robi z człowiekiem ... ( ͡° ͜ʖ ͡°) Zaczyna cuda tworzyć

[mapache]

@Filip69: poki co to prawie dzien w dzien cos robie. praca zdalna + brak silowni to masa czasu wolengo. wczesniej tez projekt ciagnalem ale szlo jak krew z nosa

[RacjaStanu]

@mapache: Szanuję za kontroler XO ( ͡° ͜ʖ ͡°)

[Krocpok]

W cenie 300-400 cebulionów masz SBricka do którego możesz użyć kontrolera i do takiego Technikowego modelu możesz dobudować cały napęd nie zabierając przy tym tyle miejsca, ale ważne, że cieszy i jeździ.

[mapache]

@Krocpok: a za 0 cbl miałem siknik od drukarki i pada od xboxa

[asperger15k]

@mapache: Fajne, bardzo fajne, też myślałem aby się pobawić w coś takiego, tylko od lat jestem tak zawalony zarabianiem kasy, że nie mam cały czas czasu na żaden większy projekt. Natomiast ja myślałem, aby podejść na 1 z 2 innych sposobów:

1. Jakiś stary samochód (ale na tyle nowy, że z magistralą CAN) jako platforma deweloperska. To podstawa: samochód realnej wielkości zamiast zabawki. I sterowanie przez GSM, wyposażone w ekran LCD pokazujący widok z kamer(y) - tutaj mój oryginalny pomysł to wzięcie całego układu kamera/sterowanie z ArDrone lub czegoś podobnego.

2. Gdyby przez główny CAN nie dało się sterować jednostkami wykonawczymi, a jedynie czytać dane (nowsze samochody tak niestety mają), to każdy element wykonawczy wyposażyć w osobne Arduino z logiką sterowania tym elementem, wystawiające minimalne API do modułu centralnego, a całością sterować albo z poziomu Raspberry Pi, albo, jeśli Pi będzie za słabe, to z poziomu jakiegoś małego Della Optiplexa USFF zasilanego z gniazda zapalniczki za pośrednictwem jakiegoś

[mapache]

samochód realnej wielkości zamiast zabawki.

@asperger15k: to akurat spory problem. trzeba mieć własny plac i jedna osoba do czegoś takiego to za mało. myślę że łatwiej jest zrobić auto w skali jak teraz robię i potem przenosić tą samą technologie do normalnego auta. ale czy w ogóle problem taki istnieje by robić na niego rozwiązania komercyjne?

[mapache]

@asperger15k: z ciekawości zrobiłem sobie test z twojej strony 32/50 ( ͡° ͜ʖ ͡°)