Skocz do zawartości

deshipu

Użytkownicy
  • Zawartość

    3173
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    152

Wszystko napisane przez deshipu

  1. Dostałeś boot loop, który pojawia się generalnie w jednej z poniższych sytuacji: nie wykasowałeś flasha przed flashowaniem i zostały tam jakieś opcje konfiguracji niekompatybilne z tym, co wgrałeś, przy flashowaniu wybrałeś niewłaściwy rozmiar pamięci flash (albo autodetekcja się nie powiodła), przy flashowaniu wybrałeś niewłaściwy sposób połączenia pomięci flash do płytki (są 4 do wyboru, po prostu spróbuj każdy po kolei), niewystarczające zasilanie, ale w przypadku tej płytki powinno być ok. Patrząc na płytkę, jest jeszcze jedna możliwość: MicroPython normalnie nie obsługuje 16MB flasha — musi być specjalny build, żeby to działało. Spróbuj wymusić 4MB.
  2. Jestem pewien, że twój post bardzo pomoże autorowi. Mi już bardzo pomógł. Wielkie dzięki!
  3. Masz rację, autor na pewno nauczył się tej konstrukcji z Icona.
  4. Takie konstrukcje w C++ (a więc i w Arduino) oznaczają co innego niż w Pythonie. Napisz to jako dwa warunki.
  5. Serwa ciągłej rotacji mają z tyłu taką śrubkę, do ustawiania pozycji neutralnej — upewnij się, że poprawnie je wycentrowałeś.
  6. Z mojego doświadczenia takie podejście kończy się wielokrotnym przebudowywaniem (albo wręcz budowaniem od nowa) projektu, w miarę jak odkrywasz nowe problemy i okazuje się, że najlepszym ich rozwiązaniem jest zmiana konstrukcji. Albo kończysz z czymś wielokrotnie bardziej skomplikowanym niż potrzeba, bo złe decyzje konstrukcyjnie po fakcie próbujesz naprawiać oprogramowaniem. Moim zdaniem (oczywiście zrobisz jak uważasz) najlepiej jest pracować równolegle nad projektem mechanicznym i oprogramowaniem (na przykład na jakimś symulatorze), żeby mogły się nawzajem uzupełniać. A jaka dokładność jest dla ciebie odpowiednia? Bo jak przed chwilą o to zapytałem, to napisałeś, że wyjdzie co wyjdzie. Pytanie o konkretne serwa w momencie kiedy nie znasz konstrukcji ani założeń jest moim zdaniem trochę bezcelowe, bo jeśli nie masz wymagań, to każde serwo będzie dobre.
  7. A mierzyłeś czy rzeczywiście są rozwarte?
  8. Ja miałem się okazję sam przekonać ile kosztuje zrobienie produktu z projektu amatorskiego i ta cena mnie zupełnie nie dziwi. To jest niestety inna kategoria niż polutowanie sobie samemu czegoś z części które i tak leżały w szufladzie. Z jednej strony musisz zrobić pewną liczbę prototypów zanim będziesz pewny, że wszystko jest dobrze i nadaje się do wysłania do fabryki. Fabryka musi zamówić wszystkie części, które nie zawsze są łatwo dostępne i nie zawsze są dostępne w małych opakowaniach (więc trzeba zamówić więcej i część się zmarnuje). Jeśli zamawiają je spoza Chin, to dochodzi cło i opłaty za przesyłkę. Fabryka musi ustawić sobie linię produkcyjną, co przy produkcji małej liczby urządzeń wychodzi drogo. Kiedy już wyprodukują wszystko, to robią testowanie i część urządzeń odpadnie na tym etapie — i jakbyś się zastanawiał kto za to płaci, to od razu mogę cię zapewnić, że ty. Na koniec muszą to wszystko zapakować (opakowania też musi ktoś zaprojektować i wyprodukować) i wysłać do ciebie — znowu cło i opłaty za przesyłkę. Ale to jeszcze nie koniec, teraz ty musisz to wszystko przepakować do indywidualnych paczek dla wszystkich ludzi, którzy je zamówili, zaadresować i powysyłać na cały świat. Ale to nadal nie koniec. Część paczek zaginie po drodze i ludzie będą się dopytywać co z nimi — nawet jeśli postanowisz nie wysyłać ich ponownie, to nadal musisz tym wszystkim ludziom odpowiadać. Inni będą mieć problemy z uruchomieniem, często trywialne, inni stwierdzą, że im się nie podoba i chcą zwrócić, etc. — więc musisz komuś płacić za rozmawianie z nimi wszystkimi (albo robić to sam). I to nadal jeszcze nie wszystko. Jak chcesz, żeby to było sprzedawane w jakichś botlandach i tym podobnych sklepach, to ich marża nie jest dodawana do ceny (bo oni nie chcą sprzedawać tego drożej), tylko jest brana z twojej marży — cena jest ta sama, tylko ty dostajesz mniej. Jak nie przewidziałeś tego wszystkiego w cenie, to dokładasz do interesu. I to wszystko zakładając, że wszystko poszło idealnie i nic się po drodze nie zepsuło — co oczywiście nigdy się nie zdarza, więc musisz mieć jakiś margines na nieprzewidziane wydatki. To wszystko się dodaje bardzo szybko, więc jeśli samo wyprodukowanie twojego urządzenia kosztuje $20, to musisz je sprzedawać co najmniej za $60. Interes robi się bardzie opłacalny dopiero kiedy produkujesz tych urządzeń kilka tysięcy.
  9. Robiłem roboty kroczące na atmedze, z czterema nogami każda po 3 stawy i jakoś kinematyka odwrotna go nie zabiła — a nawet nie bawiłem się w jakieś wydajne liczenie funkcji trygonometrycznych na liczbach całkowitych, tylko po najmniejszej linii oporu acos i atan2 z biblioteki standardowej. No ale to był prosty wzór w postaci zamkniętej, z wymuszonym wyborem jednego z rozwiązań. Rozumiem, że przy tylu osiach będziesz mieć tych rozwiązań więcej i niekoniecznie prostym wzorem liczonych — może napisz coś więcej o tym jak planujesz do tego podejść? Jako czujnik pozycji niekoniecznie musi służyć zaraz encoder w postaci licznika impulsów. Może to być zwykły potencjometr, czujnik efektu Halla, enkoder absolutny, etc. — możliwości jest wiele i w zależności od techniki wykonania, można je wbudować w samą konstrukcję robota — na przykład enkoder optyczny może mieć tarczę wyciętą laserem. Można tu dużo ugrać jeśli się to dobrze przemyśli. Możesz też rozważyć na przykład konfigurację SCARA — tam tylko ostatni człon walczy z grawitacją, reszta napędów obraca ramię tylko w poziomie, więc musi tylko przezwyciężyć opory łożysk i bezwładność.
  10. Nie ma znaczenie jaki mocny procesor tam wsadzisz, bo te gry nie wymagają wydajności obliczeniowej — są nawet wersje takich konsolek z attiny. "Arduino compatible" nic dzisiaj nie znaczy, bo są biblioteki kompatybilne z Arduino IDE dla praktycznie każdej platformy, a jak nie akurat nie ma, to nie jest wielkim problemem dopisać jeśli tylko istnieje kompilator C++. Natomiast wymiana wyświetlacza dużo zmienia i powoduje, że nagle musisz przemielić o dwie albo cztery rzędy wartości bajtów w tym samym czasie — pojawiają się problemy nie tylko z szybkością samego procesora, ale także ilością pamięci i szybkością szyn danych. To nie jest tak, że sobie możesz części dowolnie wymieniać dobierając je tylko ze względu na cenę — taką platformę trzeba dobrze przemyśleć, inaczej ci pies z kulawą nogą na to gry nie napisze.
  11. Oczywiście jak zawsze masz rację, przepraszam za próby upraszczania.
  12. Z pinu Arduino (niezależnie, czy na nim wystawiasz sygnał PWM czy jakiś inny) popłynie tyle prądu, ile wynika z prawa Ohma, zależnie od impedancji odbiornika, który do tej nóżki podłączysz. Jeśli będzie to więcej niż te 20mA, to jest bardzo duża szansa na permanentne uszkodzenie Arduino, ale generalnie nie ma jakiegoś stałego prądu, który by tam miał płynąć. Pamiętaj, napięcie zależy od nadajnika, prąd od odbiornika.
  13. To może dodaj zmienną, w której będziesz trzymać docelową prędkość danego silnika, osobną od aktualnej jego prędkości, i w każdym obrocie pętli, jeśli docelowa prędkość jest większa od aktualnej, to zwiększaj aktualną o jakąś ograniczoną od góry wartość, a jak jest mniejsza, to zmniejszaj, analogicznie.
  14. Osoby chętne do faktycznej pracy po prostu biorą się do tej pracy i robią co trzeba, bez konieczności szukania chętnych, umawiania się nie wiadomo na co i chwalenia się w jakich to projektach mają linijki kodu. Jak nie wiedzą od czego zacząć, to szukają istniejącego projektu odpowiadającego ich zainteresowaniom, albo eksperymentują, albo robią kursy (takie jak na tym forum), albo zadają konkretne pytania — aż się nie dowiedzą. Szukanie chętnych do zrobienia projektu tylko po to, żeby móc powiedzieć, że się w nim uczestniczyło (albo, co gorsza, że się go wymyśliło) uważam za stratę czasu. Ale oczywiście to jest tylko moja prywatna opinia.
  15. A jaki masz ten budżet? Bo nawet prosty potencjometr za 20 groszy da ci lepsze przybliżenie pozycji niż potrójna całka z sygnału PWM. Nie wspominając nawet o tym, że prędkość obrotowa tych serw zależy od sygnału w sposób nieliniowy, zależny od obciążenia. Jak już musisz oszczędzać, to zmniejsz liczbę osi, a nie pozbywaj się enkoderów. Druga sprawa, zastanów się nad sposobami przeniesienia napędów tak, aby jak najwięcej ciężaru (i masy) było jak najbliżej podstawy robota, żebyś nie musiał świgać ciężkich serw po całym stole. Nie napisałeś nic o precyzji i powtarzalności, jakie chcesz uzyskać — to także jest ważne przy dobieraniu napędów (lub dobieraniu wielkości do napędów, jeśli koniecznie chcesz iść w tę stronę).
  16. Zawsze tak robię. Ty mówisz za kogoś innego?
  17. Największym problemem jest to, że wszyscy chcą wnosić do projektu swoje pomysły, a nikt — swojej pracy.
  18. A skąd wziąłeś ten ATMlib w którym masz błędy?
  19. Wystawiłem projekt na Tindie, lud zadecyduje czy ma to sens głosując mamoną, jak w prawdziwej demokracji kapitalistycznej.
  20. Tak, są cieńsze i rozstawione co 2.50mm zamiast 2.52mm, bo tak. Co sprawia dodatkowe kłopoty przy używaniu ich z breadboardami i płytkami prototypowymi. Ten problem mój adapter przy okazji także rozwiązuje.
  21. Te otwory już mają średnicę 0.9mm, ale to nie wystarcza (szczególnie kiedy zarówno fabryki płytek, jak i goldpinów mają trochę wariancji). Może do podłączenia JTAG-a na chwilę zadziała, jak dociśniesz palcem. Rozstrzelenie otworów powoduje, że są dociskane przez sprężystość tego kawałka plastiku, który je trzyma razem i w efekcie działa to porównywalnie do sprężynek w żeńskich złączach. Polecam wypróbować.
  22. Dzisiaj czas na super-zaawansowany projekt, zainspirowany rzeczywistym problem. Jeśli ktoś z was kiedyś bawił się macierzami LED, to zapewne nieraz podrapał się po głowie widząc jak poszczególne kolumny i wiersze podłączone są do ich nóżek: Nie dość, że układ jest dosyć losowy, to jeszcze dostępne diagramy zazwyczaj pokazują go od "złej strony" — to znaczy pokazują numery nóżek i fizyczne rozmieszczenie LED-ów, zamiast pokazać fizyczne rozmieszczenie nóżek i numery wierszy i kolumn. Oczywiście 5 minut z ołówkiem w ręce rozwiązuje problem, ale wciąż łatwo o pomyłkę, szczególnie jak podłącza się to na płytce prototypowej. Postanowiłem zatem naprawić problem za pomocą techniki. Oto mój sanitizer do macierzy: Idea jest prosta: płytka PCB dokładnie wielkości macierzy 2x2cm, która przestawia nóżki w bardziej logiczny układ, obrócony o 90°, żeby nie kolidował z istniejącymi nóżkami. Szybkie, łatwe i skuteczne. Schemat zajął mi chwilkę, bo postawiłem sobie wyzwanie żeby nie było żadnych przelotek: Dodatkowym eksperymentem było zamówienie płytek w JLCPCB z ich panelizacją i v-score. Zatem wysłałem im gerbery jednej płytki i zaznaczyłem, że na każdej płytce 10x10cm ma być ich po 5x5=25 sztuk. Z wyniku jestem bardzo zadowolony, v-score to jednak dużo mniej roboty, niż taby z dziurkami: Zastanawiam się teraz czy tego nie wystawić na sprzedaż na Tindie, bo trochę głupio tak same płytki — wysyłka wyjdzie drożej niż sama płytka. Z drugiej strony mógłbym sprzedawać z już przylutowaną macierzą, ale mam ich w szufladzie tylko garść, a nie wiedząc ile się sprzeda nie bardzo wiem ile zamówić. Zastanowię się jeszcze nad tym, być może będę je dorzucał do zamówień jako gratisy. A, jeszcze jedno, dziurki na goldpiny są "pijane", żeby się dało je wetknąć bez lutowania. Ostatni obrazek z przykładem zastosowania:
  23. Wiesz, esp8266 też ma przerwania i wbrew pozorom, wykonują się nawet jak akurat coś wysyła albo odbiera przez WiFi, więc to Arduino tam trochę niepotrzebne, szczególnie jak dokładność ma być do 1 sekundy. Przy takich założeniach, to w zasadzie nawet przejdzie na ESP tylko wywoływanie URL-a (i sprawdzenie odpowiedzi czy doszło, z ewentualnymi powtórzeniami), a czas można tak naprawdę brać z serwera, bo aż takich opóźnień mieć nie będziesz.
  24. Kiedy piszesz "naciśnięcia by się zapisywały", jakie dokładnie dane masz na myśli i z jaką dokładnością?
×
×
  • Utwórz nowe...