Jak połączyć kilka programów sterujących robotem w jeden wspólny z wyborem trybu?

[MarJanPol]

Witam, mam kilka programików do sterowania robotem-samochodem - jeden program prowadzi samochód po linii, inny wykrywa przeszkody, jeszcze inny pozwala sterować komórką. Teraz chciałbym te 3 programy ubrać w jeden wspólny program z wyborem jednego z trzech trybów za pomocą pilota IR. Czyli np.: wciskam na pilocie 1 - uruchamia się program 1, 2-2, 3-3. Gdy wcisnę np. # to samochód powraca do trybu czuwania. Czy mogę prosić o poradę jak powinien wyglądać szkielet takiego łączącego programu? Dodam ,że nie chodzi mi o obsługę IR tylko ogólnie o konstrukcję takiego programu z kilkoma trybami działania. Wyobrażałem sobie, że każdy z trzech trybów będzie obsługiwany przez inną funkcję , ale nie wiem jak zrobić, żeby podczas wykonywania jednego z 3 programów Arduino cały czas zachowało gotowość do otrzymania sygnału z pilota i zmiany trybu. Bo np jak samochód będzie w trybie unikania przeszkód to będzie "zajęty" przetwarzaniem danych z odległościomierza i reagowaniem na te dane i wydaje mi się, że nie będzie reagować na sygnały z pilota i próby zmiany trybu.

Mar

[marek1707]

To nie jest proste i nie da się opisać w jednym poście. Generalnie to wyższa szkoła jazdy. W miarę łatwo zmusić procesor do niezależnego mrugania kilkoma diodami, ale równoległa obsługa wielu procesów dziejących się na wielu interfejsach zewnętrznych wymaga gruntownego przemyślenia i zaprojektowania każdej z tych rzeczy właśnie pod taki system pracy. Nie da się w małym procesorku połączyć kilku programów pisanych jako samodzielne kody w jeden wspólny, robiący wszystko jednocześnie. Na dużej maszynie z wielozdaniowym systemem operacyjnym można by się zastanawiać, ale tutaj.. przykro mi. Musisz usiąść, zastanowić się co chciałbyś żeby ta całość robiła i tak napisać duży program, by to robił. Nie ma zmiłuj.

[MarJanPol]

A nie można jakoś użyć funkcji przerwania wyzwalanego na sygnał z pilota?

[marek1707]

Oczywiście trzeba masowo używać przerwań, podziału czasu i wszystkich tych fajnych mechanizmów, które mają małe procesorki własnie po to by robiły setki rzeczy "na raz". Przecież nie da się tego opisać w jednej odpowiedzi i dlatego -> "Musisz usiąść, zastanowić się co chciałbyś żeby ta całość robiła i tak napisać duży program, by to robił".

[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

[MarJanPol]

Oczywiście trzeba masowo używać przerwań, podziału czasu i wszystkich tych fajnych mechanizmów, które mają małe procesorki własnie po to by robiły setki rzeczy "na raz". Przecież nie da się tego opisać w jednej odpowiedzi i dlatego -> "Musisz usiąść, zastanowić się co chciałbyś żeby ta całość robiła i tak napisać duży program, by to robił".

Wiesz co, ale zamiast silić się na niepotrzebny sarkazm i truizmy mógłbyś w kilku zdaniach napisać co proponujesz. Chyba po to jest to forum, żeby sobie pomagać a nie leczyć kompleksy, no nie?

[marek1707]

Nie mogę niczego proponować, bo nie opisałeś dokładnie, punkt po punkcie jakie procesy chcesz tam mieć. Wiemy na pewno, że masz:

- odczyt czujników linii (liu? jakich?),
- odbiór sygnałów z IR (jaki standard?)

- sterowanie silnikami (jakimi? w jaki sposób?)

- wykrywanie przeszkód (pomiar odległości? sonar? lidar? czujnik zderzeniowy?)

- sterowanie komórką (to znaczy co ona ma niby robić?).

Na dodatek nie napisałeś tego wszystkiego sam tylko zapewne korzystałeś z gotowych bibliotek i/lub całych gotowych programów. Coś takiego jest praktycznie nie do ruszenia bo musiałbyś rozkminić dokładnie jakich zasobów (np. mocy procesora, timerów, przerwań itp) używają te biblioteki by to jakoś pożenić a wcześniej pewnie sporo pozmieniać. To naprawdę wymaga planowania wielu rzeczy z góry, to z kolei wymaga ogarniania dużych projektów a to z kolei doświadczenia. Osobiście wolałbym napisać to wszystko od nowa (bo są to proste rzeczy) niż tracić czas na na analizę zwykle bardzo kiepsko napisanych kodów. Nie mam w tej materii kompleksów, takie projekciki robię sobie po godzinach z nudów, ale nie umiem w prostych żołnierskich słowach wytłumaczyć przedszkolakowi jak działa silnik turbofan bo maluch nawet nie wie, że istnieje termodynamika.

Hm, dobra, spróbujmy, ja bym zrobił to tak:

- odczyt czujników jako automat pracujący z systemticka,
- odbiór sygnałów IR na przerwaniu ICP1 z buforowaniem ramek lub od razu interpretacją dłuższych naciśnięć,
- sterowanie silnikami na sprzętowym PWM i kilku automatach: taktycznym sterującym bieżącym kierunkiem i strategicznym, wymyślającym trasę na podstawie czujników linii i przeszkód,
- wykrywanie przeszkód (jeżeli to sonar) wyzwalane okresowo systemtickiem a czas mierzony którymś wolnym timerem,
- sterowanie komórką jako proces gromadzenia i parsowania stringów przychodzących przez UART pracujący na przerwaniach, to samo nadawanie odpowiedzi.

Nad tym wszystkim prosty automat uruchamiający i zatrzymujący poszczególne procesy na żądanie z pilota, wołany z systemticka.

A teraz podziękujesz mi za wskazówki i weźmiesz się do roboty/czytania/pisania itd czy jak dziecko odburkniesz, że się mądrzę? Może zanim zdecydujesz się wylać lawę, zapytaj jakiegoś programistę systemów embedded czy to w ogóle ma sens albo jak on by to zrobił na mega328. Zawsze to jakaś niezależna opinia, przecież nikt nie ma monopolu na wiedzę..

[MarJanPol]

...A teraz podziękujesz mi za wskazówki i weźmiesz się do roboty/czytania/pisania itd czy jak dziecko odburkniesz, że się mądrzę? Może zanim zdecydujesz się wylać lawę, zapytaj jakiegoś programistę systemów embedded czy to w ogóle ma sens albo jak on by to zrobił na mega328. Zawsze to jakaś niezależna opinia, przecież nikt nie ma monopolu na wiedzę..

Odpowiadam - szczerze podziękuję Ci za wskazówki i poświęcony czas. Zaskoczony? ...choć uważam, że się mądrzysz. Bo przecież widzisz, że nie pyta Cię o radę kolega informatyk tylko majsterkowicz hobbysta na forum dla początkujących opornikolubów. Mógłbyś więc pochylić nieco nos do dołu i zaprzestać używania slangu mehatroników. Mam nadzieję, że Cię nie uraziłem, ale powiem Ci, że wkurza mnie to swoiste zadęcie, z którym miewam niestety czasem do czynienia na tym sympatycznym forum ze strony niektórych osób, które zamiast po ludzku pomóc prosto i na temat próbują brylować i czasem opryskliwie pouczać tych co "przecież nie znają podstaw" - jak gdyby powinni. O ile było by sympatyczniej gdyby Ci Ważni uświadomili sobie, że dla wielu osób takich jak ja Arduino to jest po prostu miłe hobby i nic więcej i że nie trzeba wcale robić fakultetu z C++ żeby mieć frajdę ze sterowania serwomechanizmem i, że tym hobbystom amatorom też fajnie jest pomóc jak się wie więcej od nich. Tym wszystkim Ważnym chciałbym życzyć, aby wzięli przykład ze swoich kolegów po fachu na analogicznych anglojęzycznych forach. OK, kończę marudzenie.

A w temacie - jeśli zatem zgodzisz się przetłumaczyć na ludzki język to co mi doradziłeś w swoim poprzednim poście to będę Ci jeszcze bardziej wdzięczny 🙂

[Elvis]

Skoro programista embedded jest poszukiwany, to pozwolę sobie dołączyć do dyskusji.

Pozwólcie Panowie że pominę waszą burzę i wrócę do oryginalnego pytania - czyli jak wywoływać jedną z trzech funkcji sterujących w zależności od wybranego trybu działania.

Jest to bardzo proste - potrzebna jest jedna zmianne przechowująca aktualny tryb pracy:

int tryb = 0; 

Możemy przyjąć, że zero to tryb jazdy po linii, 1 wykrywanie przeszkód, 2 sterowanie komórką. Oczywiście zamiast magicznych liczb ładniej będzie zdefiniować stałe, ale nawet takie "brzydkie" rozwiązanie zadziała.

Pętla główna może wtedy wyglądać mniej więcej tak:

void loop()
{
 switch (tryb) {
   case 0: 
     jazdaPoLinii();
     break;
   case 1: 
     wykrywaniePrzeszkod();
     break;
   case 2: 
     zdalne sterowanie();
     break;
 }
}

Pisząc taki program nie możesz blokować procesora, więc każda z funkcji powinna możliwie szybko wykonywać swoje działanie i wracać do pętli głównej. Podobny sposób pisania programów znajdziesz tutaj: https://forbot.pl/blog/kurs-arduino-ii-wielozadaniowosc-opoznienia-z-millis-id18418

Jeśli tryb zostanie zmieniony, to program "zauważy" to dopiero po powrocie z aktualnej funkcji - stąd konieczność szybkiego powrotu.

Natomiast problem kompatybilności bibliotek to zupełnie inny temat - więc nie ma pewności że połączenie trzech działających programów w jeden nadal będzie działać.

[marek1707]

MarJanPol: Nie jestem zaskoczony, bo nie podejrzewam Cię o bycie bucem. Za pomoc zwykłe Dziękuję należy się jak psu buda. A teraz o od lat tu wałkowanej sprawie formy pomocy. Nie jesteś zadowolony z mojej bo jej nie rozumiesz, trudno. Napisałem Ci przecież na początku, że to nie są proste sprawy a teraz, gdy dotarło to wreszcie do Ciebie - jesteś zdziwiony i oburzony. I tego nie rozumiem. Nie rozumiem takich oczekiwań (nie tylko Twoich, coraz więcej tu takich osób). Naprawdę liczysz, że ktoś specjalnie dla Ciebie zrobi wykład o pisaniu zaawansowanych programów? Możemy tu wrzucać krótkie akapity o pewnych szczególnych problemach, o ustawieniu konkretnego timera, a trybie pracy ADC czy motywach działania kilku połączonych tranzystorów, ale od czasu do czasu pada pytanie "jak zbudować rakietę kosmiczną"?

Pewnie nie masz 12 lat więc choćby z racji wieku znasz się już na czymś dobrze, prawda? Niech to będą np. instalacje elektryczne w budynkach. I teraz przychodzi do Ciebie człowiek, który jest ratownikiem TOPR. Fantastyczne zajęcie, pełne poświęceń, człowiek legenda o ogromnej wiedzy i doświadczeniu, szacun i w ogóle i mówi tak: "Zrobiłem kiedyś kilka latarek LED więc wiem jak wyglądają kable. Chciałbym zrobić instalację elektryczną w nowym, 100-pokojowym hotelu mojego brata w Zakopanem. Czy mógłbyś mi to wytłumaczyć?". A Tobie opada szczęka, bo nie wiesz czy śmiać się czy płakać. Musiałbyś zacząć od tłumaczenia energetyki od postaw, o stacjach SN/NN, o zabezpieczeniach, o przekrojach, o całej masie obowiązujących przepisów, norm i dobrych zwyczajów, o zasadach wykonawstwa, doboru firm, itd itp. Acha, i miałbyś robić to korespondencyjnie... A przecież to wszystko gdzieś jest opisane i skodyfikowane i nie da się tego łyknąć za jednym razem. To przychodzi z latami pracy i zdobywanego doświadczenia. Czy zacząłbyś pisać dla niego książkę "Jak zostać elektrykiem w 256 prostych krokach bez wychodzenia z domu?". Raczej nie, prawda? A gdybyś jeszcze spotkał się zarzutem zadzierania nosa i niechęci do pomocy? Co byś o gościu pomyślał? Odpowiedz szczerze.

Czy już dostrzegasz tę przepaść? Moja rada jest taka: pisz dużo małych rzeczy, wnikaj w procesory i powoli przestaniesz być "początkującym opornikolubem". Swoją drogą obraża to wielu ludzi tutaj, którzy (także na moich oczach) rozwinęli się w ciągu paru lat fantastycznie. Nie przetłumaczę Ci porad na ludzki język, bo one już jest w nim napisane. Każda branża ma jakiś system porozumiewania się i tu jest taki. Doceń, jak łagodnie się z Tobą obchodzę pisząc proste rzeczy, bo nawet nie zacząłem pisać o skomplikowanych. Nie wiń innych za to, że czegoś nie rozumiesz, bo tak naprawdę świat ma gdzieś to, ze czegoś nie wiesz. Angielskojęzyczne fora także. Pomyśl, że to raczej Twoje postrzeganie świata jest takie, że gdzieś znajdujesz artykuły/wypowiedzi zrozumiałe a gdzieś może mniej albo gorzej szukasz. I to wcale nie znaczy, że tam jest lepiej a tu masz samo zadęcie. To tylko Twój wybór i ogląd rzeczy, które do Ciebie dotarły. Nie czytając tych skomplikowanych, których nie pojmujesz masz wrażenie, że nie istnieją. Zrób eksperyment i zadaj podobne pytanie, o sposób połączenia wielu bliżej niesprecyzowanych programów w jedną całość, na najlepszym i najbardziej pomocnym Twoim zdaniem innym forum i sam się przekonaj czy dostaniesz instrukcję krok po kroku "Jak stać się dobrym i doświadczonym programistą embedded w dwa dni". Sam chętnie to przeczytam.

A poza tym wszystkim: wg Ciebie jestem bufonem i zadzieram tu nosa, nie ostrzegam i nie umiem tłumaczyć a wolę napisać coś niezrozumiałego, bo to fajnie brzmi. Poczekajmy, może znajdzie się ktoś kto da Ci satysfakcjonujący przepis na to połączenie kodów. W końcu niech eksperyment rozstrzygnie. Nie muszę akurat Twojego wątku zaśmiecać wątpliwymi poradami, z pewnością jest wielu chętnych, przekonaj się.

Elvis: Nie łudź człowieka jednym switchem. Przecież wiesz, że to nie rozwiązuje sprawy, pochyl się i pomóż mu naprawdę. Wywołałem programistę by ocenił czy to co napisałem ma sens. Odnieś się do tego proszę albo napisz, czy jest to dla Ciebie przynajmniej zrozumiałe. Co sądzisz o podejmowaniu na naszym Forum takich wyzwań jak to wywołane przez Autora. I czy - obiektywnie - Twoja rada (zrób wielozadaniowość na millis) jest z gatunku tych pomocnych i prostych, jakich domaga się MarJanPol. Absolutnie nie twierdzę, że ona jest zła, tylko czy coś mu pomoże na szybko?

[Elvis]

marek1707, przeczytaj na spokojnie pierwszy post w tym wątku. Autor nie pytał o jednoczesne wykonywanie trzech funkcji, ale o możliwość przełączania i wyboru jednej. Jeśli sterujemy przez telefon to samochodzik nie wykrywa przeszkód itd.

Dlatego dałem podpowiedź jak prostym switchem wybierać aktualnie używaną funkcję. Jeśli biblioteki się pogryzą to oczywiście program nie zadziała, ale wtedy będzie kolejny wątek albo chociaż kolejny post.

Mogę się mylić, ale ja tak zrozumiałem pytanie autora wątku. A jakie będzie następne - zobaczymy, może faktycznie będzie chciał zbudować skomplikowny program, a może zwykły switch wystarczy.

[marek1707]

Nie chodzi mi trzy główne funkcje leżące na wierzchu tylko o te procesy, które będą odbywać się pod spodem, np. odbiór IR, "sterowanie komórką" itp. MarJanPol jest przekonany, że Arduino jest zawsze proste i próbuję go wyprowadzić z błędu. Trzy proste rzeczy (np. prowadzenie samochodu, jedzenie i gadanie przez komórkę) robione jedna po drugiej są łatwe, ale z jakiegoś powodu za trzy te same czynności robione jednocześnie można trafić do więzienia. Nie radzimy sobie z tym. Jeśli chce wejść w trudne (dla obecnego niego) tematy, to będą one trudne i nie ma tu prostych rozwiązań. Niezależnie od tego co MarJanpol o tym myśli. Moje ostrzeżenia wziął za niechęć do pomocy - to nie jest fajne.

[Elvis]

Wydaje mi się Marku że trochę za bardzo komplikujesz problem i rozwiązanie. Autor na razie do wielowątkowości nie doszedł, a sztuczka opisywana w artykule o millis może wystarczyć - zamiast procesów będzie odpowiednio częsty polling. W końcu to nie program sterujący rakietą kosmiczną, tylko hobby i okazja do nauki.

[deshipu]

Ja i tak chce zobaczyć w jaki sposób napiszesz te funkcje tak krótkie, żeby między nimi jeszcze zdążyć odebrać i zdekodować sygnał IR.

Bądźmy szczerzy, podałeś rozwiązanie, które nie zadziała (a przynajmniej nie samo z siebie) i liczysz na to, że pytający i tak nic z tym nie zrobi i nigdy się o tym nie przekona. Co oczywiście zazwyczaj jest dobrym założeniem, bo jakby chciał coś zrobić, to już by dawno poszukał informacji o podanych tu pojęciach, a nie narzekał, że nic nie rozumie. Ale mimo wszystko brzydki trik.

[Elvis]

To akurat powinno być proste - odbiór danych odbywa się w przerwaniu, a dekodowanie można zrobić później w pętli głównej.

[deshipu]

Czyli powtarzasz to, co marek1707 napisał.