Skocz do zawartości

madman07

Users
  • Zawartość

    60
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    2

madman07 zajął 1. miejsce w rankingu.
Data osiągnięcia: 28 marca 2013.

Treści użytkownika madman07 zdobyły tego dnia najwięcej polubień!

Reputacja

9 Neutralna

O madman07

  • Ranga
    4/10

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Wrocław
  1. Ł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?
  2. Ś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
  3. 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 rob
  4. 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.
  5. 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
  6. 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.
  7. madman07

    Zmiana typu zmiennej

    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));
  8. 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.
  9. 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 e
  10. 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
  11. 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 ro
  12. 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.
  13. 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.
  14. 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
  15. madman07

    ARM czy dalsza droga w AVR

    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.
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.