Dzisiaj opowieść o kolejnym znanym bugu, który miał ogromne konsekwencje. Podobnie jak w przypadku Therac-25, analiza katastrofy rakiety Ariane 5 przyczyniła się do poprawy procesów wytwarzania systemów safety-critical.

Programowanie i Robotyka
Dzisiaj opowieść o kolejnym znanym bugu, który miał ogromne konsekwencje. Podobnie jak w przypadku Therac-25, analiza katastrofy rakiety Ariane 5 przyczyniła się do poprawy procesów wytwarzania systemów safety-critical.
W dzisiejszym wpisie omawiam najbardziej znany przypadek błędu systemu safety-critical z branży medycznej prowadzący do ciężkich obrażeń i śmierci pacjentów. Został on wnikliwie przeanalizowany teraz służy jako case study w różnego rodzaju materiałach o systemach safety.
W tym artykule odpowiemy sobie na pytanie jakie rodzaje testów powinniśmy wykonywać i w jakich proporcjach. Pomoże nam w tym piramida testów, czyli prosta graficzna reprezentacja ilości testów, kosztu ich utrzymania i szybkości wykonywania. Opiszemy również podstawowe cechy testów każdego poziomu i ich ograniczenia. Wbrew pozorom nie jest to tylko wiedza dla testerów, ale również dla developerów. Szczególnie jeśli korzystają z Test Driven Development.
W ostatnim czasie blog przechodzi zmiany. Duża część z nich nie rzuca się w oczy. Między innymi poprawiłem bezpieczeństwo, przyspieszyłem wczytywanie strony, zainstalowałem nowe pluginy, zacząłem ułatwiać dostęp do najważniejszych wpisów, a nawet zwiększyłem aktywność na fejsie. We wpisie pada trochę nazw pluginów do WordPressa, więc jeżeli też prowadzisz własnego bloga, mogą Ci się również przydać.
Ostatnio na portalu embedded.com zaczęła pojawiać się seria artykułów omawiających 10 najczęstszych problemów w projektach embedded napisana przez Jacka Gannsle. Pierwszym omówionym zagadnieniem były złudne oszczędności (link tutaj). Czytając artykuł zgadzałem się praktycznie z każdym słowem, bo sam obserwuję to samo praktycznie od początku kariery zawodowej. Z resztą nie jest to coś specyficznego tylko dla systemów embedded, czy branży IT, Krótkowzroczne podejście do oszczędności jest chyba ogólnoświatowym standardem i objawia się na wielu płaszczyznach. We wpisie postaram się rozwinąć tę myśl, chociaż będę się trzymał przykładów z IT.
Ostatnio straciłem pół dnia poprawiając wiele pozornie nie powiązanych ze sobą błędy w unit testach. Dokonana przeze mnie zmianie polegała w uproszczeniu na zmianie w kilku miejscach typu zmiennej z uint16_t na int32_t. Jak nietrudno się domyślić, przyczyna wszystkich błędów była wspólna i wiązała się z konwersją signed/unsigned. Linijka, która powodowała błąd wyglądała mniej więcej tak:
uint16_t var = -1;
Ostatnio przez długi czas na blogu panowała cisza spowodowana oczywiście wakacjami. Jednak powoli już wracam do codziennej rzeczywistości, a więc także i do regularnego zamieszczania nowych wpisów. Na początek jeszcze będzie trochę ogórkowo, ponieważ dzisiaj mam zamiar opisać ostatnie tygodnie i plany na najbliższe miesiące. Będzie więc o Woodstocku, o grze IT Startup i o konferencjach.
Pokazany w poprzednim wpisie filmik obrazował jak wyrobiły się otwory w mocowaniu silnika z drukarki 3D. W sumie można się było tego spodziewać, w końcu te tworzywa nie są super wytrzymałe, a ja używam je już od roku. W końcu postanowiłem je poprawić dodając na górze nakrętki na śruby. Powinienem to zrobić od razu po złożeniu i nie mieć problemów z luzowaniem się mocowań. Wpływały one między innymi na działanie regulatora silnika. W tym wpisie opiszę szczegóły prowadzące do poprawienia dokładności regulacji. Na początek jednak filmik pokazujący końcowy efekt (wartości zadane: 0.5m/s i 90°/s przez 2 sekundy):
Wprowadziłem zmiany opisane w poprzednim wpisie i wyniki są wręcz niewiarygodne. Testy pokrywają się z obliczeniami teoretycznymi i symulacją! Działanie nowego regulatora ruchu obrotowego możecie obejrzeć na filmiku:
Program testowy po naciśnięciu przycisku przez 2 sekundy podaje wartość zadaną 360 stopni na sekundę, czyli spodziewamy się dwóch obrotów. W rzeczywistości jest trochę mniej, bo robot musi się rozpędzić przy starcie, a poza tym jest pewien problem mechaniczny..
Po wyeliminowaniu błędów w PID opisanych w poprzednim artykule, mogłem przejść do kolejnych poprawek w module silników. Moją uwagę przykuł regulator prędkości kątowej. Postanowiłem wprowadzić w nim zmiany, aby zwiększyć precyzję obrotu robota i zwiększyć jego stabilność. Do tej pory zdarzało mi się, że robot się wzbudzał i stojąc w miejscu wykonywał czasem niewielkie skręty.