Silnik DC, sterowanie prędkością i kierunkiem obrotu

[Czarek2222]

Witam serdecznie,
Piszę w sprawie pewnego problemu dot. programu w Arduino Uno R3. Stworzyłem system sterowania silnikiem DC. Wydaje mi się, że Arduino "samo decyduje" co ma zrobić. W napisanym programie mam podłączony silnik DC na napięciu 5,5V z mostka H i diodami LED wskazującymi świetlnie poziom napięcia (tak jak w lekcji z kursu). Jest zmiana kierunku kręcenia silnikiem na 2 przyciskach z blokadą na pewnej prędkości. Przyspieszanie i zwalnianie silnika na 2 przyciskach zrealizowane na dodawaniu i odejmowaniu zmiennej prędkości oraz przycisk stopu awaryjnego.

W trakcie zmiany prędkości na ekranie LCD wyświetlają się po jakimś czasie dziwne znaki. Inną rzeczą jest to, że po ustawieniu konkretnej prędkości silnika nieznacznie zmienia się ona. Czasem z ekranu całkowicie znikają znaki lub samoczynnie włącza się zaimplementowana przeze mnie funkcja stopu awaryjnego.

Tutaj wstawiam kod:

https://pastebin.com/3eKdw0m6

[jbanaszczyk]

Cześć.

Program jest dobrym przykładem "jak napisać program, żeby się go nie dało zrozumieć".

1. Po co jest "goto"??? To nie basic, a i w basicu można uniknąć. W tym wypadku: goto po coś skacze na początek funkcji loop(). Ale ... jak się skończy funkcja loop(), to Arduino zajmie się na małą chwilę swoimi sprawami i samo ponownie uruchomi funkcję loop(), czyl efektywnie wróci do etykiety start:. W dodatku logika kodu nie wskazuje na jakąkolwiek potrzebę powrotu na początek pętli jak najszybciej. Jeśli gdzieś widziałeś instrukcję goto, to ją jak najszybciej odzobacz.

2. Bardzo lubię zagadki - i mam. Jest jedno stop, które ma zwalniać silnik i drugie stop, które ma go zatrzymać

if(digitalRead(12)==LOW) //stop
...
if(digitalRead(13)==LOW) //stop

Bardzo fajna zagadka, bardzo dziękuję

3. Liczby magiczne. Jakbyś te piny ponazywał jakoś, to by się łatwiej czytało, analizowało itp. A jakbyś nazwał co to jest 8, 9 i 10, to też by pomogło - trochę zgadywałem, w kodzie nie ma ani literki podpowiedzi.

Na przykład tak:

const int buttonFaster = 11;
const int buttonSlower = 12;
const int buttonStop = 13;
const int buttonModeL = 14;
const int buttonModeR = 15;
const int bridgeA = 8;
const int bridgeB = 10;
const int gearSpeed = 9;

4. Zmienne (o zgrozo globalne) "i" oraz "s". Zazwyczaj takie zmienne (krótkie, nieznaczące nazwy) używamy jak zmienne tymczasowe, w szczególności powszechnie używamy "i" w pętli. "i" jako speed - prosisz się o kłopoty w przyszłości przy kolejnych zmianach kodu.

5. Dziwne coś:

if(i<255) //blokada na 255
 {
   i=i+1;
 }
 else
 i=255; //max

No już gorzej tego nie można było zapisać.

Komentarz: że blokada na 255 ... no przecież w tej samej linii widzę, że na 255. Dobrze, że w komentarzu nie ma "blokada na 256", bo by była zagadka.

i = i + 1; instrukcja jest nawiasach klamrowych. Ale już kolejne i=255; w nawiasach nie jest. Sformatowane jest tak absurdalnie, że naprawdę nie jestem pewien, czy po "else" był jakiś kod i zniknął, czy właśnie tak ma być.

blokada na 255: Nikt nie zwiększy i powyżej 255, po co else i=255? Na wszelki wypadek??? Voodoo?

Ja bym ten fragment napisał tak, bez żadnych else:

       if (speed < 255) {
           ++speed;
       }

6. Zmienna s. Zmienna ma dwie wartości - 0 i 1 (marną nazwę). Pewnie miałeś na myśli boolean. Na przykład:

boolean leftMode = true;
...
leftMode = false;
...
if ( leftMode ) {
 ... 
} else {
 ...
}

6. Sformatuj kod przyzwoicie, nazwij zmienne i stałe, wynieś obsługę lcd do procedur, zwróć uwagę, że procedury mogą mieć parametry - znakomicie ułatwiają życie i zobacz co masz w kodzie.

7. Ja to zrobiłem, wywaliłem precz obsługę lcd (długa, nudna i zaciemnia obraz) i wyszło mi coś takiego:

int speed = 0;

const int buttonFaster = 11;
const int buttonSlower = 12;
const int buttonStop = 13;
const int buttonModeL = 14;
const int buttonModeR = 15;
const int bridgeA = 8;
const int bridgeB = 10;
const int gearSpeed = 9;

void setup () {
   pinMode (bridgeA, OUTPUT);
   pinMode (gearSpeed, OUTPUT);
   pinMode (bridgeB, OUTPUT);
   pinMode (buttonFaster, INPUT_PULLUP); //rozruch
   pinMode (buttonSlower, INPUT_PULLUP); //zatrz
   pinMode (buttonStop, INPUT_PULLUP); //awaryjny stop
   pinMode (buttonModeL, INPUT_PULLUP); //strona krecenia L
   pinMode (buttonModeR, INPUT_PULLUP); //strona krecenia R
   digitalWrite (bridgeA, LOW);
   digitalWrite (bridgeB, HIGH);
}

void loop () {
   if (speed < 75)  //blokada na zmiane kierunku w pracy silnika
   {
       if (digitalRead (buttonModeL) == LOW) {
           digitalWrite (bridgeA, HIGH);
           digitalWrite (bridgeB, LOW);
       }
       if (digitalRead (buttonModeR) == LOW) {
           digitalWrite (bridgeA, LOW);
           digitalWrite (bridgeB, HIGH);
       }
   }
   if (digitalRead (buttonFaster) == LOW) {
       if (speed < 255) {
           ++speed;
       }
       analogWrite (gearSpeed, speed);
   }
   if (digitalRead (buttonSlower) == LOW) {
       if (speed > 0) {
           --speed;
       }
       analogWrite (gearSpeed, speed);
   }
   if (digitalRead (buttonStop) == LOW) {
       speed = 0;
       analogWrite (gearSpeed, speed);
   }
}

Nie wiem, jak dla Ciebie, ale dla mnie ten kawałek kodu daje się odczytać, zrozumieć i przeanalizować.

A z szybkiego spojrzenia wynika mi, że: jeśli połączyłeś to tak, jak mi wynika z kodu, i nie pomyliłeś się w połączeniach (a chyba nie, bo układ ogólnie działa), to w kodzie nie ma żadnych powodów, żeby silnik zmieniał prędkość albo włączał się stop (ten drugi stop, nie ten pierwszy). Czyli sporadycznie odczytujesz na pinach buttonFaster, buttonSlower oraz buttonStop wartości LOW, które biorą się z powietrza. A dokładniej - z zakłóceń. O tu masz opisane na przykład: https://www.forbot.pl/forum/topics20/teoria-mostek-h-h-bridge-kompendium-dla-robotyka-vt111.htm W sumie mało dziwne - na zdjęciu nie widać nic, co mogło by zakłócenia eliminować, silnik sieje iskrami, kabelki łapią jak antenki, no to czasem się dzieją cuda.

[Czarek2222]

Proszę o zrozumienie, ze to mój pierwszy dłuższy program na Ardiino i jeszcze był wersją roboczą.

Co do problemu, winne okazały się sztywne przewody łączące silnik z płytką stykową, gdyż przenosimy drgania silnika na mikrokontroler. Arduino było również przymocowane do płytki. Silnik podłączyłem do innej pytki, a ją znowu giętkimi przewodami połączyłem ze starą płytką.

[marek1707]

To pokazuje, że w tego typu projektach ważne jest wszystko. Zarówno uwaga przy konstruowaniu części sprzętowej (przemyślany schemat, dobrze mechanicznie i elektrycznie wykonane połączenia, nic na szybko lub na chwilę), jak i program tworzony i testowany po kolei, na każdym kroku rozwoju. Nic dużego stworzonego w pośpiechu, bez trzymania się jakiejś idei przewodniej i ogólnych zasad raczej nie zadziała. A jeśli już, to nigdy nie będzie pewności, że nie robi przy okazji czegoś głupiego albo że robi poprawnie wszystko czego oczekiwaliśmy. Tak, to truizmy tylko że wciąż mamy przykłady takich programów i takich konstrukcji. Być może w kursach dla początkujących majsterkowiczów trzeba kłaść (jeszcze) większy nacisk na kulturę pracy elektronika a w kursach programowania większą połowę powinna zajmować teoria i praktyka (poparta przykładami) dot. samego procesu projektowania, pisania, uruchamiania i testowania kodu. Wiem, są liczne książki o inżynierii oprogramowania, wiele pisanych niestety jeszcze w czasach świetności Fortranu a mam nieodparte wrażenie, że nowości skupiają się na "Szalonym Geniuszu" i są raczej zbiorkiem gotowców dla klecących coś w godzinę z gotowych modułów i bibliotek Arduino. Tam wszystko jest proste (bo trudnych rzeczy nikt nie kupi) i działa od razu. A ludzie myślą, że tak jest zawsze. Piszą swoje "programy" łącząc czasem (o zgrozo) wiele internetowych przykładów w jedno spaghetti a potem bezradni wrzucają je tu w całości i.. "Pomóżcie!".

jbanaszczyk, dzięki za wkład pracy w pokazywanie totalnym amatorom jak powinien kod wyglądać. Ja zaczynałem moje C od już pożółkłego Kernighana/Ritchiego i moim zdaniem jest to jakiś dobry(?) początek, choć nie jest to przecież książka stricte o tworzeniu dobrych programów.

Mam niestety podejrzenie, że oglądając gotowe Lamborgini (Twój kod) nikt nie stanie się od tego dobrym konstruktorem maszyn (programistą). Czy możesz wskazać jakieś przystępne pozycje, najlepiej wydane w Polsce, lub kursy internetowe, które pomogłyby piszącym swoje pierwsze programy zrozumieć nie tyle składnię, co właśnie wagę kolejnych etapów tworzenia programu? A może sam coś takiego byś tu pociągnął od zera?

EDIT: Nic z tego co napisałem nie jest skierowane bezpośrednio do Autora wątku - to tylko takie luźne uwagi i przemyślenia. Każdy jest przecież w czymś początkujący (ja na przykład od jakiegoś czasu dowiaduję się ile jeszcze nie wiem o władaniu japońskim mieczem) i to nic złego. Uważam, tylko, że skoro nie jesteś pierwszym, który prezentuje podobnej klasy kod i bezradnie prosi o pomoc to znaczy, że materiałów i wiedzy o projektowaniu i tworzeniu programów jest stanowczo za mało. I że paradoksalnie dużo złego robią właśnie poradniki typu "20 prostych projektów na Arduino". Jeśli ktoś zna książkę/stronę w której opisuje się powstawanie jakiegoś nietrywialnego projektu od zera, ze wszystkimi przemyśleniami, ślepymi uliczkami, błędami i poprawkami - niech wskaże. Albo o tym jak projektować, pisać i uruchamiać poprawnie wyglądające i działające programy dzisiaj, w świecie IDE, gotowych modułów, bibliotek. Być może nic nie zastąpi doświadczenia, ale jednak jakichś ram można się trzymać. Przecież jazda po szynach ułożonych przez kogoś wcześniej jest łatwiejsza. Co o tym myślicie?

[Czarek2222]

OK. Dziękuję za rady i krytykę dotycząca programu. Następnym razem przyłożę się do tworzenia kodu.

[jbanaszczyk]

Proszę o zrozumienie, ze to mój pierwszy dłuższy program na Ardiino i jeszcze był wersją roboczą.

Na wszelki wypadek: zapomniałem napisać jakiegoś disclajmera, że mój post był pozytywny, miał na celu wyłącznie rozwiązanie jakiegoś problemu, fajnie wyszło, bo się pokazało, że program nie ma jakichś fundamentalnych błędów i problem leży gdzie indziej.

Każdy jakoś zaczynał, nikt nie wyssał wiedzy w kołysce, ja mam wiele lat doświadczenia (choć nigdy nie pracowałem jako deweloper czy programista ), to mi łatwiej zauważyć.

Kto nic nie robi, ten nic nie osiągnie, próbuj dalej, to trudna sztuka. Jakbyś Ty albo ktokolwiek potrzebował mojego wsparcia to mnie znajdzie.

jbanaszczyk, dzięki za wkład pracy w pokazywanie totalnym amatorom jak powinien kod wyglądać. Ja zaczynałem moje C od już pożółkłego Kernighana/Ritchiego i moim zdaniem jest to jakiś dobry(?) początek, choć nie jest to przecież książka stricte o tworzeniu dobrych programów.

Mam niestety podejrzenie, że oglądając gotowe Lamborgini (Twój kod) nikt nie stanie się od tego dobrym konstruktorem maszyn (programistą). Czy możesz wskazać jakieś przystępne pozycje, najlepiej wydane w Polsce, lub kursy internetowe, które pomogłyby piszącym swoje pierwsze programy zrozumieć nie tyle składnię, co właśnie wagę kolejnych etapów tworzenia programu? A może sam coś takiego byś tu pociągnął od zera?

Rada pierwsza: wyrzuć C. Arduino w pełni wspiera C++ (albo odwrotnie: C++ w pełni wspiera Arduino). I to nie prehistoryczne C++, które w zasadzie było "C z klasami", a bardzo fajne, nowoczesne, sprytne i mniej podatne na błędy C++11/C++14. Już nawet z bibliotek standardowych Arduino znika C. Coraz mniej #define, coraz więcej nowoczesnych konstrukcji. C K&R jest językiem z lat siedemdziesiątych zeszłego wieku (czterdzieści parę lat inżynierii oprogramowania), zwykłe C++ to jest C++99 (18 lat minęło).

Materiały: nie mam pojęcia. Przede wszystkim: wszystkie publikacje Stroustroupa, Meyersa i Suttera. Albo chociaż CppCoreGuidelines Tylko nie wolno popadać w przesadę, bo urządzenie samo się nie zlutuje.

Kurs: zacząłem majstrować jakąś własną darmową książkę o C++, szkic jest do znalezienia na moim githubie, miała wspierać dedykowany, fizyczny kurs dla kilku osób "od zera od bohatera, czyli jak w pół roku zrobić z kartografa programistę". Kurs fizyczny poszedł swoją drogą, kartografowie lada moment będą aplikować do pracy w nowym zawodzie, a książka po jednym rozdziale nie nadążyła, ... mam w planach kontynuację. Książka miała być na mega liberalnej licencji CC BY 4.0, jak masz pomysł na współpracę, to ja jestem chętny porozmawiać.