deshipu

@ethanak generalnie są dwie drogi, albo można próbować zrobić to samo z mniejszymi zasobami (tak jak sugerujesz), albo można z tymi samymi zasobami (albo większymi) zrobić coś lepszego. Obie są trudne i pozwalają na naukę, ale uczysz się innych rzeczy: albo optymalizacji, albo tworzenia bardziej zaawansowanych gier. Ta druga droga ma znacznie szersze horyzonty, choć jest trudniejsza, bo trzeba samemu decydować w którym kierunku się udać. Niestety, w którąkolwiek stronę się nie pójdzie, to i tak nie mamy szans na konkurowanie z profesjonalnymi lub nawet pół-profesjonalnymi studiami robiącymi gry, ani z komercyjnymi platformami do nich, ani z tanimi chińskimi "100 000 gier w jednej".

@Mechano a to zwracam honor, rzeczywiście innowacja @Treker nie mam nic przeciwko powielaniu istniejących projektów — sam staram się tak projektować, żeby się moje konstrukcje dało łatwo powielić i cieszę się, kiedy ktoś to zrobi. Tylko jak sam zauważyłeś, napisanie nowej gry na arduboya wymaga więcej pracy i umiejętności, niż przeniesienie jego schematu na nowy rodzaj płytki drukowanej. Boli mnie, że to drugie jest świętowane jak pierwszy krok człowieka na księżycu, a to pierwsze przechodzi w zasadzie bez żadnego echa, ot po prostu jeszcze jedna gra. A czasem naprawdę są to osiągnięcia. Weź na przykład ten projekt: https://next-hack.com/index.php/2019/04/07/lets-build-an-handheld-platform-game-with-a-cortex-m0-microcontroller/

Szkoda, że ciągle ta sama atmega328 z tym samym wyświetlaczem oled i te same gry, które ktoś napisał na Arduboy 5 lat temu. Chętnie zobaczyłbym jakąkolwiek innowację, zamiast używania tych samych trzech komponentów z tym samym kodem tylko w różnych obudowach.

Nie, arduino to C++. Przy Raspberry Pi się Python przydaje, ale możesz użyć w zasadzie dowolnego języka programowania.

Może weź to jeszcze przemyśl. Dlaczego chcesz kupować dobre serwa, wywalać z nich istniejące sterowniki i chałupniczo dorabiać do nich swoje własne, nie do końca przy tym rozumiejąc co robisz? One przecież już mają sterowniki w środku, dobrane dokładnie pod te silniki, sterowane z jednego pina twojego Arduino.

No to moje obliczenia są złe — potrzebujesz 30x mniejsze koła

Zobaczmy: 100mm/s to jest 6000mm/minutę, przy 1000 obrotach na minutę i przełożeniu 30:1 musiałbyś mieć koła o obwodzie 180mm, czyli o promieniu mniej więcej 2.86cm. Przy masie 200g (100g to same dwa ogniwa 18650 ważą) i takich kołach, potrzebujesz moment obrotowy 0.2*2.86=0.572kg*cm żeby podjechać na przykład pod próg albo inną przeszkodę. Te silniki dają ci 0.6kg*cm każdy, więc wydaje się, że masz zapas. Powinno działać. Update: Oczywiście zapomniałem o przekładni. Te 0.6kg*cm po przełożeniu będzie 30 razy więcej, więc spokojnie powinno dać radę, chyba, że moment podają już za przkładnią...

Jak nam nie napiszesz jaki błąd miałeś, to jak mamy pomóc?

Ja mam parę pomysłów na dodanie rang niższych niż startowa, ale to pewnie nie przejdzie.

To co masz zagwarantowane, to że przy pobieraniu 2.5A będzie dawał 12V i nie pobierał więcej niż 0.7A z sieci. Tyle wiadomo. W zależności od budowy zasilacza, przy pobieraniu mniej niż 2.5A może na przykład dawać napięcie nawet kilkakrotnie wyższe niż 12V (tanie ładowarki do telefonów tak mają) albo nadal trzymać się tych 12V. Tak samo przy próbie pobrania więcej niż 2.5A napięcie może spaść (tak mają zasilacze ze stabilizowanym prądem), może pozostać takie samo, ale za to zasilacz może się przegrzać, a nawet przepalić lub wybuchnąć, albo może nawet zostać całkowicie wyłączone przez wewnętrzny układ zabezpieczający albo przepalony bezpiecznik. Może też na przykład pulsować, etc. — bez wiedzy o tym co jest wewnątrz zasilacza, lub przeczytania danych katalogowych wszystko jest możliwe.

1. 0.7A oznacza dokładnie siedem dziesiątych ampera, a 2.5A oznacza dokładnie dwa i pół ampera, 2. tak.

I jedno i drugie. Mógłbym go wykorzystać do sprawdzenia czy robot jest do góry nogami czy nie, i to w zasadzie tyle.

Pokrywanie wydruków 3D miedzią:

No i niestety będę musiał przeprojektować tego robota. Okazało się, że w wersji CircuitPythona której używałem żeby wszystko sprawdzić był błąd w module pulseio w tym jak wybierane był timery i ich kanały przy tworzeniu nowych obiektów PWMOut. Przez to niektóre z nich używały tego samego timera i kanału, dzięki czemu zawsze miały ten sam duty cycle, więc serwa poruszały się razem — nie zauważyłem tego, bo przy testach ustawiałem wszystkie serwa w tej samej pozycji — that było najłatwiej napisać program. W nowej wersji CircuitPythona błąd jest poprawiony i pulseio rzuca wyjątek jak się próbuje stworzyć PWMOut dla wielu pinów, a nie ma już wolnego kanału timera. No i oczywiście dostaję taki błąd teraz z moim robotem. Będę musiał usiąść i z naleźć taką kombinację nóżek, dla których da się utworzyć PWMOut jednocześnie, a to niestety oznacza przeprojektowanie płytki. Ale nie ma tego złego co by na dobre nie wyszło: przy okazji wyrzucę akcelerometr (okazał się bezużyteczny), dodam pamięć flash (miejsce w systemie plików się przyda), przeprojektuję układ ładowania baterii (żeby się ładowała przy wyłączonym robocie) i przeniosę wszystko na górę płytki (komponenty schowane pod pojemnikiem baterii wglądają fajnie, ale są strasznie uciążliwe do debugowania). Przy okazji też dorzucę wyłączniki krańcowe na końcach stóp. Jak nie znajdę działającego zestawu 12 pinów, to będę musiał zmienić mikrokontroler na większy.

Olaboga, a co to za klon? Ja też bym obstawiał tą mniejszą: Zobacz jeszcze, czy od spodu na padzie termicznym nie ma ściętego narożnika.