deshipu

Zobaczymy, być może tak będzie. Na razie nie będę wyrzucał, a na przyszłość zawsze będę pisał wymiary na rysunkach wysyłanych do takich projektów. Tylko na zewnątrz obrysu, bo jeszcze mi to wygrawerują...

No cóż, zdjęcie zamieszczę, ale nie wyszło to najlepiej... Następnym razem umieszczę na rysunku wymiary, żeby nie było problemów ze skalą.

Pierwsza jest zdecydowanie łatwiejsza do debugowania.

Projekt się powoli rozwija. Właśnie została założona lista mailowa pod adresem pewpew@python.org (można się na nią zapisać odwiedzając http://mail.python.org/mailman3/lists/pewpew.python.org/) dla wszystkich użytkowników urządzenia. Poza tym pracuję nad zamówieniem przeszło tysiąca sztuk na potrzeby pewnej konferencji (niestety wszystko jest na razie tajne/poufne), więc są nadzieje, że przybędzie niedługo trochę nowych użytkowników. Zmiany w firmware CircuitPythona niezbędne do działania urządzenia zostały wprowadzone do oficjalnej dystrybucji i dzięki temu można zawsze ściągnąć najnowszy firmware ze strony https://circuitpython.org/board/pewpew10/. Jeden z użytkowników opublikował stworzoną przez siebie grę logiczną Othello (znaną też jako Reversi), dostępną pod adresem https://github.com/pewpew-game/game-othello. Jutro powinno do mnie dotrzeć zamówienie zawierające wycięte laserem z akrylu elementy mechaniczne do przymocowania na tył konsolek, poprawiające ich kształt — wspominałem wcześniej o ich prototypowaniu z drewna. Kiedy dotrą napiszę o nich więcej. To na razie tyle.

Zauważcie, że tu nie chodzi o jednorazowe wyznaczanie położenia, tylko o uszczegółowienie położenia, które kosiarka już mniej więcej zna na podstawie własnych czujników takich jak enkodery w kołach, akcelerometr, żyroskop i kompas. Zatem problem z dwoma możliwymi położeniami przy dwóch bojach odpada, chyba, że kosiarka akurat znajduje się prawie dokładnie między nimi. A jak wyznaczyć swoje położenie przy pomocy tylko jednej boi? Bardzo prosto: wystarczy zmierzyć do niej odległość, przesunąć się o znany dystans w znanym kierunku i zmierzyć tę odległość ponownie. Uzyskamy trójkąt o znanej długości wszystkich boków (a właściwie 4 możliwe trójkąty), którego czubek wskazuje nam położenie boi względem dwóch położeń kosiarki przy podstawie trójkąta. Jeśli teraz będziemy takie pomiary wykonywać cały czas podczas ruchu, to jesteśmy w stanie odfiltrować niedokładności i dość dobrze zgadnąć gdzie jesteśmy. Artykuł wyraźnie wspomina, że kosiarka ma wyłącznie "czujniki optyczne", więc ta kwestia jest rozwiązana. Czy są to czujniki badające czas lotu fotonów (mamy już takie w powszechnym zastosowaniu) czy też na przykład prosta tasiemka czujników optycznych mierząca rozstaw dwóch światełek, albo nawet po prostu kąt pod jakim widoczna jest latarnia — to już trzeba by było sprawdzić, bo wydaje mi się, że każde z tych rozwiązań mogłoby dobrze działać.

Sami zrobiliśmy własne zabezpieczenia!

A mógłbyś napisać coś więcej, bo nie każdy zna te układy na pamięć?

Jak to pisałem, to miałem na myśli sam czujnik, a nie mikrokontroler, więc nie "takie urządzenia" — dyskusja była o szyfrowaniu komunikacji z każdym czujnikiem. Ale nawet w przypadku gdy masz urządzenie które może ci robić szyfrowanie, to sam sobie odpowiadasz na pytanie: albo płacisz za urządzenie które ma tyle pamięci, żeby certyfikaty się zmieściły, albo płacisz komuś, kto wie, że certyfikaty potrzebujesz, skąd te certyfikaty wziąć, jak je wgrać i jak je zweryfikować. Albo kogoś, kto to wie i do tego zaprojektuje interfejs, instrukcję i będzie robił support dla użytkowników, którzy mimo to nadal nie ogarniają, bo zawsze się tacy znajdą. Niestety nie ma nic za darmo. Skoro szyfruje, to po co ci ten zepsuty HTTPS? Żeby zrobić man-in-the-middle, wystarczy, że będziesz gdziekolwiek na drodze pakietów — lokalną sieć WiFi masz zaszyfrowaną, ale dalej przez cały Internet już wszystko leci szyfrowane tylko TLS-em, którego równie dobrze w tym przypadku mogłoby nie być, bo nie sprawdzasz z kim się połączyłeś. A to jest akurat bardzo proste. Jak nie ma zabezpieczeń, to się dwa razy zastanowisz zanim prześlesz otwartym tekstem hasła, klucze, etc. — a jeśli nawet będziesz musiał to zrobić, to je osobno zaszyfrujesz. Będziesz mieć też mniejsze zaufanie do takich danych i odpowiednie zabezpieczenia. A jak jest "bezpieczne", to przecież "nie trzeba", więc hulaj dusza piekła nie ma. Do tego pojawia się problem używania tego samego hasła/klucza/certyfikatu do innych rzeczy (bo przecież to tyle pracy je generować za każdym razem jak wygasają), więc często jak złamiesz taki słabo zaimplementowany szyfr w czymś mało ważnym, to uda ci się uzyskać dostęp do dużo ważniejszych rzeczy.

Obstawiam, że baterie się wyładowały i nie dają wystarczająco dużo prądu żeby poruszać tym serwem. Zmierz jakie rzeczywiście dają napięcie pod obciążeniem.

Nie tylko nie zawsze trzeba, ale wręcz prawie nigdy nie należy. Co nie znaczy, że nie trzeba też wiedzieć co robią te biblioteki, których się używa. Większość luk bezpieczeństwa wynika nie z błędów w algorytmie czy w kodzie biblioteki, ale z ich niezrozumienia i użycia niezgodnie z przeznaczeniem. Nikt nie twierdzi, że to jest bzdurny wynalazek. No właśnie nie bardzo. To znaczy niby "potrafi", ale tak naprawdę nie: nie weryfikuje certyfikatów, więc równie dobrze mógłbyś tam nic nie mieć i man-in-the-middle i tak ci wszystko przeczyta. A częściej właśnie źle użyta kryptografia spowoduje, że dokładnie ten sam dzieciak będzie mieć kupę frajdy robiąc ci dyskotekę w domu żarówką. Nikt cię nie zmusza ani do czytania, ani do pisania w tym temacie. Ani, prawdę mówiąc, w żadnym innym temacie na tym forum. Nawet specjalnie poprosiłem o jego wydzielenie, żebyś nie czuł się zobowiązany.

Z mojego doświadczenia na różnych forach wynika, że tego typu głosowanie na tematy nie sprawdza się za dobrze. Ludzie zawsze będą faworyzować tematy, które już znają (bo taka jest ludzka natura), zamiast tych, które rzeczywiście by ich czegoś nauczyły. Z drugiej strony przydatność artykułu znacznie bardziej zależy od tego jak dobrze jest napisany i jak dobrze tłumaczy dany problem, niż od tematu który porusza — nawet na zupełnie trywialne tematy można napisać naprawdę dobre i przydatne artykuły. Zatem wydaje mi się, że nie ma co się przejmować czy danym tematem jest zainteresowanie, tylko po prostu napisać najlepiej jak się potrafi o tym, co się wie i czym się interesujemy.

Zatem może skupmy się na tym jakie są fakty, a nie na tym kto o nich wspomniał i czy przy tym źle przetłumaczył jedno słowo, które nie ma i tak wpływu na te fakty. Teza, do której próbuję tutaj przekonać to: Szyfrowanie wszystkiego bez zrozumienia co się robi nie zwiększa bezpieczeństwa systemu, a wręcz zmniejsza je, wprowadzając fałszywe poczucie bezpieczeństwa, dodatkowe koszty i dodatkowe słabe punkty. Zrobienie szyfrowania porządnie wymaga specjalistycznej wiedzy i przez to jest kosztowne — nie wystarczy po prostu wpisać "import security" i będzie wszystko dobrze.

Bardzo fajny pojazd. Niemal 40km/h to naprawdę sporo jak na taki niepozorny silniczek. Zastanawiam się czy tego typu konstrukcje zabezpiecza się w jakiś sposób przed błotem i kurzem?

Ale nieistotne jest kto to mówi — w końcu nawet największy idiota czasem powie prawdę. Gdyby tak nie było, wystarczyłoby słuchać idiotów i robić odwrotnie niż mówią.

Oprócz szerokiej gamy monochromatycznych wyświetlaczy OLED, e-ink i LCD, na rynku znaleźć też można wyświetlacze kolorowe, czy to LCD czy OLED, nierzadko nawet w postaci gotowych modułów. Ze względu na ilość danych, jakie do nich trzeba przesłać, wyświetlacze te zazwyczaj używają protokołu SPI z dodatkowym pinem (same wyświetlacze często obsługują także kilka trybów równoległych, ale nie widziałem jeszcze gotowego modułu, który by udostępniał odpowiednie wyprowadzenia). Dość często są one nawet wyposażone w panel dotykowy. Kusi zatem ich użycie w naszych projektach do wyświetlania interfejsu użytkownika. Niestety, gdy tylko spróbujemy użyć jednej z gotowych bibliotek na Arduino, przekonamy się, że są one panicznie wolne. Odświeżenie ekranu potrafi nawet zająć kilka sekund — używanie takiego interfejsu użytkownika to mordęga. Czy to zatem wina wyświetlacza? Ale jeśli podłączymy go do RaspberryPi i ustawimy odpowiedni sterownik w jądrze, to ten sam wyświetlacz działa relatywnie szybko — da się nawet na nim grać w gry komputerowe? Co jest zatem nie tak? Czy to wina samego Arduino? Okazuje się, że częściowo winę ponosi dosyć wolne taktowanie SPI w Arduino, ale większym problemem jest sposób, w jaki te biblioteki wysyłają dane. Generalnie spotkać można dwa podejścia, oba dosyć wolne: Bufor Ramki Pierwszym podejściem jest użycie bufora — wielkości całego ekranu, lub, jeśli brakuje nam na to pamięci — części ekranu. Wszystkie operacje graficzne skutkują w zmianach w tym buforze — wobec czego są relatywnie szybkie. Na koniec, cały bufor jest wysyłany do wyświetlacza. Jeśli bufor zajmował tylko część ekranu, to wszystkie operacje graficzne są powtarzane dla poszczególnych fragmentów ekranu, aż cały ekran nie zostanie odświeżony. Podejście takie ma tą zaletę, że nawet jeśli wiele naszych operacji graficznych dotyka tych samych pikseli, to na koniec każdy z nich wysłany jest tylko raz — zatem nie "boli" tak bardzo na przykład rysowanie pogrubionego prostokąta przez narysowanie najpierw większego prostokąta, a potem mniejszego wewnątrz, w kolorze tła. Poniższy rysunek ilustruje tą ideę: Niestety podejście to ma dwie duże wady: po pierwsze, wymaga gigantycznych, jak na możliwości mikrokontrolerów, ilości pamięci RAM, a po drugie, niepotrzebnie wysyła co klatkę te wszystkie piksele, które się wcale nie zmieniły. Ten drugi problem można rozwiązać przynajmniej częściowo, kosztem dodatkowej pamięci, zapamiętując po prostu które piksele się zmieniły i wysyłając do wyświetlacza obszar lub obszary które je zawierają. Najprościej jest to zrobić po prostu trzymając w pamięci listę tak zwanych "brudnych prostokątów" (dirty blocks). Jest tu niezłe pole do popisu dla miłośników algorytmów, bo te prostokąty można ze sobą scalać w jeden lub dzielić na kilka, optymalizując transfer. Niestety, większość dostępnych bibliotek nic takiego nie robi. Bezpośrednie Rysowanie Drugim popularnym podejściem jest wysyłanie do wyświetlacza piksela natychmiast gdy tylko jakaś operacja graficzna go modyfikuje. Niewątpliwą zaletą takiego podejścia jest znacznie mniejsze zapotrzebowanie na pamięć, a także fakt, że wynik takiej operacji jest widoczny od razu, bez konieczności odświeżania. Wadą jest to, że na każdy piksel przypada teraz 8-10 bajtów, zamiast 2, oraz to, że widać wykonywanie się każdej operacji graficznej, zatem jeśli się nakładają, to będzie widać migotanie. Tryb Tekstowy A może da się to zrobić inaczej? Być może moglibyśmy się nauczyć czegoś z tego, jak robiły to stare ośmiobitowe komputery? Albo nawet nie takie stare pecety. Otóż zamiast trzymać stan wszystkich pikseli w pamięci RAM, możemy zamiast tego mieć w pamięci ROM wszystkie kombinacje, jakie potrzebujemy, dla fragmentów ekranu, a w pamięci RAM tylko pamiętać który kawałek używa której kombinacji. To szczególnie dobrze sprawdza się do wyświetlania tekstu, gdy w pamięci ROM mamy wzory wszystkich znaków, a w RAM tylko informację o tym jaki znak i w jakim kolorze jest w danym miejscu. Mamy wówczas tylko jedną operację graficzną, jaką jest zmiana pojedynczego znaku. Używamy wówczas małego bufora — takiej wielkości, w jakiej mają się nam na ekranie wyświetlać znaki — do którego kopiujemy z pamięci ROM grafikę nowego znaku, zmieniając odpowiednio kolory. Następnie wysyłamy ten bufor do wyświetlacza. W ten sposób mamy relatywnie mały narzut, zmienia się cały znak na raz i nie zużywamy dużo pamięci. Oczywiście technikę tę można stosować nie tylko do tekstu. Nasze "znaki" mogą być tak naprawdę całymi fragmentami interfejsu użytkownika — ramkami, przyciskami, lampkami, etc. — trochę to przypomina interfejs Norton Commandera, ale przecież nasze kafelki mogą być większe i w wielu kolorach. Co więcej, możemy je łączyć z pozostałymi dwoma strategiami — na przykład mieć na ekranie miejsce, w którym piksel po pikselu będzie rysowany jakiś wykres, obszar, w którym wyświetlany będzie tekst (z małymi kafelkami) i resztę ekranu, gdzie wyświetlimy resztę interfejsu (z dużymi kolorowymi kafelkami). Tak długo, jak obszary nie będą się nakładać, wszystko będzie działać dobrze. Sprite-y No dobrze, ale co w przypadku gdy chcemy mieć jakieś płynnie przemieszczające się elementy, na przykład kursor myszy? Albo bohatera gry komputerowej? Okazuje się, że nadal możemy to zrobić dość wydajnie, jeśli tylko połączymy w jedną całość wszystkie dotychczas wspomniane pomysły: Powyższa ilustracja pokazuje jak może wyglądać taki system. W pamięci ROM mamy grafiki dla naszych kafelków (na przykład części mapy) oraz duszków (postaci gracza, wrogów, pocisków, etc.). W pamięci RAM trzymamy mapę, która mówi jaki kafelek jest w danym miejscu ekranu, oraz obiekty reprezentujące duszki (zawierającą ich pozycję i wskaźnik do grafiki). Mamy dwie możliwości operacji graficznych: zmiana zawartości kafelka, lub zmiana zawartości lub położenia duszka. W pierwszym przypadku, brudnym blokiem jest obszar zajmowany przez kafelek, w drugim — obszar zajmowany poprzednio przez duszka, połączony z obszarem zajmowanym przez jego nową pozycję. W każdym z tych przypadków, tworzymy w pamięci bufor wielkości naszego brudnego prostokąta i wypełniamy go odpowiednią grafiką. Mamy tutaj dwie możliwości, które mogą działać lepiej lub gorzej w zależności od specyfiki systemu. Albo rysujemy każdy z kafelków, których dotyka nasz brudny blok, a następnie na tym rysujemy każdego duszka, który ma choć jeden piksel w środku bloku (kolejność rysowania duszków jest istotna). Albo iterujemy po pikselach naszego bufora sprawdzając najpierw wszystkie duszki a na końcu kafelek, aż nie znajdziemy elementu, który jest w tym miejscu widoczny. Wtedy sprawdzamy jaki kolor ma mieć ten piksel i przechodzimy dalej. Pierwsze podejście sprawdza się przy pojedynczej warstwie kafelków i małej liczbie duszków. Drugie podejście jest lepsze kiedy mamy kilka warstw kafelków (z przezroczystością), albo na przykład duże kafelki i mały tekst, oraz większą liczbę duszków. Jak szybko to działa? Zależy oczywiście od ilości zmian, ale jest to wystarczająco szybkie, aby pisać gry komputerowe w MicroPythonie: