madman07

Ładna konstrukcja. Ode mnie wielki plus za wydrukowanie elementów, oraz jeszcze większy za samodzielnie wytrawienie płytek i oparcie projektu o uc, zamiast pchania tam rpi 😉 Dlaczego silniki krokowe a nie BLDC? Chodziło tylko o łatwość sterowania czy były też inne względy? Dlaczego podczas ruchu robot lekko 'utyka'? Rozumiem zasadność użycia operacji zmiennoprzecinkowych, ale strasznie razi to w oczy. Zawsze można posiłkować się operacjami stałoprzecinkowymi, które są dość proste i szybkie 😉 Czy rozważasz sterowanie poprzez np. telefon (dotyk lub pochylenie) zamiast pilota?

Świetna konstrukcja! Podobnie jak poprzednikom, podoba mi się manipulator. Aż prosi się, aby liczyć kinematykę odwrotną i sterować położeniem końcówki, zamiast wychyleniem serw 😉

Jeżeli autor zbuduje sobie sieć jednokierunkową, złożoną z kilku warstw i wykorzysta algorytm propagacji wstecznej, to to spokojnie powinno pójść nawet na mikrokontrolerze, nie obawiałbym się o wydajność tego na RPi. Może warto po prostu sprawdzić któreś rozwiązania? Np. google podpowiada to. Zależy co masz na myśli, przez 'zaprogramowany ręczie'. Rzucę dla przykładu mój robot. Jeżeli 'ręcznie' znaczy zaprogramować poszczególne zakresy poprzez warunki if-else, to uważam, że ann jest lepsza - 'naturalniej' uczymy robota działania. Wystarczy dodać algorytm uczący i możemy uczyć naszego robota, bez potrzeby przeprogramowywania go za każdym razem.

A gdzie jeszcze widzisz zastosowanie poza rozpoznawaniem obrazu i dźwięku? Wszędzie gdzie się da napisać algorytm na piechotę, to będzie on lepszy. Pomijając przykłady, które podałeś: robot omijający przeszkody (ogólnie symulacja zachowań), ogólnie zadania rozpoznawania i klasyfikacji, przetwarzanie sygnałów, automatyka (jako np. model systemu czy układ sterujący), pamięć i jeszcze wiele wiele innych zastosowań. Szczególnie, jeżeli weźmiemy pod uwagę modele zbliżone do biologiczynch.

Nie lepiej już użyć matlaba na PC i eksportować gotową sieć na RPi, albo i lepiej - zrobić sobie komunikację RPI <> PC i obciążyć obliczeniami PCta? Generalnie sieć można zaimplementować wszędzie. Ja swego czasu (gdzieś na forbocie jest mój projekt) implementowałem sieć na mikrokontrolerze dsPIC30F z tym, że proces uczenia był przeprowadzany na PC (w zależności od wielkości zbioru danych potrafił trwać nawet kilka minut). Np. obecnie robię implementacje na karcie graficznej, co daje mi możliwość symulacji nawet do miliona połączeń synaptycznych. Obawiam się, że z RPi nie osiągniesz dużej wydajności. Jednak wszystko się rozbija o problem, który masz. Jeżeli chcesz rozwiązać zadanie omijania przeszkód, to spokojnie ten mikrokomputer wystarczy nawet, aby w każdym cyklu użyć np. propagacji wstecznej do nauki sieci. Jest wiele bibliotek pod C++, nie musi być to odrazu Matlab 🙂 @deshipu, nie zgodzę się, że sieci neuronowe mają mało zastosowań.

Spacing pomiędzy ścieżkami a wylanym polygonem możesz zrobić większy, aby uniknąć problemów podczas wytrawiania płytki (chyba, że oddajesz do fachowego zakładu). Polecam zapoznać się z notą katalogową stabilizatora, ponieważ nie sądzę, aby producent sugerował takie wartości kondensatorów. niektóre ze ścieżek bez sensu rzucasz pomiędzy warstwami, kiedy mogą spokojnie iść na jednej z nich. Jeżeli planujesz płytkę jednowarstwową to powinieneś unikać warstwy TOP, o ile to możliwe.

Kompilator jasno dał Ci znać, co jest nie tak. Miejsce błędu: HelloWorld.ino: In function 'void loop()': Pierwszy błąd, który mówi, że nie możesz zamienić int na wskaźnik na int: HelloWorld.ino:47:25: error: invalid conversion from 'int' to 'int*' [-fpermissive] oraz drugi błąd, który mówi, że funkcja powinna przyjąć parametr o typie 'const char*' a nie 'int*': HelloWorld.ino:50:39: error: cannot convert 'int*' to 'const char*' for argument '1' to 'size_t strlen(const char*)' Wg mnie tak możesz to naprawić: vw_send(&DHT11.temperature, sizeof(DHT11.temperature));

Faktycznie, z tablicą się zagalopowałem, przepraszam za wprowadzanie w błąd 😉 Powinienem to zapisać tak, jak jest tutaj poniżej to zapisane. Natomiast jest różnica pomiędzy uint32_t z1 = *((uint32_t*)&buffer[1]); a memcpy(&z1, &buffer[1], sizeof(z1)); gdy buffer jest tablicą np. typu uint8_t. Jak sam powiedziałeś, memcpy skopiuje dane dbając o wyrównanie (czy implementacja standardowa uwzględnia optymalizację pod postacią kopiowania np. bloków 4 bajtowych?), natomiast rzutowanie i przypisanie tego nie zrobi.

Mogliśmy się nie zrozumieć 😉 Pierwszy kod jest okej. Natomiast, taki kod (odwołując się do Twojego drugiego przykładu): uint16_t y = x[0]; // y = 5 uint16_t y = x[1]; // y nie musi być równe 10 Tutaj dochodzimy do konkluzji, czyli tego, jak kompilator rzeczywiście to potraktuje. A potraktuje to tak, jak napisałeś (i co pokazuję poniżej). Użycie memcpy (tj kopiowanie bajt po bajcie) ABSOLUTNIE nie jest odpowiednikiem takiego kodu: uint32_t z1 = *((uint32_t*)&buffer[1]); który to kompilator spróbuje przetłumaczyć na instrukcje typu Load-Save zamiast kopiowania bajt po bajcie. W efekcie, dokładnie jak piszesz, mogą stać się niesprecyzowane rzeczy czy nawet wyjątek dostępu do pamięci. To już zależy pewnie od architektury.

Generalnie pierwszy element ma znaczenie. Natomiast chciałbym kolegom przypomnieć o istotnej pułapce, której zdaje się nie zauważać wielu z nas, a która "zadziała" na maszynach 16- i 32-bitowych. Załóżmy, że mam taki kod: uint8_t buffer[16]; uint16_t z1; uint32_t z2; // tutaj kopiujemy coś do bufora, jakieś memcpy itp. z1 = buffer[0]; // dobrze z1 = buffer[1]; // źle z1 = buffer[2]; // teoretycznie dobrze, zależnie od kompilatora i maszyny z1 = buffer[3]; // źle z2 = buffer[0]; // dobrze z2 = buffer[1]; // źle z2 = buffer[2]; // raczej źle, zależnie od kompilatora i maszyny z2 = buffer[3]; // źle Przy przypisywaniu danych z bufora do zmiennych należy uważać na wyrównanie danych w buforze. Jeżeli dane zaczynają się nieparzyście lub nie od wielokrotności 4 (lub 2 dla 16-bitowców), mogą pojawić się problemy. O wiele bezpieczniejszym sposobem jest wtedy wykorzystanie tradycyjnego memcpy: memcpy(&z1, &buffer[1], sizeof(z1)); Jednak należy tutaj pamiętać o poprawnym endianesie - do takich operacji przydane jest mieć specjalne makra, które potrafią przepisać dany typ zmiennej bez względu na rodzaj maszyny, tj wykryć go w czasie kompilacji, albo mieć przygotowany zestaw dla big i little endian. Przykładowym moim makrem do kopiowania uint16_t z niewyrównanego bufora (który trzyma dane w big endian) jest: #define _Int16ToVoidBE(buff, val) {_Lo(buff) = _Hi(val); _Hi(buff) = _Lo(val);} gdzie makra _Lo i _Hi potrafią się odnieść do danych bajtów względem niewyrównanego adresu. Tyle smaczków na dziś 🙂

Nie trzeba do wszystkich, wystarczy dopisać to do pierwszej z nich i zreorganizować mnożenie, lub rzucić pierwszą zmienną na odpowiedni typ: uint32_t total = 3600UL * hours + 60 * minutes+ seconds; uint32_t total = (uint32_t)hours * 3600 + minutes * 60 + seconds; Natomiast należy uważać np. na taki zapis: uint32_t total = 3600 * hours + 60 * minutes+ seconds; ponieważ, wbrew pozorom, wynik może być różny w zależności od zastosowanej maszyny. Zadziała tutaj mechanizm zwany promocją do int, tj. kompilator rzuci pierwszą liczbę do inta. I tak dla 8 i 16-bitówców int ma zazwyczaj rozmiar 16-bitów, a dla 32-bitówców zazwyczaj 32-bity.

Dlatego na zasilaniu sieciowym przełączasz taktowanie (o ile to możliwe) na coś szybszego, np. 8MHz 😉 Ale fakt, biorąc pod uwagę umiejętności, wykorzystanie tutaj dedykowanego scalonego układu będzie najlepszym rozwiązaniem.

Warto zaznaczyć, że nie koniecznie. Nie znam się na ATmegach, nie znam tej konkretnej, ale (na ile pozwala mikrokontroler) można również taktować mikrokontroler z 32KHz na baterii, z generatora RC na zasilaniu sieciowym, trzymać procesor w stanie uśpienia na baterii i cyklicznie go wybudzać do kilku razy na sekundę. Ja np. tak robię w obecnym projekcie aby zaoszczędzić miejsce na PCB oraz pozbyć się transmisji I2C.

Jesteś pewien napięcia wejściowego? Osobiście dałbym na wejściu diodę zabezpieczającą przed odwrotną polaryzacją, bezpiecznik, diodę zenera np. na 5.1V, jakiś dławik i chociażby kondensatory 100uF (albo coś większego) i 100n. Na moje oko przyciski są źle podłączone. Rezystory powinny być "przed" przyciskami, np. do masy podpięte jak jest teraz, natomiast same przyciski powinny zwierać do zasilania (bądź na odwrót, zależnie od preferowanej logiki). Jaki widzisz sens stosowania zewnętrznego RTC, jeżeli nie posiada on baterii? To samo można osiągnąć w głównym procku, przy czym odpada jeden układ i komunikacja I2C.

Generalnie nie polecam MSP430. Mają swoje zalety, ale mają swoje wady. Np. nie możesz jednocześnie użyć UARTu i SPI/I2C 😉 Na pewno nie można na MSP430F44x i MSP430F461x.