Skocz do zawartości

telemetria w bolidzie


macowca
 Udostępnij

Rekomendowane odpowiedzi

Cześć ! Wróciłem po długim czasie z ciekawym pytaniem ;) 
Otóż zaangażowałem się w studencki projekt bolidu i myślę nad telemetrią. 
Potrzeba kilku czujników temperatury, przyśpieszenie, prędkość ( biegi i obroty ), wychylenia pedałów itp. 

Myślałem żeby użyć do tego w jakiś sposób telemetrii FrSky.  Mam apkę Turnigy 9XR, więc można ją wykorzystać do przesyłu danych i ew. zapisu. 
I tutaj chciałbym was poprosić o pomoc. Moje pytania to:

- czy da się wykorzystać modelarską telemetrię do takiego przeznaczenia ? Wiem, że ułatwiłoby to sprawę, bo dane z czujników są już "ladnie poukładane", więc nie trzeba pisać do nich specjalnego programu

- czy pobrane dane da się podłączyć do jakiegoś Raspberry pi albo arduino, żeby można było je potem przejrzeć na kompie

 

- jeśli nie, to czy mogę mieć podgląd na bieżąco za pomocą apki oraz dodatkowy zapis, żeby potem obejrzeć wszystko na komputerze w postaci wykresów etc.

 

- ogólnie poprosiłbym o jakieś rzeczy do przeczytania, na czym mogę się wzorować. Szukałem ogólnie info o telemetrii w takich bolidach, ale z miernym skutkiem

 

Z góry dzięki :)

Odnośnik do komentarza
Udostępnij na innych stronach

Postaw mi kawę na buycoffee.to

Oczywiście że da się to zrobić. Najlepiej wykorzystać jak najwięcej już istniejącego sprzętu i oprogramowania, czyli zapoznać się z tym jak z logowaniem danych radzą sobie kontrolery lotu - Pixhawk i iNav. Jedno i drugie rozwiązanie ma świetne narzędzia do przeglądania danych zapisywanych na karcie SD. 

 

Część pomiarów można wykorzystać wprost (przyspieszenia), część trzeba przerobić - np wychylenia pedałów, ale coś musi być do zrobienia :) Telemetrię po mavlinku albo innych protokołach jak najbardziej da się wykorzystać. Najlepiej wziąć gotową implementację i podmienić niepotrzebne dane (wysokość lotu, napięcia baterii itd) na te użyte w projekcie.

 

Nie wiem co to bolid ale raczej to łatwiejsze niż dron. No chyba żeby, skoro już jest kontroler, dodać mu jazdę autonomiczną - ArduRover.

Odnośnik do komentarza
Udostępnij na innych stronach

 

 

Telemetria frsky nic do tego nie ma, nie przyda się.

 

Dlaczego ma się nie przydać? Moim zdaniem najlepiej zacząć od kontrolera lotu z działającą telemetrią, i po kolei podłączać nowe czujniki i dostosowywać całość do tej dziedziny. Ogromną zaletą tej sytuacji jest szczegółowy log na karcie SD, do odtworzenia po jazdach, i bieżąca informacja przekazywana przez radio. Tak jest o wiele łatwiej niż wymyślać system od nowa. Mnóstwo problemów jest już rozwiązanych, a cenowo wyjdzie lepiej niż jakieś własne wynalazki. Nie będzie to duży koszt, nie tylko w odniesieniu do ceny bolidu ale też bezwzględnie.

Odnośnik do komentarza
Udostępnij na innych stronach

A ile czujników mógłbym maksymalnie podpiąć ? Powiedzmy że  dokładniej potrzebuje 4 do 8 od temperatury, prędkościomierz, akcelerometr, 2 od wychyleń pedałów, czyli wstępnie jakieś 8-12 czujników. Nigdy nie miałem do czynienia z modelarska telemetrią, bo nie była mi potrzebna, więc nie wiem jak to wygląda.

 

Jeśli macie jakieś artykuły ( mogą być po ang.) które pomogą mi w jakikolwiek sposób, to bardzo bym o nie prosił.
Jeśli mogę za to w lepszy sposób wykorzystać Arduino/ Malinkę to też proszę o artykuły. Myślę, że programiści sobie jakoś by poradzili, jeśli byłaby taka potrzeba ;)
Ew. część może iść przez FrSky, a część inną drogą, mogę rozważyć wszystkie opcje.
Jeśli znacie też jakieś forum, które jest bardziej w takich tematach, to proszę o link

Odnośnik do komentarza
Udostępnij na innych stronach

Na początek zapoznaj się z dwoma pojęciami: logowanie danych (zapis na karcie SD) i telemetria (przesył danych przez radio, z mniejszą rozdzielczością i potencjalnymi przerwami).

 

Zobacz, jak jest to rozwiązane w dwóch systemach: iNav oraz Pixhawk, ewentualnie kup sobie jeden z tych kontrolerów, i wypróbuj, logowanie na karcie (na początek) oraz współpracę z telemetrią FrSky.

 

opis:

http://ardupilot.org/copter/docs/common-downloading-and-analyzing-data-logs-in-mission-planner.html

 

Kilka przykładów ("telemetry iNav", "data logging pixhawk" itd w google):

 

https://user-images.githubusercontent.com/11059099/31385570-1e5c5f82-ae07-11e7-8a0a-548e98bd06f4.png

http://ardupilot.org/copter/_images/DiagnosingWithLogs_VibesTlog.png

 

10 kanałów bez problemu da się zapisać na karcie i przesłać telemetrią.

Odnośnik do komentarza
Udostępnij na innych stronach

Tak naprawdę to nie potrzebujesz telemetrii a tylko czarną skrzynkę. Telemetria jest tylko dodatkowo jako podgląd aktualnych danych.

Ja to widzę tak; czujniki - arduino - zapis na kartę sd lub pamięć - nadajnik lora - odbiornik lora - komputer lub tablet.

Każdy średnio zaawansowany programista arduino zaprogramuje ci to w kilka wieczorów. Plus program do wizualizacji danych na komputerze w czasie rzeczywistym.

 

 Jak wpadniesz na dobry pomysł z podłączeniem różnych czujników to będziesz miał z tego jeszcze dobrą kasę na piwo:)

Taki drobny przykład:

http://home.agh.edu.pl/~bartus/index.php?action=efekty&subaction=arduino&item=5

Odnośnik do komentarza
Udostępnij na innych stronach

 

Każdy średnio zaawansowany programista arduino zaprogramuje ci to w kilka wieczorów. 

 

My ze szwagrem po półlitrze to w godzinkę to zrobilim :)

 

 

 

Plus program do wizualizacji danych na komputerze w czasie rzeczywistym.

 

A spoko, w 5 minut się zrobi!

 

Najpierw trzeba zdecydować, czy te dane mają być zbierane porządnie, czy byle jak. Jeśli porządnie, to trzeba wybrać częstotliwości próbkowania, 10 Hz zapewne wystarczy (dla akcelerometrów, bo np termometr albo czujnik pozycji gazu mają większą bezwładność),  i zapisywać także wartości przetworzone filtrem Kalmana, by eliminować odczyty błędne, bo i takie się zdarzają. Na przykład Pixhawk zapisuje dane z akcelerometrów zarówno jako "raw data", jak i przetworzone.

 

Napisanie tego na arduino jest dość trudne, bo nie jest to system czasu rzeczywistego. Operacje takie jak odczyt danych z czujników, filtrowanie, zapis na kartę SD, wysyłanie telemetrii muszą być robione efektywnie, bo nie mogą powstawać opóźnienia. Stąd różne bufory i odpowiednio dobrany sprzęt (np port karty SD powinien być podłączony przez port SPI, a nie I2C). 

Odnośnik do komentarza
Udostępnij na innych stronach

 Udostępnij

×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę.