Ekspertyza · Systemy dla robotów

Software dla robotów: warstwa, która decyduje o ruchu, moduł widzenia i moduł słuchu. Dziś mamy weryfikację offline i symulację — nie mamy niczego, co steruje realnym silnikiem.

Piszemy kinematykę, weryfikację trajektorii i odtwarzalną symulację fizyczną, z bramkami, które blokują, gdy brakuje dowodu. Dla wizji mamy prototyp na stałej kamerze, nie na robocie. Dla audio na robocie nie mamy nic zbudowanego i strona mówi to zamiast pożyczać dowody z telefonii. Nie pracujemy z ROS.

Omów projekt

Oferta, z warunkamiUruchomiłem dziś wszystko, co da się uruchomić. Warstwa sterowania istnieje i jest solidna, ale jest offline: własny moduł kinematyki dla ramienia z sześcioma osiami, który rozwiązał 8.400 z 8.400 punktów trajektorii, oraz walidator fizyki na MuJoCo 3.10.0 z 34 zaliczonymi testami, plus 14 testów po stronie wizualizacji. Oba deklarują w swoim kodzie źródłowym, że nie ma transportu do hardware i nie mogą komendować rzeczywistego robota. Na widoku mamy własny prototyp — detekcję i śledzenie osób na stałej kamerze IP — z jednym commitem i pustym katalogiem testów. W audio na robocie mamy zero: wszystko, co jest na dysku, to głos call-center albo biblioteka zewnętrzna telefonii, a jedyne własne opracowanie akustyczne zakończyło się wynikiem negatywnym, zapisanym w aplikacji. ROS: zainstalowane zero, napisane zero. Reguła wymaga minimum dwóch własnych implementacji, żeby powiedzieć „zrobione”; w sterowaniu je mam, ale żadna nie sięga hardware, a pozostałe dwie warstwy usługi są poniżej progu. Więc: oferta z warunkami, z narysowanymi granicami.

Oprogramowanie robota ma trzy warstwy, które psują się różnie: to, co widzi i słyszy, to, co decyduje, i to, co wysyła do silników. Na pierwszych dwóch mamy własne prace z testami, które się uruchamiają. Na trzeciej — moście do hardware — nie mamy nic, i to jest granica usługi, a nie detal implementacji. Dwa z naszych kodów mówią to we własnym nagłówku, po angielsku, dokładnie po to, by nie dało się ich odczytać błędnie: moduł kinematyki nie ma transportu do hardware i nie może sterować prawdziwym robotem.

To, co istnieje po stronie ruchu, to weryfikacja przed ruchem. Własny moduł liczy kinematykę prostą, Jacobiego i kinematykę odwrotną dla ramienia sześcioosiowego, z wymuszoną rezerwą względem limitów każdej osi, i został użyty do sprawdzenia całej trajektorii: 8.400 żądanych punktów, 8.400 rozwiązanych, przy czym maksymalna prędkość na osi pozostała poniżej 8% limitu katalogowego. Osobno walidator fizyki działa na MuJoCo 3.10.0 na procesorze, z krokiem obliczeń jednej milisekundy, w sześciu scenariuszach, każdy po dwa razy, z tym samym ziarnem — i dwa uruchomienia dają identyczne odciski. Determinizm nie jest stwierdzeniem, tylko porównaniem sum kontrolnych.

To, co istnieje po stronie wizyjnej, jest mniej, i uczciwie jest powiedzieć ile. Własny prototyp wykrywa i śledzi osoby na strumieniach z kamer IP, z małym detektorem z rodziny YOLO, śledzeniem wielu obiektów, estymacją postawy dla pięciu stanów oraz sterowaniem obrotem, pochyleniem i zoomem kamery. Ma jeden commit i pusty katalog testów. A różnica między tym a widzeniem robota jest rzeczywista, nie formalna: kamera na robocie porusza się razem z nim, scena jest blisko, ekspozycja zmienia się przy każdym kroku, a budżet opóźnienia jest inny, bo obraz musi trafić do decyzji o ruchu, a nie na ekran. Nie mamy kamery głębi, nie mamy kalibracji kamery, nie mamy wizualnej odometrii.

Po stronie audio dla robotów nie mamy niczego zbudowanego i nie będziemy pożyczać dowodów skądinąd. Mamy realne prace głosowe dla telefonii i asystentów konwersacyjnych, ale mikrofon na robocie ma inne problemy: własny hałas maszyny, wentylatory i serwomotory, które uruchamiają się dokładnie wtedy, gdy robot się porusza, kierunek, z którego dochodzi głos, echo w pomieszczeniu i zmienną odległość. Jedyna własna praca akustyczna, którą mamy, zakończyła się wynikiem negatywnym, zapisanym w aplikacji, i publikujemy go w tej postaci — bo zmierzony wynik negatywny jest bardziej użyteczny niż obietnica.

Co obejmuje

Praca, komponent po komponencie

Sprawdzamy kinematykę przed poruszeniem czegokolwiek

Kinematyka prosta, analityczny Jacobian zbudowany z iloczynów wektorowych, numeryczna kinematyka odwrotna z czterema pozycjami startowymi i rezerwą wymuszoną 10° względem granicy każdej osi, z zbieżnością do 0,05 mm na pozycję. Dzięki niej sprawdziliśmy ustawienie w 1.331 pozycjach siatki i pełną trajektorię z 8.400 punktów, wszystkie rozwiązane. Wyniki: maksymalna prędkość na osi na poziomie 7,86% limitu katalogowego i minimalny margines względem limitów 19,9°. Raport sam opisuje swój charakter: dyskretne skanowanie offline, bez wyjścia do sprzętu.

Uruchamiamy fizykę osobno od obrazu i powtarzalnie

Walidator fizyki to program oddzielony od części wizualnej, na MuJoCo 3.10.0, na procesorze, z krokiem jednej milisekundy i próbkowaniem co 20 milisekund. Sześć scenariuszy, każdy uruchomiony dwa razy z tym samym ziarnem, z identycznymi odciskami między uruchomieniami. Tolerancje są zadeklarowane w kodzie, a nie domyślane: dryf energii poniżej 1% względnie, penetracja w podłoże poniżej 3 cm, naruszenie limitu stawowego poniżej 0,03 radiana. To, co mierzy się w swobodnym spadku, to przyspieszenie środka masy, porównane z ustawioną grawitacją — 9,80665, 1,62 i 3,72076 metra na sekundę do kwadratu.

Stawiamy bramkę, która blokuje, a nie tylko oznacza

Rejestr akcji wymaga, aby każdy ruch zadeklarował swoje pochodzenie, a wszystkie 15 zarejestrowanych akcji jest oznaczonych kinematycznie, zweryfikowanych zerem — bo żaden z tych sterowników nie jest napędzany symulatorem brył sztywnych z ograniczeniami siłowników i walidacją kontaktu. Nad tym działa bramka zwolnienia, która czyta plik dowodowy i odrzuca go, jeśli kluczowa stała nie jest skalibrowana na sprzęcie. Dziś odrzuca: jedna stała zatrzymania stawu, 5 milisekund, jest zadeklarowana w kodzie jako parametr tymczasowy, a nie zmierzona wartość — i to wystarcza, by pełna weryfikacja zakończyła się błędem. To reguła napisana przez nas przeciwko nam.

Czytamy opis robota własnym parserem i mówimy, co pomija

Do wyświetlania i inspekcji modeli napisaliśmy własny analizator formatu MJCF: ciała, stawy typu zawiasowego, swobodnego, przesuwnego i kulowego, geometrie, materiały i ładowanie siatek, z cache geometrii. Celowo pomija geometrie kolizyjne, bo to analizator wizualny, a nie kontaktowy — napisany w kodzie, a nie odkryty później. Używane modele są oficjalne, z 29 stopniami swobody dla humanoida i 12 dla czworonoga.

Nie mylimy wartości zadanych z mierzalnymi

Kąty pojawiające się na ekranie to kąty zadane przez kontroler, publikowane w jednym kierunku do interfejsu. Nie zawierają szumu enkodera, stanu mierzonego, momentu, prędkości ani temperatury — zapisane to jest wprost w audycie technicznym projektu. Różnica ta wydaje się mała, dopóki ktoś nie weźmie ładnego wykresu za telemetrię robota; dlatego zapisujemy ją w kodzie, w audycie i tutaj.

Wizja: wykrywanie i śledzenie osób na stałej kamerze

Własny prototyp, który pobiera strumienie z kamer IP, wykrywa osoby małym modelem z rodziny YOLO, śledzi je między klatkami za pomocą śledzenia wielu obiektów przy progu pewności 0,5, szacuje postawę w pięciu stanach — nieznany, siedzący, stojący, idący, pochylony — i może obracać kamerę przez standardowy protokół sterowania. Działa wymuszenie na procesorze, z powodu niezgodności odnotowanej w kodzie. Jego rzeczywisty stan: jeden commit i pusty katalog testów. To prototyp, nie moduł produkcyjny, i nigdy nie był na robocie.

Audio na robocie: mówimy, czego brakuje, zamiast pożyczać z telefonii

Nie mamy detektora słowa aktywującego, nie mamy lokalnie uruchamianego detektora mowy, nie mamy formowania wiązki, nie mamy estymacji kierunku i nie mamy napisanego przez nas kodu anulowania echa. To, co mamy w obszarze głosu, jest dla połączeń telefonicznych i asystentów konwersacyjnych: przerwanie mówiącej osoby odbywa się albo przez detektor w usłudze dostawcy, albo przez naciśnięcie klawisza w menu telefonicznym, a anulowanie echa pochodzi z bibliotek przeglądarki lub z zewnętrznego stosu telefonii. To rzeczywiste rzeczy, ale rozwiązują inny problem niż mikrofon zamontowany na maszynie, która się porusza i sama generuje hałas.

ROS: nie mamy i nie udajemy, że mamy

Nie jest zainstalowany na żadnym z naszych komputerów i nigdy nie napisaliśmy własnego węzła, pliku uruchomieniowego ani pakietu. Jedynym pakietem z systemem budowy specyficznym dla ROS na dysku jest publiczny opis robota przemysłowego, pobrany jako plik modelu i użyty dokładnie tak, bez kompilacji. Jeśli Twój projekt zakłada ROS 2 jako coś oczywistego, to informacja, którą trzeba mieć przed pierwszym spotkaniem, a nie po nim.

Co zaakceptowalibyśmy, a czego nie

Zaakceptowalibyśmy: sprawdzenie kinematyki i trajektorii przed zakupem, symulację z zadeklarowanymi tolerancjami, moduł percepcji zmierzony na Twoich danych oraz most do hardware'u wykonany wspólnie z integratorem odpowiedzialnym za bezpieczeństwo. Nie zaakceptowalibyśmy: napisania samodzielnie warstwy zatrzymującej robota w sytuacji awaryjnej, obiecywania modułu audio dla robota bez wcześniejszego pomiaru własnego szumu Twojej maszyny, ani twierdzenia, że nasze doświadczenie z głosem w telefonie obejmuje słuch robota.

Jak to wygląda

Trasa, krok po kroku.

Definiujemy zadanie i ograniczenia fizyczne, potem sprawdzamy, czy się mieszczą

Co robot ma osiągnąć, w jakiej objętości, z jaką prędkością i z jakim ładunkiem. Potem weryfikacja: pokrycie objętości, margines względem limitów każdej osi, prędkość i przyspieszenie na trasie, kolizje na rzeczywistej geometrii jako screening. Dostarczamy raport z zapisanymi ograniczeniami. Ta etapa ma dobry stosunek kosztu do unikniętej szkody, bo robi się ją przed zakupem.

Symulujemy z zadeklarowanymi tolerancjami i zweryfikowanym determinizmem

Scenariusze, stałe ziarno, powtarzane uruchomienia, porównywanie odcisków, tolerancje zapisane w kodzie. Dostarczamy też listę rzeczy, których symulacja NIE dowodzi — u nas, na przykład, walidator potwierdzający swobodny spadek i utrzymanie pozycji na planie testowym nie potwierdza chodzenia, złożonego kontaktu ani dynamiki aktuatora i zapisuje to sam.

Budujemy percepcję na Twoich danych, a nie na publicznym zbiorze

Detektor działający na obrazach z internetu nie mówi nic o Twojej hali. Etapa oznacza pozyskanie z rzeczywistego środowiska, własny zbiór ewaluacyjny, pomiar referencyjny i dopiero potem wybór modelu oraz miejsca uruchomienia. Dostarczamy liczby referencyjne i metodę, dzięki której można je odtworzyć, także wtedy, gdy są słabe.

Most do hardware'u — etapa, której nigdy nie zrobiliśmy

Piszymy ją na końcu i z warunkami, bo to jedyna pozycja z listy, w której nie mamy własnego doświadczenia. Robi się ją wspólnie z integratorem albo z producentem robota, a funkcje zatrzymania awaryjnego, ograniczania i bezpieczeństwa pozostają w odpowiedzialności osoby odpowiadającej za maszynę. To, co możemy doprowadzić do tego momentu, to warstwa decyzji, zweryfikowana, z udokumentowanym interfejsem.

Łańcuch robota, od lewej do prawej, z rzeczywistym stanem każdego ogniwa. Widzenie: prototyp na stałej kamerze, jeden commit, bez testów. Słuch: pusto — nic zbudowanego dla mikrofonu na maszynie, która się porusza. Decyzja i kinematyka: zweryfikowane, z 8 400 rozwiązanymi punktami i bramką, która blokuje, gdy stała nie jest skalibrowana. Ostatnia strzałka, ta do silników, jest przerwana: żaden nasz kod nie ma transportu do sprzętu. Rysunek jest zrobiony tak, żeby było widać, gdzie kończy się usługa, nie żeby wyglądał na kompletny.

Dane

Czego dotykamy, gdzie to leży i jak długo zostaje

Pytania, które zadaje każdy, kto ma inspektora ochrony danych — postawione tutaj, zanim on je zada.

Kamera robota filmuje ludzi i to zmienia wszystko: Moduł wizyjny, który wykrywa i śledzi osoby, produkuje dane osobowe w ścisłym znaczeniu tego słowa, nawet jeśli nikt nie jest identyfikowany z imienia i nazwiska. Pytania zadaje się przed pierwszą linią kodu: czy przechowywany jest obraz, czy tylko wynik, gdzie odbywa się przetwarzanie, kto ma dostęp do nagrań, jak długo są przechowywane, co jest wyświetlane osobom filmowanym. Nasz prototyp został zbudowany jako eksperyment techniczny, a nie jako system oddany do użytku, i nie proponujemy go jako takiego.
Na urządzeniu czy na serwerze — decyzja o opóźnieniu, nie o preferencji: Jeśli obraz ma dojść do decyzji o ruchu, droga do serwera i z powrotem wchodzi bezpośrednio do budżetu reakcji. Jeśli wynik jest tylko wyświetlany albo zapisywany, serwer jest akceptowalny. Decyzję podejmuje się na podstawie budżetu opóźnienia zmierzonego na Twoim przypadku i zapisuje się ją. Nasz prototyp działa wymuszenie na procesorze, co jest realnym ograniczeniem prędkości, zapisanym w kodzie.
Symulacje są przechowywane z ziarnem i z odciskiem: Wynik symulacji bez ziarna generatora i bez sumy kontrolnej danych wejściowych nie jest dowodem, jest opowieścią. Nasze raporty fizyczne zawierają ziarno, liczbę uruchomień na scenariusz, wersję silnika i stan deterministyczności; raporty kinematyczne zawierają odcisk plików wejściowych. Tak można sprawdzić, miesiące później, czy cytowana liczba nadal jest aktualna.
Audio oznacza nagrywanie pomieszczenia: Mikrofon na robocie słyszy wszystko, co dzieje się wokół, nie tylko wydawane polecenie. Zasada, którą zastosowalibyśmy, jest taka, że ciągłe nagrywanie nie istnieje domyślnie, lecz tylko okno potrzebne do decyzji, a to, co jest zachowywane do ulepszania, ma być wyraźnym wyborem, z terminem. Nie mamy jeszcze zbudowanego takiego systemu, więc to deklarowane stanowisko, a nie wykazana praktyka.
Modele i opisy robota mają swoje licencje: Modele robotów, których używamy w symulacji, pochodzą z publicznych kolekcji, na licencjach permisywnych, a opisy robotów przemysłowych są publicznymi plikami producentów. Nie są nasze i nie rościmy do nich praw; w Twoim projekcie licencja każdego zewnętrznego źródła jest sprawdzana przed wejściem do produktu końcowego.

Przykład

Własny pomiar akustyczny, który zakończył się „nie”, i dlaczego go publikujemy

Sytuacja

W jednej własnej aplikacji na macOS chciałyśmy/chcieliśmy sprawdzić, czy głośnik i mikrofon urządzenia konsumenckiego mogą służyć jako prosty sonar — wysłany sygnał, zmierzony jego echo, wyprowadzona odległość. To dokładnie to samo pytanie pojawia się też przy robocie: ile można dowiedzieć się o przestrzeni wokół, używając już posiadanego sprzętu audio, bez dodatkowych czujników.

Co zbudowaliśmy

Zbudowaliśmy pełny łańcuch, nie szkic: sygnał przemiatający o długości 12 milisekund, rosnący od 2 do 8 kilohertzów, okienkowany, wysyłany przy małej amplitudzie; korelacja krzyżowa między sygnałem wysłanym i zarejestrowanym; wykrywanie nadejścia bezpośredniego z oknem ochronnym 1,5 milisekundy, aby boczne płaty autokorelacji nie zostały wzięte za echo; wyszukiwanie echa w oknie do 60 milisekund, z osobnymi progami korelacji i względnego wzmocnienia; prędkość dźwięku skorygowana o temperaturę powietrza. Prawie 800 linii Swift, z wykrywaniem toru audio — jeśli nadajnik i odbiornik są na różnych urządzeniach, geometria jest bistatyczna i jeden czas opóźnienia definiuje elipsę, a nie punkt.

Co z tego wyszło

Wniosek jest zapisany w aplikacji, na ekranie mówiącym, co może, a czego nie może mierzyć: na głośniku i mikrofonie tego samego komputera można wykrywać zgrubne zmiany odbić po kalibracji, ponieważ opóźnienie jest względnie stabilne. Jednak przez bezprzewodowe słuchawki aktywna redukcja szumów, formowanie wiązki, kodek i zmienne opóźnienie niszczą precyzyjny pomiar metryczny — więc mogą być używane do orientacji głowy, ale nie jako precyzyjny sonar. Napisałyśmy/napisałem to w produkcie, nie w notatce wewnętrznej.

Czego nie mówi ten przypadek

Wynik dotyczy sprzętu konsumenckiego przez łącze bezprzewodowe, a nie robota z zamontowanymi i podłączonymi mikrofonami. Przenosi się nie wniosek, lecz metoda: kanał mierzy się przed obietnicą funkcji. Dla robota to samo badanie zaczęłoby się od własnego szumu maszyny w ruchu — i dopiero wynik tego pomiaru powiedziałby, co jest możliwe.

Pytania

O co pytają ludzie, zanim zadzwonią

Czy kiedykolwiek uruchamialiście Wasze oprogramowanie na fizycznym robocie?

Nie. Żaden z naszych kodów nigdy nie sterował prawdziwym silnikiem, a dwa nasze codebase’y deklarują to nawet w nagłówku pliku, żeby nie dało się tego odczytać błędnie. To, co uruchamiałyśmy/uruchamialiśmy, to symulacja i weryfikacja offline. Jeśli to jest problem dla Twojego projektu, lepiej wiedzieć o tym od pierwszego zdania niż odkryć to na trzecim spotkaniu.

To co konkretnie macie?

Trzy rzeczy, wszystkie uruchamialne przed Tobą. Moduł kinematyki dla ramienia o sześciu osiach, który zweryfikował trajektorię 8.400 punktów bez żadnej awarii, z minimalnym marginesem 19,9° względem granic osi. Walidator fizyki na MuJoCo 3.10.0, z 34 przechodzącymi testami i z deterministycznością potwierdzoną identycznymi odciskami przy powtórnych uruchomieniach. I demonstrator w przeglądarce z 14 testami, którego bramka kwalifikacyjna dziś celowo pada. Do tego prototyp widzenia, o którym otwarcie mówimy, że ma jeden commit i nie ma żadnego testu.

Pracujecie z ROS?

Nie. Nie jest u nas zainstalowany, nie napisałyśmy/napisałem żadnego noda, żadnego pliku startowego ani żadnego pakietu. Jedyny pakiet typu ROS na naszych dyskach to publiczny opis robota przemysłowego, pobrany jako plik modelu do obliczeń kinematycznych — użyty jako dane, nie zbudowany. Jeśli Twój zespół pracuje już w ROS 2 i to jest wymaganie, my zaczynamy tam od zera i trzeba to uwzględnić.

Czy możecie zrobić moduł widzenia dla naszego robota?

Z etapem pomiaru wcześniej, nie na podstawie prototypu, który mamy. To, co można z niego przenieść, to sposób pracy — detektor, śledzenie między klatkami, próg zaufania, gdzie działa obliczenie. To, czego nie można przenieść, to sytuacja: kamera na robocie się porusza, obiekt jest blisko, światło zmienia się z każdym krokiem, a wynik musi prowadzić do decyzji ruchu, a nie do ekranu. Ponadto nie mamy kamery głębi, kalibracji kamery ani odometrii wizualnej w żadnym własnym projekcie. Pierwszym etapem byłby zapis z Twojego środowiska i pomiar referencyjny.

Macie agenty głosowe. Czy to nie to samo co słuchanie robota?

Nie i nie chcemy, żeby tak to wyglądało. Przez telefon kanał jest znany i wąski, osoba mówiąca jest blisko mikrofonu, a przerwanie wypowiedzi rozwiązuje albo usługa dostawcy, albo naciśnięty klawisz. Na robocie mikrofon znajduje się na maszynie, która sama robi hałas dokładnie wtedy, gdy się porusza, głos dochodzi z kierunku, który się zmienia, pomieszczenie tworzy echo, a odległość się waha. To problemy akustyczne, nie konwersacyjne. Moglibyśmy zacząć od pomiaru własnego szumu Twojego robota — ale byłaby to nowa praca, a nie rozszerzenie tej telefonicznej.

Dlaczego publikujecie bramkę kwalifikacyjną, która nie przechodzi?

Bo alternatywą jest to, że przejdzie, nic nie znacząc. Nasza bramka czyta plik dowodowy i sprawdza, czy krytyczna stała — czas zatrzymania na końcu zakresu ruchu przegubu — została skalibrowana na sprzęcie. Nie została: to prowizoryczna wartość 5 milisekund, ustawiona po to, żeby istniała stabilna symulacja. Dopóki jest prowizoryczna, pełna weryfikacja kończy się błędem, a wszystkie akcje pozostają oznaczone jako kinematyczne. Dzień, w którym przejdzie, będzie coś znaczył właśnie dlatego, że dziś nie przechodzi.

Czego nie dowodzą Wasze symulacje?

Bardziej tego, czego nie dowodzą, i jest to zapisane w raportach. Walidator fizyki potwierdza swobodny spadek i utrzymanie pozycji na planie testowym — nie chód, nie złożony kontakt, nie dynamikę siłownika, nie syntetyczne czujniki. Screening trajektorii potwierdza kinematykę i geometrię — nie materiał, nie elastyczne przewody, nie opóźnienia procesu, nie rampy start-stop sterownika. A ruch w przeglądarce to podgląd, nie wynik symulacji.

Potrzebujemy certyfikacji bezpieczeństwa. Czy to robicie?

Nie. Architektury bezpieczeństwa możemy zaprojektować — osobny obwód od sterowania ruchem, niezależny sterownik bezpieczeństwa, bezpieczne wyłączenie momentu, hamulce z feedbackiem, stany awarii przechodzące w tryb bezpieczny; to też zrobiliśmy w jednym własnym projekcie maszyny. Ale ocena zgodności i odpowiedzialność za maszynę wprowadzoną na rynek pozostają po stronie producenta albo integratora. Nie przyjmujemy tej roli i nie podpisujemy za nikogo.

Dlaczego na tej stronie jest napisane „oferta”?

Bo usługa ma trzy warstwy i żadna z nich nie przekracza w pełni progu, który sobie postawiliśmy. W sterowaniu mamy dwa własne projekty z przechodzącymi testami, ale żaden nie sięga sprzętu. W wizji mamy prototyp z jednym commitem i bez testów. W audio dla robotów mamy zero. Moglibyśmy napisać stronę brzmiącą jak doświadczenie, używając słów takich jak „percepcja” i „sterowanie” bez liczb. Wytrzymałaby do pierwszego pytania inżyniera.

Na czym opierają się powyższe stwierdzenia (17 źródeł)

`vision.megapromoting.com` nie jest systemem wizyjnymhttps://vision.megapromoting.com · 2026-09-06

16 z nich to kod i pliki z naszych repozytoriów. Nie publikujemy ich nazw ani numerów linii: razem, na jednej stronie, opisałoby to zbyt dokładnie, jak zbudowane są systemy, które nie należą tylko do nas. Przechodzimy je razem z Tobą, w repozytorium, na życzenie — weryfikacja pozostaje możliwa, tylko odbywa się w rozmowie.

Jak pracujemy Wszystkie usługi

Co chcesz, żeby działało lepiej?

Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.

Porozmawiajmy