Moduł startowy tzw. wiedeński - komenda stop vs kill switch

[aw]

Mam dwa pytania:

1. Implementuje moduł startowy do swojego robota w kategorii sumo. Możecie mi powiedzieć po co dodatkowo wprowadzono killswitcha skoro może on działać tak samo jak komenda stop?

Dokumentacja

2. Gdzie można nabyć gotowy referencyjny moduł pilota?

[Hudyvolt]

ad. 1. może działać ale nie powinien. Idea killswitcha jest taka żeby sygnał ten podłączyć bezpośrednio do wejścia ENABLE/STAND-BY układu sterującego silnikami aby w momencie sygnału STOP wyłączyć silniki niezależnie od mikrokontrolera. Sam sygnał START/STOP jest obsługiwany przez uC co stwarza co najmniej dwa zagrożenia: błąd programisty i robot nie zatrzyma się po sygnale STOP lub uszkodzenie mikrokontrolera, który nie wyłączy silników.

[aw]

ad. 1. może działać ale nie powinien. Idea killswitcha jest taka żeby sygnał ten podłączyć bezpośrednio do wejścia ENABLE/STAND-BY układu sterującego silnikami aby w momencie sygnału STOP wyłączyć silniki niezależnie od mikrokontrolera. Sam sygnał START/STOP jest obsługiwany przez uC co stwarza co najmniej dwa zagrożenia: błąd programisty i robot nie zatrzyma się po sygnale STOP lub uszkodzenie mikrokontrolera, który nie wyłączy silników.

Też bym to zrozumiał gdyby tak było, ale wg dokumentacji killswitch polega na zatrzymaniu obwodu silnika za pomocą kontrolera:

http://www.startmodule.com/implement-yourself/kill-switch-relay/

Wydaje się mi że w tej dokumentacji killswitch jest użyty jako obejście do motor driver-a np. mostka H. Można sobie wyobrazić że przycisk stop powoduje że silniki hamują robota aż enkodery powiedzą że koła się nie obracają. A po naciśnięciu kill-switcha robot jeszcze chwilę zachowuje swój pęd.

Takie podejście jest jak dla mnie trochę dziwne właśnie pod względem co napisałeś że tak czy siak może nawalić oprogramowanie w kontrolerze.

[Hudyvolt]

link który podałeś jest akurat do działu "implement yourself" czyli pomijając moduł startowy zewnętrzny. Nie ma żadnych przeciwwskazań aby funkcję odbioru danych z podczerwieni realizował twój główny mikrokontroler. Stosując zewnętrzny moduł kill-switch można podłączyć bezpośrednio do mostka czy przez przekaźnik/optoizolator.

To o czym piszesz odnośnie hamowania po stopie i toczeniu się po killswitchu nie ma miejsca bo na pilocie nie ma przycisku killswitch, są tylko 3: start, stop i programowanie.

[aw]

link który podałeś jest akurat do działu "implement yourself" czyli pomijając moduł startowy zewnętrzny. Nie ma żadnych przeciwwskazań aby funkcję odbioru danych z podczerwieni realizował twój główny mikrokontroler. Stosując zewnętrzny moduł kill-switch można podłączyć bezpośrednio do mostka czy przez przekaźnik/optoizolator.

To o czym piszesz odnośnie hamowania po stopie i toczeniu się po killswitchu nie ma miejsca bo na pilocie nie ma przycisku killswitch, są tylko 3: start, stop i programowanie.

Jesteś tego pewny że nie ma dodatkowego przycisku? W minisumo nie ma killswitch-a on jest tylko w sumo. Dział "implement yourself" to dział dla osób które chcą samemu zrobić odbiornik, co nie znaczy że nie może to być osobny moduł, ale został tak przedstawiony jakby ten osobny moduł nie był potrzebny.

Przeciwkazanie do robienia czegoś takiego na głównym mikrokontrolerze jest proste - np. mikrokontroler wpada w jakiś deadlock. Dlatego się dziwię że taki schemat jest na tej stronie. Bo w takim razie tak jak napisałem na początku nie ma różnicy pomiędzy takim killswitchem a przyciskiem stop. Chyba że tak jak napisałem stop powoduje że robot jeszcze dodatkowo hamuje.

[Hudyvolt]

na 100% nie ma na pilocie przycisku killswitch (na stronie możesz pobrać schemat oraz pcb i zobaczysz, że nie ma takiego przycisku).

idea jest taka, że sygnał STOP obsługiwany jest programowo (i jeśli jest taka Twoja wola jako programisty możesz zaprogramować hamowanie), a killswitch powinien być zrealizowany sprzętowo.

w minisumo killswitch jest opcjonalny, ponieważ jadący robot nie stanowi takiego zagrożenia dla otoczenia jak sumo.