Log sesji

Zasady:

Kazda sesja dopisuje swoj wpis na KONCU tego pliku (nowe u dolu).
Nie edytuj cudzych wpisow - jesli cos jest nieaktualne, dopisz nowy wpis, ktory to prostuje.
Stan biezacy projektu (co dziala, co jest w toku) jest w docs/STATUS.md, NIE tutaj - ten plik to tylko historia.
Sprzet dotkniety fizycznie w danej sesji odnotuj w polu "Sprzet" ponizej.

Szablon nowego wpisu:

## RRRR-MM-DD - <kto> - <temat w 5 slowach>
**Zrobione:** ...
**Nie dziala / otwarte:** ...
**Nastepny krok:** ...
**Sprzet:** dotkniety / nie

Log sesji

2026-09-25 - sesja Claude (hoverboard control panel)

Setup od zera: makarena.py (gamepad) -> keyboard_control.py (WASD, bo brak pada) -> web_control.py + frontend.html (pelny panel webowy, bo terminal byl niewygodny).
Napisany xiao_send_pwm.ino od zera (generyczny H-bridge PWM+DIR, roznicowy mix speed+steer, watchdog).
Dodane tryby auto: "osemka" (figure-eight) i "pokrycie" (boustrophedon/lawnmower - jedzie rzad, obraca sie ~180 st w miejscu w dwoch krokach, jedzie rzad wstecz, powtarza).
Dodany modul nagrywania/odtwarzania sekwencji ruchow (zapis do recordings/*.json, przetrwa restart serwera).
Wszystkie parametry (predkosci, czasy, sila skretu) dostrajalne na zywo suwakami w przegladarce, bez edycji kodu.
Naprawione po drodze: skalowanie limitu predkosci nie obejmowalo steer w manualu; race condition przy broadcastcie do wielu klientow; DOM re-render 30x/s gubil klikniecia na liscie nagran; playback_name nie czyscil sie przy zmianie trybu.
Repo GitHub utworzone (pawel120/hackaton, prywatne), inne sesje dorzucily rownolegle detect_object.py i rozbudowany arm_control.py - scalone w jednym branchu master.
Stan na koniec sesji: panel webowy dziala end-to-end (potwierdzone fizycznym ruchem robota), COM9 bywa niestabilny po odlaczeniu USB.
Nie zrobione / do zrobienia: integracja ramie+kamera+auto w jeden system (wlasnie doszlo Raspberry Pi 5 do tego celu), IK dla SO-101 (ikpy + URDF, niesprawdzone konca), lerobot install na Python 3.14 wymaga obejscia (patrz constraints.txt).

2026-09-25 - sesja Claude (ramie SO-101 + kamera, planowanie pick-and-place)

Dokonczona instalacja lerobot na Python 3.14 (doinstalowane huggingface_hub, feetech-servo-sdk, deepdiff, cachebox); import SO101Follower dziala (nowa sciezka, patrz pulapki).
Wykryte: D415 przez pyrealsense2 OK; ramie na COM10 (CH343).
Pobrany URDF SO-101 z TheRobotStudio/SO-ARM100 do so101_urdf/so101_new_calib.urdf; ikpy go laduje (5 przegubow + gripper_frame_joint jako koncowka, chwytak poza lancuchem IK).
Napisany arm_control.py (CLI + funkcje do importu). Uzytkownik zrobil kalibracje serw, ruch potwierdzony fizycznie (move shoulder_pan=20 -> odczyt 19.38 st). HOME_POSE = poza zaraz po kalibracji.
Dodane komendy demo: straight (wszystko 0 st, chwytak otwarty), gong (powolny zamach + szybkie uderzenie jednym przegubem), dance (losowe ruchy ~90% zakresu, maly krok). Po drodze naprawione zapychanie magistrali (patrz pulapki); retry odczytu pozycji, disconnect nie wywala programu.
Decyzje: kamera stala wzgledem ramienia (eye-to-hand), najpierw na maszcie, potem ustalone: platforma robota 12 cm nad ziemia. Obiekty do podnoszenia nieoznaczone -> detekcja po glebi zamiast po kolorze. Platforma: Raspberry Pi 5 8 GB zamiast Jetson Nano P3450.
Research bibliotek (lerobot + ACT/SmolVLA, ikpy vs roboticstoolbox, mujoco, open3d, ultralytics; co ma wheele pod py3.14 - patrz pulapki). Rekomendacja: klasyczny pipeline (glebia -> kalibracja -> IK) jako glowny, ACT (imitation learning) jako plan B.
GitHub: issue #1 (detekcja + deprojekcja 3D, zrobione przez Tomka w PR #2 jako detect_object.py), issue #4 (detekcja dowolnych obiektow po glebi, open3d, przypisane TomkeMonke).
Plan kalibracji kamera->ramie (marker ArUco na chwytaku, 15-20 poz, Kabsch, cel RMS < 10 mm) jako Claude Doc na 1 strone A4 do zatwierdzenia przez zespol (link w "NASTEPNY KROK").
Nie zrobione: weryfikacja zer/kierunkow przegubow lerobot vs URDF, FK/IK na prawdziwym ramieniu, marker i skrypt kalibracji kamera->ramie, petla pick-and-place, cokolwiek na Pi 5. dance na pelnym zakresie nie bylo sprawdzone do konca po ostatniej poprawce (ostatnie uruchomienie padlo w go_home na zgubionym pakiecie - od tego czasu jest retry, nieprzetestowany). gong i straight nieprzetestowane fizycznie (brak potwierdzenia od uzytkownika).

2026-09-25 - sesja Claude (podglad na zywo RealSense D415)

Cel: prosty live preview (rs_preview.py) color+depth side-by-side z pyrealsense2 + cv2.imshow, do wizualnej kontroli co widzi kamera. RealSense Viewer (osobna appka Intela) NIE jest zainstalowany i nie jest potrzebny - pyrealsense2 ma librealsense wbudowane.
Napisany rs_preview.py: color+depth align, colormapa JET, FPS co 30 klatek w konsoli, wyjscie q/ESC, pipeline.stop() w finally.
Napotkane i naprawione po drodze (patrz pulapki): konflikt opencv-python / opencv-python-headless (reinstall samego opencv-python); D415 znikajaca z enumeracji USB po zombie procesach pythona (taskkill wiszacych python.exe).
Potwierdzone: kamera wykrywana (rs.context().query_devices() -> 1, D415, serial 105422060821), skrypt odpala sie bez wyjatku po posprzataniu procesow.
Nie zrobione / niepotwierdzone: uzytkownik nie potwierdzil jeszcze wizualnie ze okno faktycznie pokazuje obraz (proces dzialal bez crasha, ale brak feedbacku "widze obraz" na koniec sesji) - na starcie nastepnej sesji zapytac czy rs_preview.py faktycznie pokazuje live podglad, czy nadal lapie No device connected po replugu (jesli tak, sprawdzic Menedzer Urzadzen / port USB, moze hub zamiast bezposredniego portu USB3).

2026-09-25 - sesja Claude (Raspberry Pi 5: architektura + setup zdalnego sterowania)

Decyzje: Pi 5 jedzie na robocie, urzadzenia po USB (D415 USB3, ramie CH343, Xiao), operator przez WiFi (panel webowy). Bluetooth odrzucony jako szkielet systemu (za mala przepustowosc dla kamery, za duze opoznienia dla magistrali Feetech). System: Raspberry Pi OS Lite 64-bit na pendrivie USB (brak karty SD), venv z uv + Python 3.12, bez Dockera na start, autostart przez systemd, hotspot WiFi z Pi na demo.
Poradnik setupu Pi (Claude Doc): https://claude.ai/code/artifact/247e71b9-5b39-4ffb-8170-e355db9fd56b (instalacja, lerobot, RealSense ze zrodel jesli brak wheela, udev /dev/robot-arm i /dev/robot-drive, systemd, hotspot, checklista, diagnostyka). IMU BNO085 bylo w planie, ale odpadlo.
Kod: porty ze zmiennych ROBOT_DRIVE_PORT / ROBOT_ARM_PORT (domyslnie COM9 / COM10, Windows bez zmian); web_control.py nasluchuje na 0.0.0.0 (ROBOT_HOST); failsafe operatora: brak wiadomosci z przegladarki przez 0,5 s (albo zero klientow) = natychmiastowy stop, tryb manual, koniec nagrywania/odtwarzania. Frontend wysyla ping co 200 ms i puszcza klawisze przy visibilitychange. Nowy requirements-pi.txt (NIE uzywac constraints.txt na Pi).
Failsafe sprawdzony lokalnie klientem websockets bez Xiao (ping -> jedzie, brak pingu -> failsafe=True, speed 0, manual). Nie sprawdzony na fizycznym robocie.
GitHub: issue #7 (mapowanie ogrodu RealSense/RTAB-Map, odlozone, najpierw test na laptopie), issue #8 (zasilanie z akumulatora 12 V, osoba od elektroniki; baterie AA 1,5 V nie nadaja sie do zasilania Pi).
Stan na koniec: pendrive Kingston DataTraveler 3.0 64 GB gotowy do wgrania systemu Imagerem. Na Pi nic jeszcze nie jest zainstalowane.
Pulapka: przed failsafe'em zerwanie WiFi zostawialo robota jadacego z ostatnia komenda (watchdog Xiao chroni tylko lacze Pi-Xiao, nie operator-Pi). Tryby auto tez jechaly bez operatora.

2026-09-25 - sesja Claude (Tomek: wykrywanie szyszek po glebi + dystans, dojazd, plan chwytu)

Zamkniecie issue #4 i zbudowanie calego lancucha od kamery do katow przegubow. Cztery PR-y z forka TomkeMonke/hackaton (brak uprawnien do pushu na pawel120/hackaton): #5 wizja, #9 platforma, #10 ramie, #11 ten wpis.

Zrobione:

detect_floor_objects.py - detekcja DOWOLNYCH obiektow po glebi: RANSAC plaszczyzny ziemi (+ douczenie SVD na inlierach), maska tego co nad nia wystaje, cv2.connectedComponentsWithStats zamiast DBSCAN. Swiadomie bez open3d: glebia z D415 jest ZORGANIZOWANA (to obraz, sasiedztwo pikseli juz jest sasiedztwem w przestrzeni), wiec etykietowanie spojnych obszarow kosztuje ulamek ms, a DBSCAN po ~300 tys. luznych punktow setki ms na klatke. Zmierzone 22.2 fps end to end. Zero nowych zaleznosci.
Preset szyszka - bramka wymiarowa nastrojona na ZMIERZONYCH szyszkach na waszej murawie (nie na wymiarach z ksiazki): 0.5-6 cm szerokosci, 2-10 cm dlugosci, 0.8-9 cm nad ziemia, wypelnienie >= 0.4. Kolorem sie ich nie wylowi - patrz pulapki.
Wyniki w ukladzie ROBOTA, nie kamery: forward_m, lateral_m, ground_distance_m, bearing_deg, wyprowadzone z dopasowanej plaszczyzny, wiec krzywo przykrecony uchwyt kompensuje sie sam.
scan_cones.py - skan na POSTOJU: mediana z N klatek + rozrzut w mm. Zapisuje cel.json. Na torze: 5 szyszek, kazda widziana w 15/15 klatkach, rozrzut 0.0-1.4 mm.
drive_to_target.py + approach_and_grasp.py - dojazd i plan chwytu, oba czytaja cel.json. Szczegoly w #9 i #10.
Testy bez sprzetu: test_detect_gates.py, test_drive_plan.py, test_grasp_plan.py - razem 28, zwykly python, bez pytest.

Decyzje:

Postoj-skan-zapamietaj-jedz, nie ciagle sledzenie. Wymusza to martwa strefa 0.27 m (patrz pulapki) - przy chwytaniu szyszki nie widac.
Zasieg skanu 0.3-1.0 m (ustalony z zespolem). Zmierzone: na 1.06 m rozrzut to nadal ~1 mm, wiec podniesienie do 1.2-1.5 m jest bezpieczne.
Detekcja po GLEBI jako podstawowa, kolor jako opcja (--mode depth|color|both). Uzasadnienie w pulapkach.
Wykrycia migoczace sa odrzucane: skan zglasza tylko cele widziane w

=60% klatek. Dlatego podglad na zywo pokazuje wiecej niz skan.

NIE dokonczone / swiadomie odlozone:

Nic nie sprawdzone na sprzecie poza kamera. Ani ramie, ani platforma nie byly podlaczone (zero portow COM na tej maszynie). Dojazd i chwyt sa przetestowane wylacznie w dry-run.
Kalibracja kamera->baza ramienia - approach_and_grasp.py uzywa OSZACOWANIA z montazu. To wasz osobny task (plan w Claude Doc).
Stale kalibracji jazdy niezmierzone - drive_to_target.py ODMAWIA jazdy, dopoki ktos ich nie zmierzy przez --calibrate.
Znaki/offsety przegubow lerobota niesprawdzone - przy zlym znaku plan czyta sie bez zarzutu i wysyla ramie w druga strone.
Odlozone na zyczenie zespolu: inne obiekty na torze (liscie, patyki), detekcja w trakcie jazdy, zasieg powyzej 1 m.
Szyszka przy lewej krawedzi kadru nie jest wykrywana - patrz pulapki, to ograniczenie stereo, nie progow.

2026-09-25 - sesja Claude (Pi 5: pierwsze uruchomienie calosci + proby chwytu)

Stos na Pi (venv .venv, Python 3.12) - co i jak zainstalowane:

torch CPU-only z --index-url https://download.pytorch.org/whl/cpu (zwykly torch z PyPI na aarch64 ciagnie ~2 GB paczek CUDA i pada na timeoucie - Pi nie ma GPU NVIDIA).
lerobot==0.6.1 z --no-deps, potem recznie: draccus mergedeep typing_inspect mypy_extensions tqdm huggingface_hub feetech-servo-sdk deepdiff cachebox orderly-set flit_core. Czesc offline: pip download na Windows (--platform manylinux2014_aarch64 --python-version 312 --implementation cp --abi cp312 --only-binary=:all: dla binarnych, sdist dla czystego Pythona), scp na Pi, uv pip install --no-deps --no-build-isolation <plik>.
pyrealsense2 - jest gotowy wheel arm64, budowa ze zrodel NIEPOTRZEBNA.
ikpy, opencv-python-headless, pyserial, websockets, scipy.

Nowe pliki: arm.sh (skrot do arm_control.py na Pi), rs_mjpeg_server.py (podglad kamery w przegladarce, Pi jest headless), rs_snapshot.py, drive_step.py (krok kolami surowym protokolem Xiao, omija drive_to_target.py), auto_collect.py (petla skan->krok->skan-> chwyt), record_demo.py / replay_demo.py / demo.csv (nagranie i odtworzenie recznego chwytu).

Zmiany: nowa kalibracja serw; HOME_POSE = pozycja spoczynkowa po tej kalibracji (ta sama w approach_and_grasp.START_POSE_DEG); approach_and_grasp.execute_plan wysyla bezposrednie komendy (max_relative_target=None, bez interpolacji, do 3 powtorek na krok).

ZAMIANA ID SERW - BLEDNA DIAGNOZA (sprostowane w nastepnej sesji): uznalismy, ze id=2 to lokiec, a id=3 bark, i zamienilismy wpisy shoulder_lift/elbow_flex w pliku kalibracji na Pi. lerobot ignoruje jednak pole id z pliku (nazwy->ID sa na sztywno w so_follower.py), wiec zamienily sie tylko offsety/zakresy miedzy przegubami - stad dalej "zly kierunek". Patrz wpis "Replay chwytu + naprawa kalibracji barku".

Nie zrobione: chwyt po poprawce ID; potwierdzenie wzrokowe zamiany; kalibracja kamera->ramie; internet na Pi; teleop_mirror.py (nie z tej sesji) - niezacommitowany, lezy lokalnie.

Pulapki z tej sesji:

Nie wyciagac pendrive'a z dzialajacego Pi - to dysk systemowy; SSH umiera ("kex_exchange_identification"), siec jeszcze odpowiada.
Pi 5 + D415 na slabym zasilaniu znika z sieci; na powerbanku dziala.
Siec hacker-bloc ma tylko IPv6, GitHub tylko IPv4 -> ani git pull, ani ICS dla Pi. Hotspot telefonu daje IPv4.
pkill -f nazwa przez SSH zabija sam siebie, gdy nazwa jest w tresci komendy (exit 255). Uzyj fuser -k 8080/tcp albo PID.
Interpolowane ruchy (move_to steps>1) zapychaja magistrale ("There is no status packet!") przy duzych katach - bezposrednie send_action z max_relative_target=None + powtorki sa niezawodne.
~~Ostrzezenia "clamped" z katami zmieniajacymi znak przy +-180 st to zawijanie reprezentacji, nie zly kierunek.~~ BLAD: to byl objaw zakresu barku przechodzacego przez zero enkodera (patrz nastepna sesja).
Kazde connect() na chwile wylacza torque (configure()) - ramie moze opasc pod grawitacja miedzy wywolaniami. Rob sekwencje w jednym polaczeniu.
scan_cones.py bez szyszki nadpisuje cel.json pusta lista - zapisz dobry skan zanim podjedziesz w martwa strefe.
cel.json pole angle_deg to obrot chwytaka, kierunek do celu to bearing_deg.
drive_to_target.py na Pi nie dziala: wymaga pakietu makarena spoza repo (sciezka C:\Users\Modern 14\makarena) i odmawia jazdy bez zmierzonej kalibracji. Zamiast niego drive_step.py.

2026-09-25 - Replay chwytu + naprawa kalibracji barku

Co bylo zle: kazda proba (home, replay_demo, IK) jechala barkiem w zla strone. Dwie przyczyny naraz:

lerobot adresuje serwa po nazwie ze sztywnej listy (lerobot/robots/so_follower/so_follower.py: shoulder_lift=id2, elbow_flex=id3). Pole "id" w so101.json jest IGNOROWANE. "Zamiana ID" z poprzedniej sesji zamienila tylko offsety/zakresy -> kazdy z dwoch przegubow byl normalizowany zakresem drugiego. Nie naprawiac mapowania przez edycje JSON-a.
Fizyczny zakres id2 (shoulder_lift) przechodzil przez zero enkodera (Present 4095->0). Serwo w trybie pozycji nie przejdzie przez 0, wiec do celu po drugiej stronie jechalo "naokolo", w podloge. Widac to w nagraniu: opadajacy bark -82 -> -151 -> +139 -> 128.

Naprawa (bez recznej kalibracji, policzone z nagrania demo2.csv): fix_shoulder_offset.py - id2: Homing_Offset 1977 (== -2119, przesuniecie +1418 tickow), limity 1006..3089 (srodek ~2047, bez przejscia przez zero); id3: przywrocone rejestry sprzed sesji (1159, 1168..3423). Zapisane w EEPROM serw i w so101.json na Pi. Tworzy tez demo2_fixed.csv (nagranie przeliczone do nowej kalibracji).

Nowe pliki: replay_csv.py (odtwarza cala trajektorie z CSV klatka po klatce w tempie nagrania - male kroki, bez interpolacji miedzy dalekimi punktami), fix_shoulder_offset.py, demo2.csv / demo2_fixed.csv. HOME_POSE / START_POSE_DEG = pierwsza klatka demo2_fixed.csv. replay_demo.py + demo.csv oznaczone jako nieaktualne.

Wynik: replay_csv.py demo2_fixed.csv --start 9.5 --end 23 przeszedl cala trajektorie, koniec w pozycji z nagrania (+-1 st), bez bledow magistrali.

Pulapki:

record_demo.py najpierw wysyla home - przy zlej kalibracji home nie dojezdza i nagranie startuje z innej pozy (tak bylo z demo2.csv, pierwsze ~4 s to opadanie ramienia; replay od --start 9.5).
Przed zmiana rejestrow: bus.disable_torque() (zdejmuje tez Lock), inaczej zapis EEPROM nie wejdzie.
Homing_Offset na Feetech ma zakres +-2047 - wieksze przesuniecia licz modulo 4096.

2026-09-25 - Chwyt z kamera: skan -> podjazd -> replay (nieudany, 5 prob)

Pomysl: bez IK. Jedyny pewny chwyt to nagranie demo2_fixed.csv (klatka chwytu t=14.8 s: pan -13.6, bark 86.3, lokiec -3.6, nadgarstek 53.8, chwytak otwarty 45). Kamera mierzy szyszke, robot podjezdza tak, zeby szyszka znalazla sie w punkcie chwytu, a roznice w bok nadrabia obrot podstawy (replay_csv.py --pan-offset).

Ustalenia (zmierzone):

Punkt zamkniecia szczek jest 17 cm przed kamera (suwmiarka, uzytkownik). Kamera widzi glebie dopiero od ~0.31 m, wiec szyszka w chwili chwytu jest ZAWSZE w martwej strefie - ostatni odcinek jedzie sie na slepo. Punktu chwytu nie da sie tez zobaczyc "na zywo": przy pozie chwytu ramie zaslania kamere (przedramie ~0.31 m przed obiektywem).
Szyszke widac na RGB, zanim zlapie ja glebia (np. na ~0.3 m jest wyraznie w kadrze, a detektor glebi nic nie zglasza). Rozwiazanie uzytkownika: cofac, az glebia ja zmierzy, potem podjechac.
Krok kol drive_step.py --speed 150 jest nieliniowy: 0.05 s (jeden tick 80 ms) ~ 2.9 cm do przodu; 0.1 s ~ 12.5 cm (jeden pomiar!); do tylu 0.05 s dawalo od 0.4 cm do kilku cm. Przy jezdzie lekko znosi w bok (raz 1.8 cm na jednym kroku).
scan_cones.py lapie tez buty/fotel - w petlach filtr forward < 0.8 m i |lateral| < 0.15 m.

Model obrotu podstawy (niezweryfikowany): pan = atan(lateral / 0.25 m) (17 cm od kamery + ~8 cm kamera->os podstawy), ujemny pan = w lewo; --pan-offset = pan - (-13.6).

Proby (wszystkie: chwytak wrocil pusty, odczyt ~2):

#	szyszka przed chwytem	pan	co widzial uzytkownik
1	0.322 m, 1.9 cm L (bez podjazdu)	-9.9	zahaczyl, przeciagnal
2	0.306 m, 0.9 cm L (bez podjazdu)	-5.4	chwytak zamykal sie PRZED szyszka
3	0.306 m, 0.9 cm L (bez podjazdu)	-11.4	j.w.
4	0.310 m -> 5x0.05 s (~14.5 cm)	-2.7	brak informacji
5	0.542 -> 0.417 (zmierz.) -> 2x0.1 s na slepo	0.0	brak informacji

Proby 1-3 byly oparte na zlej kotwicy (0.30 m, zgadnieta ze zdjecia); dopiero pomiar suwmiarka dal 17 cm.

Zmiany w kodzie: replay_csv.py ma --pause-at/--pause (zatrzymanie w wybranej klatce z trzymanym torque) i --pan-offset (obrot calego ruchu w bok).

2026-09-25 - Mapa RTAB-Map z nagrania pokoju (issue #7, sesja Claude na laptopie)

Wejscie: D:\HACKATHON\20260925_190138.db3 (4.7 GB) - rosbag2 z RealSense D415, 1280x720 @30, 98.4 s, nagrane z reki (losowe chodzenie po sali, ~0.9 m nad podloga). Bez IMU i bez odometrii kol.

Wynik: D:\HACKATHON\20260925_190138_rtabmap\wynik\ - mapa_rtabmap.db, chmura_punktow.ply (820 tys. pkt, voxel 1 cm), trajektoria.txt, podglad.png. W jednej spojnej mapie jest 50 z 93 wezlow (54% nagrania) - poczatek i koniec. Srodek (wezly 779-1648) to 4 osobne kawalki bez wizualnego pokrycia z reszta; detectMoreLoopClosures sprawdzil wszystkie pary i nic nie znalazl. Przyczyna w nagraniu: dziury 1.2-1.6 s bez klatek (t = 62, 74, 85 s), szybkie obroty przy bluszczu, ta czesc sali obejrzana raz. Na podgladzie widac podwojne sciany - resztkowe niedopasowanie miedzy sklejonymi sesjami.

Pipeline (bez ROS, bez GUI): bag_to_rtabmap.py -> 1897 par RGB-D -> rtabmap-dataRecorder (ini ze zrodlem "RGB-D images") -> rtabmap-reprocess -odom -> rtabmap-detectMoreLoopClosures -> rtabmap-export. Calosc w run_rtabmap.cmd w katalogu wyniku, ~20 min. RTAB-Map portable w D:\HACKATHON\tools\bin.

Strojenie odometrii (zmierzone):

konfiguracja	zgubione klatki	sesje	najwiekszy sklejony kawalek
domyslna (ResetCountdown 0)	od kl. 439 do konca	1	~23% nagrania
ResetCountdown 1, MinInliers 12	59	22	2 pozy
+ CorType 1 (KLT), MaxFeatures 2000	13	8	50/93 wezlow <- wybrana
j.w. + ResetCountdown 15	81	6	37/87 wezlow

Nie zrobione: mesh z tekstura, mapa 2D zajetosci (rtabmap-export jej nie ma - do zrobienia w GUI RTABMap.exe -> Export 2D map albo z chmury), nagranie na robocie zamiast z reki.

Nastepny krok dla mapowania: nagrac jeszcze raz, wolno (obroty szczegolnie), z powrotem do miejsca startu na koncu (loop closure skleja cala petle) i sprawdzic, czy nagranie nie gubi klatek (zapis na SSD). Pipeline jest gotowy: python bag_to_rtabmap.py NOWE.db3, potem run_rtabmap.cmd z poprawionymi sciezkami w rtabmap_source.ini.

2026-09-26 - pinecone_bot: deterministyczny stos (PR #14) + poprawki z issue #15

Sesja Claude na laptopie (Windows, bez sprzetu). Nowy stos w pinecone_bot/, opis i poradnik w PINECONE_README.md, wpis w "Struktura repo" wyzej.

Zalozenie: poprzednie podejscie (IK z niezmierzona transformacja kamera-ramie, slepy podjazd z czasu) chybialo systematycznie. Zamiast poprawiac teorie: ramie odtwarza nagrany chwyt w stalym miejscu, a baza ustawia szyszke w tym miejscu z obrazu (obrot az szyszka w kolumnie cfg.cx, jazda az w wierszu target_row). Wymaga przestawienia kamery tak, by widziala miejsce chwytu (dzis 17 cm przed kamera = martwa strefa).

Zrobione (bez sprzetu):

Symulator (kamera pinhole + naped roznicowy) i pelna petla sterowania; na 10 losowych ukladach 5 szyszek: pole 2.2 m -> 48/50, pole 3.0 m -> 44/50 (braki w rogach, pasy liczone z czasu bez odometrii).
Bledy sterowania zlapane w symulacji i naprawione: skrawek szyszki na krawedzi obrazu wciagal w petle SEARCH/APPROACH (teraz detekcja "czesciowa", uzywana tylko do kierunku); przestrzal po utracie celu (obrot trzymany 0.25 s, potem pelzanie do przodu); przelaczanie celu miedzy dwiema szyszkami w tej samej odleglosci (sledzenie celu).
Sterowniki bazy: Xiao (a<speed> b<steer>) i bipropellant po UART (SPEED_DATA 0x03, hall 0x02 -> odometria). Ramie: punkty nad arm_control.py + fallback na skrypt zespolu.
Poprawki z review PR #14 (issue #15): brakujace ruchy near/far pomijane zamiast FileNotFoundError (config ma tylko grasp_mid, dopoki nie nagrane); po pustym chwycie ramie wraca do home; _last_cmd scalany; reset licznika prob po zgubieniu szyszki; _last_seen odswiezany po chwycie; blokada zapisu na porcie w BipropellantBase; zacisk trzymany do konca nagrania; deploy: --delete, wlasciwe requirements; polskie teksty w frontend.html przywrocone (reszta repo zostaje ASCII).

Do zweryfikowania na sprzecie (rano): znak skretu Xiao i mapowanie PWM -> m/s, prog "pusty chwytak" (empty_gripper_below, grasp_mid schodzi do ~0.5 przy pustym), kolejnosc kol i znak halla w bipropellancie, wersja protokolu (COBS czy stare ramki) - test unlockASCII po UART.

2026-09-25 - stan na koniec sesji (dawny NASTEPNY KROK)

Ramie odtwarza recznie nagrany chwyt szyszki (replay_csv.py demo2_fixed.csv) bez jazdy "naokolo". Przyczyna wczesniejszych porazek znaleziona i naprawiona (patrz wpis sesji na dole) - teza "ID serw sa zamienione" z poprzedniej sesji byla BLEDNA.

Najwazniejsze na start nastepnej sesji (w tej kolejnosci): 0. Nowy stos pinecone_bot (PR #14, poprawki z issue #15) - zamiast IK i slepego podjazdu: nagrany chwyt + baza ustawia szyszke z obrazu. Kolejnosc na Pi jest w PINECONE_README.md ("Na Raspberry Pi, w tej kolejnosci"): przestawic kamere wyzej i za ramie, tools/snap_frames.py, tools/calibrate_hsv.py, tools/record_waypoints.py (grasp_near/far, drop_box; grasp_mid jest z demo2_fixed.csv), tools/calibrate_target.py, tools/base_test.py (znak skretu, mapowanie PWM), --dry-run, --real. Punkty 2-4 ponizej dotycza starego podejscia i sa opcjonalne.

./arm.sh home - HOME_POSE przepisany pod nowa kalibracje (ramie zlozone, bark -85 st, lokiec 99 st).
Chwyt z kamera jeszcze NIE trafil (5 prob, patrz wpis "Chwyt z kamera: skan -> podjazd -> replay" na dole). Procedura jest gotowa, brakuje dokladnosci podjazdu na slepo i potwierdzenia, gdzie chwytak laduje w bok. Nastepna proba: w pauzie (--pause-at 14.8 --pause 10) zmierzyc suwmiarka, gdzie sa szczeki wzgledem szyszki (przod/tyl, lewo/prawo), i z tego poprawic kotwice (17 cm) oraz znak/skale obrotu podstawy.
Skalibrowac krok kol: drive_step.py jest mocno nieliniowy (nizej). Najlepiej zmierzyc kamera kilka krokow 0.1 s na szyszce 0.4-0.6 m.
IK (approach_and_grasp.py): zera barku/lokcia po nowej kalibracji NIE sa sprawdzone wzgledem zer URDF.
Internet na Pi (patrz "Jak sie polaczyc") - bez niego git pull na Pi nie dziala, pliki ida przez scp.

NIE uruchamiac lerobot calibrate - nadpisze recznie poprawiony offset barku (id2) i zakres znow przejdzie przez zero enkodera. Backup pliku sprzed poprawki: ~/so101.json.bak-204746 na Pi.

Jak sie polaczyc z Pi (stan na koniec sesji)

Kabel ethernet laptop<->Pi (adapter USB-Ethernet w laptopie). Pi ma statyczne IP 192.168.137.5 (ustawione przez nmcli na "Wired connection 1"), laptop 192.168.137.1 (Windows ICS).
ssh robot@192.168.137.5 - user robot, haslo znasz. robot.local (mDNS) dziala z git-bash, ale NIE z PowerShell - w PowerShell uzywaj IP.
Terminale uzytkownika na Windows dzialaja jako konto slawe, narzedzia Claude jako pawel - dlatego klucz SSH dziala u Claude'a, a u ciebie pyta o haslo. Nie ruszac ACL ~/.ssh/id_ed25519 (icacls je psulo).
Pliki z laptopa na Pi: scp plik.py robot@192.168.137.5:~/hackaton/ (w PowerShell na laptopie, NIE w sesji SSH).
WiFi Pi: NIE dziala (handshake WPA do hotspotu iPhone pada). Profile WiFi usuniete. Pi nie ma internetu.

Jak odpalac (w sesji SSH na Pi)

cd ~/hackaton && source .venv/bin/activate
./arm.sh status | home | straight | open | close | move shoulder_pan=10
python rs_mjpeg_server.py          # podglad na zywo: http://192.168.137.5:8080/ (Ctrl+C = stop)
python scan_cones.py --json cel.json
python approach_and_grasp.py --no-drive                       # dry-run planu
python approach_and_grasp.py --no-drive --port /dev/robot-arm # NA ZYWO
python drive_step.py --port /dev/robot-drive --speed 150 --duration 0.05   # jeden krok kolami
python auto_collect.py --drive-port /dev/robot-drive --arm-port /dev/robot-arm --dry-run
python record_demo.py --seconds 25 --out demo.csv   # nagranie recznego ruchu (torque off)
python replay_demo.py --port /dev/robot-arm [--dry-run]

Kamera na wylacznosc: zatrzymaj rs_mjpeg_server.py przed skanem. Porty: /dev/robot-arm (ramie), /dev/robot-drive (Xiao), udev dziala.

2026-09-25 - poprzedni NASTEPNY KROK (sesja detekcja + dystans)

Cel ogolny: pick-and-place dowolnych, nieoznaczonych obiektow z podlogi ramieniem SO-101, z kamera D415 na platformie robota, docelowo wszystko na Raspberry Pi 5 (8 GB) zamiast Windows PC.

Stan:

Ramie: skalibrowane (serwa), sterowanie dziala fizycznie (arm_control.py: status/move/home/straight/open/close/gong/dance).
Wizja: DZIALA i jest zmierzona. detect_floor_objects.py + scan_cones.py wykrywaja szyszki po glebi i podaja dystans w ukladzie robota (do przodu / w bok / kat). Na torze: 5 szyszek, rozrzut 0.0-1.4 mm przy 15-20 klatkach. Issue #4 zamkniete przez PR #5. detect_object.py (HSV) zostal, ale do szyszek nie nadaje sie - brazu w obrazie nie ma, patrz pulapki.
Dojazd i chwyt: kod gotowy, ZERO testow na sprzecie. drive_to_target.py (PR #9) i approach_and_grasp.py (PR #10) czytaja cel.json z wizji. Oba maja dry-run jako domyslny i odmawiaja ruchu bez jawnego portu. Ani ramie, ani platforma nie byly podlaczone przy ich pisaniu.
Kalibracja kamera->ramie: nadal tylko PLAN (Claude Doc https://claude.ai/code/artifact/44f74190-82ad-4315-a878-07329119a2a7). approach_and_grasp.py uzywa OSZACOWANIA z montazu i mowi o tym przy kazdym uruchomieniu.

Najwazniejsze dalej (w tej kolejnosci):

Zmierzyc stale jazdy: python drive_to_target.py --calibrate, zmierzyc miarka przejazd i obrot, wpisac do drive_calibration.json i ustawic "measured": true. Dopoki tego nie ma, skrypt nie pojedzie do celu. Spodziewany blad dojazdu po kalibracji: 5-8 cm.
Sprawdzic znaki i offsety przegubow lerobota przed PIERWSZYM ruchem ramienia z planu (arm_control.py status w pozie z wypisu, poprawic arm_camera_transform.json). Przy zlym znaku plan czyta sie bez zarzutu i wysyla ramie w druga strone.
Zmierzyc, ile chwytak siega przed obiektyw kamery i ustawic na tej podstawie --standoff - ta sama liczba w drive_to_target.py i approach_and_grasp.py, inaczej plan chwytu opisuje inne miejsce niz to, gdzie stanie platforma. Teraz w obu jest 0.12 m (placeholder).
Kalibracja kamera->baza (Kabsch) - po niej chwyt przestaje byc przyblizeniem.
Pi 5: instalacja stosu, build pyrealsense2 ze zrodel.

Rozwazyc (propozycja z sesji dojazdu, nie decyzja): drugi skan po obrocie, przed jazda. Na 0.5 m kamera jeszcze widzi, wiec korekta kata jest darmowa i zamyka petle tam, gdzie blad open-loop jest najwiekszy.

Pytania do uzytkownika na starcie nastepnej sesji (nie zgaduj):

Czy stale kalibracji jazdy zostaly zmierzone? Jaki wyszedl realny blad dojazdu na 0.5 m?
Ile chwytak siega przed obiektyw kamery (do --standoff)?
Czy zespol zatwierdzil plan kalibracji kamera->ramie? Komentarze?
Czy ramie SO-101 stoi na tej samej platformie co kamera, i w jakiej odleglosci/orientacji od niej (do transformaty)?
Czy wchodzimy w odlozone przypadki: inne obiekty na torze (liscie, patyki), detekcja w trakcie jazdy, zasieg powyzej 1 m?
Czy wlaczac filtry glebi (--filters)? Poprawiaja pokrycie, ale w polowie przebiegow gubily najblizsza szyszke (patrz pulapki) - zostaly domyslnie wylaczone, decyzja do rewizji przy innych obiektach.
Czy jest ramie leader SO-101 (teleop / nagrywanie demonstracji)?
Czy robimy plan B z uczeniem (ACT) - jest GPU do treningu?
Pi 5: jaka rola (centralny kontroler wszystkiego czy tylko kamera+ramie)? Czy ma juz system/siec/zdalny dostep? Czy repo jest na nim sklonowane? Jak podsystemy maja sie komunikowac (jeden proces vs serwisy po sieci)?

2026-09-26 - pawel120 (Claude) - glebia kamery w nizszej rozdzielczosci

Zrobione: rs_mjpeg_server.py: glebia 424x240 (--depth-res), kolor zostaje 640x480 + align; zakres kolormapy --max-mm (domyslnie 1500, wczesniej ~8 m). Na Pi (z kopii w /tmp) dywan i chwytak z bliska maja ciagla glebie, wczesniej prawie cala glebia byla dziura/ciemna. Nie dziala / otwarte: SSH po WiFi zawieszalo sie (kex zrywany) po kilku ubitych sesjach, pomogl restart Pi. Blad Couldn't resolve requests = kamera zajeta przez stary proces, nie brak trybu (424x240@30 wspierane, USB3). lsusb mowi D435, docs D415. Nastepny krok: przestawic kamere wyzej (STATUS krok 1); jesli glebia dalej slaba, sprobowac --depth-res 480x270. Sprzet: dotkniety (kamera, restart Pi)

2026-09-26 - pawel120 (Claude) - kalibracja HSV na szyszkach

Zrobione: klatki z Pi (snap_frames.py): tla wewnatrz, sama sztuczna trawa, 3 szyszki na trawie. Przeszukanie progow HSV -> lo [130,35,30], hi [179,100,125], min_area 120. Wynik: 3/3 szyszki po ustaleniu AWB, 0 falszywych na trawie, 22 na dywanach. Commit teleop_mirror.py + heartbeat 1.0 s. Nie dziala / otwarte: AWB kamery zmienia kolory przez ~1 s po starcie. Progi z jednej sceny i jednego swiatla. Hue szyszek zawija sie przez 0/180, detektor ma jeden zakres H (uzyty 130-179). Robot piszczal (plyta hovera?), przyczyna nieznana. Nastepny krok: klatki w innym swietle; zablokowac AWB/ekspozycje w camera.py. Sprzet: dotkniety (kamera)

2026-09-26 - pawel120 (Claude) - webowy panel recznego sterowania ramieniem

Zrobione: tools/arm_web.py (HTTP na :8010, bez websocketow) + arm_panel.html: "-"/"+" dla kazdego stawu o krok 1/5/10, pozycje z serw (odczyt max 2 Hz, tylko gdy ramie stoi), HOME, otworz/zamknij chwytak, lista ruchow z motions/, STOP (tez spacja). Logika w pinecone_bot/arm_panel.py: kolejka (jedna komenda naraz, max 10 oczekujacych), zakres z kalibracji serw (arm.calibration + tryb normalizacji, jak lerobot), max_relative_target=None + wlasny krok 2 st/tick (chwytak 4) przy 25 Hz, jog liczony od ostatniej wyslanej komendy (bez sync_read). HOME i ruchy przez WaypointArm, STOP przerywa je miedzy tickami. Po starcie serwer sam jedzie do HOME, do tego czasu przyjmuje tylko HOME/STOP. --fake = atrapa ramienia na laptopie. Testy: tests/test_arm_panel.py (20). Panel jazdy i ramienia w jednym miejscu: UI ramienia w arm_panel.js, montowane w frontend.html (:8000, sekcja "RAMIE") i w arm_panel.html (:8010). Procesy zostaja osobne (blad magistrali serw nie zatrzymuje jazdy, lerobot tylko w arm_web). Glowny STOP jazdy wysyla tez STOP ramienia. CORS tylko dla originu :8000, POST wymaga application/json (obca strona w tej sieci nie przemyci komendy). deploy/push_to_pi.sh kopiuje teraz tez arm_control.py, web_control.py, frontend.html, arm_panel.* (wczesniej tylko pinecone_bot/tools/motions/tests). Nie dziala / otwarte: nie uruchomione na prawdziwym ramieniu. arm_control.open_gripper/go_home nie uzyte wprost: move_to robi sync_read przy kazdym wywolaniu i skacze bez limitu kroku (pulapka 10); zamiast tego te same wartosci (0/100, motions/home.json) przez limit kroku. Ctrl+C = disconnect = torque off, ramie opada - najpierw HOME. Nastepny krok: na Pi python tools/arm_web.py, czlowiek przy ramieniu; sprawdzic HOME przy starcie, jog 1 st, STOP w trakcie grasp_mid. Sprzet: nie

2026-09-26 - pawel120 (Claude) - panel ramienia bez HOME (kamera na ramieniu)

Zrobione: tools/arm_web.py --no-home (ArmPanel(manual_only=True)): bez HOME przy starcie, serwer odrzuca "home" i "motion" (ruchy z motions/ tez koncza w HOME), jog i chwytak od razu, liczone od odczytanej pozycji; UI chowa HOME i liste ruchow. 2 testy. Po drodze: Pi zgubil pendrive systemowy (Input/output error na kazdej komendzie), po odlaczeniu zasilania wstal czysto (root rw, dmesg bez bledow). Kod z mastera (#31) wypchniety na Pi, testy panelu na Pi zielone. Nie dziala / otwarte: na ramieniu siedzi kamera - HOME_POSE i nagrane ruchy trzeba sprawdzic/przepisac pod nowy montaz, zanim ktos uzyje trybu z HOME albo pinecone_bot --real. Nastepny krok: na Pi python tools/arm_web.py --no-home, jog 1 st na kazdym stawie, STOP. Sprzet: dotkniety (Pi: restart po utracie dysku, push kodu; ramie nie ruszane)

2026-09-26 - pawel120 (Claude) - blokada jogu poza zakresem, heartbeat jazdy z klawiszami

Zrobione: Na Pi odpalone tools/arm_web.py --no-home i web_control.py (nohup, logi arm_web.log / web_control.log; robot-web.service nie jest zainstalowany). Odczyt: shoulder_lift 127.7 st przy zakresie kalibracji +-91.6 - kazdy jog tego stawu bylby skokiem serwa o ~36 st do granicy (limit pozycji w EEPROM i tak tnie cel). Panel blokuje teraz jog stawu, ktory jest > 1 st poza zakresem (komenda albo odczyt), UI pokazuje "POZA ZAKRESEM". "Nie jedzie do przodu": w web_control.log failsafe heartbeatu co chwile (ping do Pi do 240 ms, straty na hotspocie), failsafe zeruje klawisze, a przegladarka wysylala W tylko przy wcisnieciu - trzymane W juz nie wracalo. Heartbeat (co 200 ms) niesie teraz stan klawiszy; sprawdzone lokalnie: przy zerwaniu robot staje, po powrocie lacza jedzie dalej. Nie dziala / otwarte: skoki opoznien hotspotu dalej zatrzymuja robota na chwile (tak ma byc przy utracie lacza > 1 s). Do sprawdzenia oszczedzanie energii WiFi na Pi (brak iw w systemie). shoulder_lift do ustawienia recznie / kalibracja pod kamere na ramieniu. Nastepny krok: restart obu serwerow na Pi z nowym kodem (ramie trzymane - connect zdejmuje na chwile torque); test jazdy W. Sprzet: dotkniety (Pi: serwery paneli; ramie i baza nie ruszane przez Claude)

2026-09-26 - Kajud (Claude) - panel: nagrywanie ruchu i sekwencje jazda+ramie

Zrobione: Zbieranie szyszek "na sztywno" z panelu jazdy (:8000), bez pisania kodu. Ramie: pinecone_bot/arm_panel.py dostal szkic waypointow (add_point = biezaca poza: przeguby z odczytu serw, chwytak z ostatniej komendy; drop_point, clear_points, save_motion -> motions/<nazwa>.json w formacie record_waypoints.py, nadpisanie tylko jawne), UI w arm_panel.js (sekcja "NAGRYWANIE RUCHU"). --no-home pozwala teraz odtwarzac ruchy z motions/ (do sekwencji), ale WaypointArm(home_on_empty=False): po pustym chwycie tylko otwarcie chwytaka, bez HOME (kamera na ramieniu). Sekwencje: nowy pinecone_bot/sequence.py (kroki drive/arm/wait, walidacja, sequences/<nazwa>.json, SequenceRunner z wstrzykiwanymi funkcjami, STOP w <=0.1 s), web_control.py tryb "sequence" (runner w watku, kroki ramienia przez HTTP do tools/arm_web.py, env ROBOT_ARM_PANEL; failsafe/STOP/zmiana trybu przerywa, zeruje jazde i wysyla STOP do ramienia; drive_step do testu pojedynczego kroku), sekcja "SEKWENCJA" w frontend.html (szkic w localStorage, zapis/odtworz/edytuj/usun, podglad biezacego kroku). deploy/push_to_pi.sh kopiuje sequences/. Testy: tests/test_sequence.py (12), +5 w test_arm_panel.py, +1 w test_arm.py; razem 135 zielonych. Sprawdzone w przegladarce na atrapie (arm_web.py --fake + web_control.py bez Xiao): nagranie 2-punktowego ruchu, sekwencja jazda 2 s -> ruch -> czekaj przeszla, STOP w trakcie kroku ramienia przerwal obie strony. Nie dziala / otwarte: nic z tego nie ruszalo na sprzecie. Kroki jazdy sa "na czas" (open-loop): powtarzalnosc zalezy od baterii i podloza, PWM -> m/s nadal niezmierzone. Stare ruchy (grasp_mid, home, drop_box) koncza w HOME - w trybie --no-home odtwarzac tylko ruchy nagrane pod obecny montaz (UI ostrzega). Przy hotspocie failsafe heartbeatu przerwie sekwencje tak samo jak jazde reczna. Nastepny krok: na Pi restart obu serwerow z mastera, jog + nagranie grasp_cam z panelu (czlowiek przy wylaczniku), potem sekwencja: podjazd 1-2 s -> grasp_cam -> cofniecie; zmierzyc ile cm daje 0.3 x 2 s. Sprzet: nie

2026-09-26 - pawel120 (Claude) - jog XYZ ramienia w panelu

Zrobione: pinecone_bot/kinematics.py: FK z URDF so101_new_calib.urdf (numpy, bez ikpy) i krok IK (DLS) dla TCP (gripper_frame_link): przesuniecie o 5/10/20 mm w osiach bazy, pochylenie chwytaka bez zmian. Panel ramienia: sekcja JOG XYZ (GORA/DOL/PRZOD/TYL/LEWO/PRAWO), odczyt TCP, przycisk ZERO URDF (biezacy odczyt = zero URDF, offsety do pinecone_config.json: arm.urdf_offset_deg, znaki arm.urdf_sign). 150 testow zielonych, sekcja widoczna w przegladarce na atrapie. Nie dziala / otwarte: nie sprawdzone na ramieniu. Zero lerobot to srodek nagranego zakresu, nie zero URDF (HARDWARE pulapka 12) - bez ZERO URDF jog pojedzie krzywo. Znaki przegubow niezmierzone (domyslnie +1). Nastepny krok: na Pi: ramie prosto poziomo do przodu -> ZERO URDF -> GORA 10 mm, sprawdzic kierunek. Sprzet: nie

2026-09-26 - pawel120 (Claude) - robot wjechal w ramie; cofniety heartbeat z klawiszami, predkosc /2

Zrobione: Po wdrozeniu PR #33 (heartbeat niosl stan klawiszy) robot przy duzym opoznieniu hotspotu wjechal w ramie i je uszkodzil. Prawdopodobna przyczyna (Claude): opoznione heartbeaty dochodza seriami, stare "W wcisniete" po failsafe znow uruchamialy jazde, a puszczenie W przychodzilo pozniej. Dead-man mierzy czas DOTARCIA wiadomosci, wiec spoznione wiadomosci wygladaja na swieze. Cofniete: heartbeat to znow goly ping (po failsafe trzeba wcisnac klawisz od nowa). web_control.py MAX_PWM 500 -> 250, panel ramienia krok 2 -> 1 st/tick (chwytak 4 -> 2). Zdalny STOP po awarii nie doszedl: Pi przestal odpowiadac (ping 100% strat). Nie dziala / otwarte: ramie uszkodzone - ocena. shoulder_lift czyta 116-128 st przy zakresie +-91.6, a wedlug uzytkownika staw jest fizycznie w zakresie -> podejrzenie rozjazdu Homing_Offset w serwie vs so101.json. Narzedzie do kalibracji jednego stawu (tools/calibrate_joint.py) zablokowane przez uprawnienia sesji - czeka na decyzje uzytkownika. Jazda po hotspocie z opoznieniem > 1 s jest niebezpieczna niezaleznie od kodu: dead-man nie odroznia spoznionych komend. Nastepny krok: ogledziny ramienia; Pi na dobrym zasilaniu; zanim ktos pojedzie zdalnie - znaczniki czasu w komendach jazdy (odrzucac spoznione) albo jazda tylko w zasiegu wzroku z wylacznikiem. Sprzet: dotkniety (robot wjechal w ramie - uszkodzenie)

2026-09-26 - tomek - sciezka S w POKRYCIU

Zrobione: tryb POKRYCIE w web_control.py zawsze skrecal w te sama strone, wiec po drugim nawrocie wracal na pierwszy pas i jezdzil tam i z powrotem po dwoch pasach. Teraz kierunek nawrotu zmienia sie po kazdym turn2 (L, P, L...), wiec pasy ida w poprzek pola. Logika fazy wydzielona do coverage_advance(), test tests/test_web_control_coverage.py (websockets podstawiony stubem, bo nie ma go w CI). Nie dziala / otwarte: nie jechane na sprzecie. Czasy otwarte (bez odometrii), wiec 90 st zalezy od cov_turn_seconds. Znak skretu Xiao niezmierzony: pierwszy nawrot moze pojsc w prawo - wtedy start z drugiego rogu. Nastepny krok: na trawie nastroic cov_turn_seconds do 90 st, potem dlugosc pasa i odstep; zmierzone predkosci przepisac do search_drive_v / search_w w pinecone_config.json. Sprzet: nie

2026-09-26 - pawel120 (Claude) - wylacznik STOP na telefon

Zrobione: Strona /stop (stop.html) w web_control.py: jeden duzy przycisk na caly ekran telefonu (pointerdown, bez przewijania). POST /api/estop zatrzaskuje STOP: petla sterowania co tick robi hard_stop() (zero bez rampy, tryb manual, koniec sekwencji/nagrywania, klawisze zerowane), start_sequence odmawia; watek wysyla STOP do ramienia (:8010). ODBLOKUJ (/api/estop_release) wymaga numeru zatrzasku - spozniony ODBLOKUJ nie zdejmie nowszego STOP. HTTP zamiast WebSocket celowo: /stop nie jest heartbeatem operatora, wiec telefon z ta strona nie trzyma robota przy zyciu po utracie panelu jazdy. Strona ponawia STOP do potwierdzenia, pokazuje lacze w ms i "BRAK LACZA" po 2 s. Panel jazdy pokazuje stan E-STOP i link do /stop. tests/test_web_control_estop.py (8), razem 163 zielone. Sprawdzone w przegladarce (widok telefonu) na web_control.py bez Xiao: zatrzask blokuje W, po ODBLOKUJ jedzie, STOP w trakcie jazdy zeruje. Nie dziala / otwarte: nie wdrozone na Pi. Zatrzask dotyczy jazdy; panel ramienia dostaje jeden STOP, jog ramienia dalej mozliwy. Przy duzym lagu hotspotu STOP tez dojdzie pozno. Nastepny krok: skopiowac web_control.py, stop.html, frontend.html na Pi, restart web_control.py, test STOP z telefonu przy jadacym robocie (kola w powietrzu).

2026-09-26 - frane (Claude) - polaczenie z Pi po WiFi + kalibracja HSV V/H

Zrobione:

Polaczenie z Pi: robot.local (mDNS, dziala w git-bash, nie w PowerShell) odpowiada, Pi ma dwa adresy - eth0 192.168.137.5 (kabel) i wlan0 172.20.10.4 (hotspot "iPhone pawel"). WiFi na Pi DZIALA (wczesniejsze wpisy mowily, ze nie) - SSH po WiFi ma ping 11-109 ms. Kabel 192.168.137.5 nie odpowiadal, bo byl wpiety w wbudowany port Realtek, a Windows ICS (192.168.137.1) bylo skonfigurowane na adapterze USB-Ethernet. Klucz SSH laptopa (~/.ssh/id_ed25519) zainstalowany na Pi (ssh-copy-id) - sesje Claude wchodza bez hasla.
Kod na Pi sprawdzony wobec mastera: d1f1b9e, ale BEZ PR #30 (pinecone_bot/camera.py i config.py na Pi starsze - brak sekcji "camera" z warmup_frames/lock_auto). Reszta plikow zgodna z masterem.
Kalibracja HSV (kamera na ramieniu, patrzy z gory na chwytak, szyszki na sztucznej trawie w hali): 40 klatek z tools/snap_frames.py (20 s co 0.5 s), analiza statystyk HSV na laptopie (percentyle 2/10/50/90/98): szyszka H [0,15,150,175,178] S [3,8,41,107,126] V [31,51,76,91,94]; trawa H [0,30,108,154,173] S [2,4,11,25,90] V [97,103,123,151,178]; chwytak (niebieski) H 100-109, S 138-255. Szyszki rozdziela V (< 95 vs > 97 dla trawy), a H szyszek lezy na obu koncach skali (0-15 i 150-179) - stary prog H 130-179 dawal poszarpana maske.
Stary prog (lo [130,35,30], hi [179,100,125], min_area 120, morph 5): 19 bledow liczby detekcji na 23 klatkach kontrolnych. Nowy prog wpisany do pinecone_config.json na Pi (backup pinecone_config.json.bak-20260926-1320): lo [130,20,20], hi [179,130,95], min_area_px 300, morph_ksize 7 -> 1 blad na 23 klatkach. Dopisana tez sekcja "camera" (warmup_frames 90, lock_auto true) - zadziala dopiero po wypchnieciu PR #30.
Test na zywo na Pi (30 klatek, 29.8 fps): pierwsze ~0.8 s po rozgrzewce (45 klatek) zero detekcji (AWB jeszcze zielony), potem stabilnie 1 szyszka. W jasniejszym swietle z 2 szyszek w kadrze wykryta 1 - prog jest czuly na jasnosc, lock_auto jest potrzebny.
W branchu (commit 0e89a0c) pinecone_bot/detector.py obsluguje zakres H przechodzacy przez 180 (lo H > hi H), test tests/test_detector.py::test_hue_range_wrapping_through_180_joins_both_ends. Wariant "przez zero" (lo [140,20,20] hi [15,130,95]) dal 3 bledy, wiec na Pi zostal zwykly zakres - NIE wpisywac zakresu przez zero do configu na Pi, dopoki nie ma tam nowego detector.py.
Prog HSV V<95 z poprzedniej czesci sesji jest NIEAKTUALNY: drugi zestaw klatek (20 klatek, jasniejsze swiatlo, 2 szyszki) dal 18 bledow na 18 klatkach - rozdzielal po jasnosci, a mediana V szyszek rosnie z ~96 do ~109 przy zmianie swiatla (trawa stoi ~123). Naprawa: prog po odcieniu+nasyceniu (H i S sa stabilne miedzy swiatlami - S mediana 73-80 dla szyszki vs ~10 dla trawy, H szyszki 156-176): lo [130,20,20] hi [179,160,255], min_area_px 400, morph_ksize 9 (blur 5) -> 0 bledow na obu zestawach (20 + 18 klatek), przeszukano 20160 kombinacji, sprawdzone klasa HsvConeDetector z repo. Commit w branchu: 2ba7fc9 (pinecone_config.json). Reka w kadrze ma ten sam odcien co szyszka (bloby 9000-31500 px, szyszka max ~4000 px) - max_area_px 40000 tego nie odrzuca, warto rozwazyc ~8000 (nie zmienione). Na Pi ten prog NIE zostal jeszcze wpisany - laptop na chwile stracil siec do Pi (patrz nizej) - na Pi jest wciaz prog V<95 (lo [130,20,20] hi [179,130,95], min 300, morph 7).
Odkryte: pinecone_config.json jest sledzony w gicie i deploy/push_to_pi.sh go NADPISUJE na Pi przy kazdym pushu - wartosci zmierzone na sprzecie musza trafic do configu W REPO (commit/PR), inaczej gina przy nastepnym pushu (tak wlasnie stracono dzis raz wpisany prog i sekcje "camera"). Dopisane jako pulapka do docs/HARDWARE.md.
Nowe narzedzie tools/record_motion.py (commit 40a75aa, w branchu, NIE na masterze): ciagle nagranie ruchu ramienia prowadzonego reka, bez jazdy do HOME (kamera na ramieniu), probki 10 Hz, 'q'+Enter konczy, torque wraca, zapis motions/<name>.json (waypointy co 0.25 s w tempie prowadzenia, pierwszy z dojazdem 1.5 s), odtwarzanie tools/arm_play.py --motion <name>. Testy tests/test_record_motion.py (3). Powstalo, bo tools/record_waypoints.py (punkt po punkcie, pytania w konsoli) byl dla operatora za uciazliwy, a legacy record_demo.py jedzie do HOME i nagrywa stala liczbe sekund.
Nagrano motions/grasp_near.json na Pi (112 waypointow, 33 s, chwytak 34 -> 1.3, shoulder_lift od -42 st przy chwycie do 121.7 st w pozie spoczynkowej z kamera nad chwytakiem). Poza spoczynkowa jest POZA zakresem kalibracji +-91.6 (ticki 1006..3089, homing_offset 1977) - odczyt z serwa dziala, ale nie wiadomo, czy limit pozycji w EEPROM serwa nie utnie celu przy odtwarzaniu (bark moglby skoczyc o ~30 st do granicy na starcie). Do sprawdzenia odczytem Min/Max_Position_Limit z serwa PRZED pierwszym arm_play na grasp_near. NIE odtworzone. drop_box nie nagrany. Plik grasp_near.json jest tylko na Pi, nie w repo.
Pulapka: sesja tmux odpalona z nieinteraktywnego ssh na Pi ginie po rozlaczeniu ssh (nawet z nohup/setsid przezyla tylko jedno rozlaczenie, potem zniknela) - interaktywne narzedzia ramienia trzeba odpalac we WLASNYM terminalu operatora przez ssh -t robot@<ip> "cd ~/hackaton && .venv/bin/python tools/...". Dopisane do docs/HARDWARE.md i docs/SETUP.md.
Sesje Claude nie moga kopiowac plikow kodu na Pi (blokada trybu auto "Remote Shell Writes"); config JSON przez python heredoc po ssh przechodzi. Operator kopiuje pliki kodu sam: scp tools\record_motion.py robot@172.20.10.4:~/hackaton/tools/ (z cmd na laptopie). Dopisane do docs/SETUP.md.
Siec: laptop w trakcie sesji przelaczyl sie sam z hotspotu "iPhone pawel" na "hacker-bloc" (IPv6 only) i stracil polaczenie z Pi; przy innej okazji byl po prostu odpiety kabel. Dopisane jako uwaga do docs/SETUP.md. Nie dziala / otwarte: Po restarcie Pi zadne panele nie chodza (web_control.py, tools/arm_web.py nie startuja same, robot-web.service nie zainstalowany) - nadal nie odpalone w tej sesji. camera.py/config.py na Pi bez PR #30 (lock_auto) i bez nowego progu HSV (commit 2ba7fc9) - detekcja na Pi dalej czula na zmiane jasnosci/ekspozycji. motions/grasp_near.json nagrany, ale nie odtworzony (shoulder_lift poza zakresem kalibracji w pozie spoczynkowej - ryzyko utracia celu przez limit EEPROM). drop_box nie nagrany. Nastepny krok: wpisac nowy prog HSV (commit 2ba7fc9) na Pi (albo push z brancha po merge) i sprawdzic na zywo; odczytac limity EEPROM barku, potem tools/arm_play.py --motion grasp_near z reka na wylaczniku; nagrac drop_box (tools/record_motion.py --name drop_box), dopisac chwyty do cfg.grasps, tools/calibrate_target.py; potem tools/base_test.py, --dry-run, --real z wylacznikiem. Sprzet: dotkniety (tylko odczyt kamery i plik configu na Pi; ramie i baza nie ruszane)

2026-09-26 - pawel120 (Claude) - podglad glebi jak RealSense Viewer

Zrobione: Uzytkownik: glebia w rs_mjpeg_server.py "zupelnie inna niz w RealSense Viewer". Klatka ze strumienia: dane glebi ciagle (podloga bez dziur, szyszki widoczne jako slabe wybrzuszenia), winna skala liniowa 0-1500 mm - podloga to jeden gradient, szyszki (kilka cm) nie odrozniaja sie. Domyslnie teraz rs.colorizer (Jet z wyrownaniem histogramu, brak danych = czarny, jak w Viewerze); stara skala pod --colormap fixed. Podglad uruchomiony na Pi (:8080), D435 na USB3, zasilanie bez throttlingu. Nie dziala / otwarte: nowa wersja nie wdrozona na Pi (sesja nie miala zgody na zapis na Pi). Viewer ma tez filtry (spatial/temporal) i domyslnie 848x480 - tu ich nie ma. Nastepny krok: scp rs_mjpeg_server.py na Pi, restart podgladu, porownac z Viewerem. Jesli szyszki dalej slabo widac: kolor = wysokosc nad plaszczyzna podlogi (jak w scan_cones.py). Sprzet: nie (tylko odczyt kamery)

2026-09-27 - frane + Claude - pasy po kursie z telefonu

Zrobione: Decyzja: plyta hovera jest przerobiona i niedostepna, wiec hallotronow (bipropellant) nie bedzie; IMU brak; ROS/SLAM/MuJoCo odlozone. Kurs do pasow bierzemy z zyroskopu telefonu (phyphox, remote access). pinecone_bot/heading.py (PhyphoxGyro: odpytywanie HTTP, calkowanie trapezami, stale -> None; OdometryHeading), cfg.heading, brain.py: pasy jako odcinki (spin/line/turn), obrot do kata zamiast po czasie, P na kurs na prostej, powrot na kurs pasa po chwycie, kurs startowy zapisany przed pierwszym podjazdem. Bezpieczniki: brak kursu > lost_s albo odcinek > 3x nominalu -> pasy z czasu od tego samego miejsca. --heading w main, kolumna yaw_deg w CSV, tools/phyphox_check.py, niedoskonalosci napedu w symulatorze (sim.turn_gain, sim.drift_w). Symulacja, pole 3.0 m, 10 ziaren x 5 szyszek: naped idealny - z czasu 43/50, z kursem 47/50; poslizg obrotow 15% + znoszenie 0.03 rad/s - z czasu 39/50, z kursem 44/50. Koniec wzorca bez szyszek przy poslizgu: 0.10 m od idealu z kursem, 3.5 m bez. 128 testow zielonych. Nie dziala / otwarte: nic nie sprawdzone na telefonie ani robocie: czy phyphox na iPhonie-hotspocie odpowiada pod 172.20.10.1:8080, znak kursu, czy ekran nie gasnie. Dlugosc pasa dalej z czasu (zyroskop nie mierzy drogi). Nastepny krok: phyphox na telefonie, python tools/phyphox_check.py na Pi, obrot recznie o 90 st w lewo -> ~+90. Sprzet: nie

2026-09-27 - frane + Claude - telefon jako zyroskop dziala

Zrobione: phyphox na iPhonie (tym samym, ktory robi hotspot) odpowiada Pi pod http://172.20.10.1 - port 80, nie 8080 jak w dokumentacji phyphox (to port Androida). Znalezione skanem portow z Pi (GCDWebServer na :80). Bufory gyrZ/gyr_time zgodne z kodem. Obrot robota recznie o 90 st w lewo -> kurs +90, heading.sign 1.0 dobry. Domyslny phyphox_url poprawiony, pulapka 36 w HARDWARE.md. Test na Pi szedl z osobnego katalogu ~/phyphox_test (config.py, heading.py, phyphox_check.py z mastera), bo na Pi jest kod z pawel/arm-xyz-jog, nie master. Nie dziala / otwarte: serwer phyphox znika po zgaszeniu ekranu. Jazda po kursie nie sprawdzona: brain.py/main.py na Pi nie maja kursu, dopoki pawel/arm-xyz-jog nie polaczy sie z masterem (push mastera cofnalby panel XYZ). Nastepny krok: merge pawel/arm-xyz-jog z masterem, push na Pi, --dry-run --heading phyphox. Sprzet: tak (telefon, Pi; baza i ramie nie ruszane)

2026-09-27 - frane + Claude - kod z Pi z powrotem w repo (frane/pi-sync)

Zrobione: Na Pi byl nie master, tylko mieszanka branchy: web_control.py/frontend.html/arm_panel.py z pawel/drive-s-path, reszta pinecone_bot/ z pawel/arm-xyz-jog (przez PR #35), rs_mjpeg_server.py z pawel/rs-viewer-colormap, tools/calibrate_joint.py z pawel/drive-revert-heartbeat-half-speed, plus pliki tylko na Pi (tools/estop_server.py, tools/raw_drive.py, offsety URDF w pinecone_config.json). push_to_pi.sh z mastera cofnalby panel XYZ i zgubil offsety. Branch frane/pi-sync = master + pawel/phone-estop (zawiera drive-s-path i arm-xyz-jog) + PR #35 + pawel/rs-viewer-colormap + frane/phyphox-ios + pliki z Pi. Porownanie md5 (bez CR) wszystkich plikow kopiowanych przez push_to_pi.sh: na Pi nic nie zostaje cofniete, roznice to tylko nowsze wersje (master, /stop, kurs). Prog HSV i sekcja camera z mastera (nowszy prog, dwa swiatla; PR #30), offsety URDF z Pi. 178 testow zielonych, symulacja 5/5 z kursem i bez. Nie dziala / otwarte: pinecone_bot/landmarks.py na Pi to same bajty zerowe (uszkodzony, pewnie pad pendrive'a przy zasilaniu z powerbanku); nic go nie importuje, oryginal jest w lokalnym commicie dafd481 (branch pawel/base-calibration, niewypchniety). tools/live_grasp/ (niezacommitowany eksperyment z pawel/arm-home-cam) poleci na Pi przy pushu z tego katalogu, bo push kopiuje katalog roboczy - nieszkodliwe. Na Pi nadal prog HSV z phone-estop (sztuczna trawa) do pushu. Nastepny krok: review + merge PR, PI_HOST=robot@172.20.10.4 bash deploy/push_to_pi.sh z mastera, potem python -m pinecone_bot.main --dry-run --heading phyphox. Sprzet: nie (tylko odczyt plikow z Pi)

2026-09-27 - frane + Claude - --no-arm do testow jazdy

Zrobione: python -m pinecone_bot.main --real --no-arm: prawdziwa baza, ramie tylko drukuje (PrintArm), port ramienia nie jest otwierany. Powod: ramie uszkodzone 2026-09-26, a --real odtwarza chwyt przy kazdej brazowej detekcji (reka w kadrze ma odcien szyszki). make_devices() w main.py, 3 testy w tests/test_main.py, 181 zielonych. Nie dziala / otwarte: nic na sprzecie. Nastepny krok: po merge #44 i tego PR: push na Pi, --dry-run --heading phyphox (obracac recznie), base_test.py, --real --no-arm --heading phyphox z lane_count 1. Sprzet: nie

2026-09-27 - frane + Claude - zyroskop z telefonu, petla obrotu, kalibracja glebia (branch frane/lidar)

Zrobione:

--dry-run --heading phyphox na Pi z pustym obrazem (--source ~/pusty.png), telefon obracany recznie: obrot 360 st konczy sie na 358, prosta trzyma kurs, skret liczy kat. Na Pi byl config.py z portem 8080 (bez #43) -> tymczasowo heading.phyphox_url w configu na Pi.
tools/calibrate_turn.py (skan PWM skretu i --response PWM): skret hovera ma martwa strefe 100-160 zaleznie od tego, czy robot stal, predkosc przy tym samym PWM rozrzut 2.5x, opoznienie 0.15-0.4 s, wybieg 3-10 st. Pulapka 37.
pinecone_bot/turn_loop.py: petla predkosci obrotu na zyroskopie (rampa, gdy stoi; skok do PWM, ktory ostatnio trzymal predkosc, gdy ruszy; calka, gdy kreci). XiaoBase.set_raw. Symulator --hover (SimXiaoDrive + SimGyro, model z pomiarow). Pasy na modelu: 0.01-0.07 m od idealu przy wzmocnieniu 0.007-0.018 i opoznieniu telefonu 0.1-0.2 s; bez petli robot sie nie obraca. Szyszki: 24/25 na bazowym modelu, ale przy innych parametrach podjazd oscyluje.
tools/calibrate_drive.py: predkosc do przodu z glebi (odleglosc do sciany przed i po jezdzie, powrot tylem, stop przy scianie < 0.5 m). Pierwsze odpalenie: kamera patrzyla w sufit -> +-2 cm, choc robot jechal 40 cm. Dodane zdjecie widoku i ostrzezenie. Kamera ustawiona poziomo jogiem nadgarstka przez panel.
Ramie przez panel arm_web.py --no-home + /api/cmd: wszystkie stawy i chwytak ruszaja sie, powrot do pozycji. shoulder_pan przy granicy -23 ucina krok (skonczyl 6 st obok startu).
Kod na Pi: wypchniety z brancha frane/gyro-rate-loop (PUSH_ANY_BRANCH), nie z mastera. Kopie configu z Pi: ~/pinecone_config.json.bak-*. Nie dziala / otwarte: pomiar jazdy do przodu do powtorzenia (kamera na sciane); petla obrotu nie jechala na robocie; podjazd do szyszki na hoverze wrazliwy (pomysl: celowanie krokami); landmarks.py na Pi uszkodzony. Nastepny krok: calibrate_drive.py --write, potem pasy --real --no-arm --heading phyphox z lane_count 1. Sprzet: tak (baza: obroty i jazda testowe; ramie: jog przez panel; telefon; kamera)

Do polaczenia z druga sesja o glebi/lidarze: branch frane/lidar (= frane/gyro-rate-loop, wychodzi z frane/no-arm <- frane/pi-sync). Pliki o glebi: tools/calibrate_drive.py, tests/test_calibrate_drive.py; o kursie/obrocie: pinecone_bot/heading.py, pinecone_bot/turn_loop.py, tools/calibrate_turn.py, tools/phyphox_check.py, pinecone_bot/sim.py (SimXiaoDrive, SimGyro), heading.* w pinecone_bot/config.py.

2026-09-27 - frane + Claude - mapa ogrodu D435, zygzak po mapie (branch frane/mapa-d435)

Zrobione:

Polaczone sesje o "lidarze": lidara nie ma, to glebia RealSense; kamera to D435 (nie D415).
tools/record_rgbd.py: nagranie na Pi prosto w formacie RTAB-Map (kolor + glebia wyrownana, ostrzezenia o szybkim obrocie, malej glebi, dziurach). tools/rtabmap_build.py: mapa jedna komenda na laptopie (RTAB-Map 0.23.8 win64; 0xC0000135 = brak msvcr110/msvcp110 - skopiowane x64 z Office do bin).
pinecone_bot/localize.py: lokalizacja z jednego zdjecia (ORB + PnP do klatek kluczowych mapy), na Pi 0.5 s.
pinecone_bot/zygzak.py: pasy od miejsca startu, obrot na zyroskopie, co 1 m stop + zdjecie + poprawka, uczenie prawdziwej predkosci; --first-turn, poza ramienia motions/patrz.json na start. Symulacja: robot 0.6x wolniejszy trafia w punkty < 0.3 m, bez zdjec chybia > 0.5 m.
camera.py: bez lock_auto odmraza auto-ekspozycje (kamera pamietala 166 -> bialy obraz na sloncu).
estop_server.py: zabija tez zygzak i calibrate_drive. tools/arm_hold.py: poza trzymana do Ctrl+C.
Nagrania ogrod1 (329 s) i ogrod2 (235 s), mapy z obu. Nie dziala / otwarte: mapy rozpadaja sie na kawalki (5-9), ok. 1/3 nagrania poza mapa; ze startu przy plocie brak lokalizacji (ogrod1). ogrod2 na zywo niesprawdzona. Zygzak nie jechal. Szyszki w zygzaku niepodpiete. Pi padl raz. Nastepny krok: zdjecie ze startu na ogrod2; jesli nie lapie - strojenie odometrii RTAB-Map / krotsze nagranie pola. Sprzet: tak (kamera, ramie w pozie patrz, jazda panelem przy nagraniu; Pi restart) Koniec sesji (frane przechodzi na inny laptop): mapy RTAB-Map skopiowane na Pi ~/mapy (bez raw.db), opis w docs/MAPA.md ("Na innym laptopie"). PR #50 czeka na review. Kod testowy na Pi w ~/mapa_test (nie w ~/hackaton). Przekazanie z sesji "Dostep do kamer": Xiao odpiety (leader w jego USB), pulapka 43 (push_to_pi nadpisuje pliki z Pi).

2026-09-27 - frane + Claude - research gotowych polityk lerobot

Zrobione: Przegladniete z polki: lerobot (ACT, SmolVLA, MolmoAct2, Flux3), DOT (IliaLarchenko), MolmoAct ("moloko"). Wynik w docs/POLICIES_LEROBOT.md. Skrot: gotowych wag do szyszek nie ma. Jedyny zero-shot pod SO-101 to MolmoAct2 (5B, 21.8 GB fp32, lerobot main, GPU >= 24 GB) - nie odpali na RTX 3070 8 GB ani na Pi. DOT nie zmergowany do lerobot (PR #739 stale), tylko fork ze stara kalibracja - odpada. Realna sciezka: lerobot ACT (jest w 0.6.1) na wlasnych ~50 epizodach, inference przez async policy server na laptopie, Pi jako klient; SmolVLA fine-tune (Colab) jako plan B. Blokery wspolne: brak leader arm (zamiennik: teleop telefonem lerobot[phone], IK na naszym URDF) i tylko jedna kamera, na ramieniu (potrzebna druga, statyczna). Nie dziala / otwarte: nic nie uruchamiane; decyzja zespolu, czy ML idzie rownolegle do petli z RUNBOOK. Nastepny krok: jesli tak: pip install "lerobot[phone]" na laptopie, kopia so101.json z Pi, teleop telefonem przy stole z wylacznikiem; potem druga kamera i nagranie 50 epizodow. Sprzet: nie

2026-09-27 - frane + Claude - lerobot do ACT: instalacja laptop + Pi

Zrobione: Decyzja frane: robimy ACT rownolegle do petli deterministycznej; laptop = serwer (trening, policy server), Pi = klient robota (teleop telefonem, nagranie, robot_client), bo placo (IK teleopu) nie ma kola na Windows. Laptop (.venv, Python 3.12): torch 2.11.0+cu128 (CUDA widzi RTX 3070 8 GB), lerobot 0.6.1 [phone,feetech,async], numpy 2.5.3 -> 2.2.6 (pin lerobota), opencv naprawione po konflikcie headless; importy teleopu OK; 128 testow zielonych. so101.json skopiowany z Pi do cache lerobota na laptopie (MD5 zgodne). Na Pi odtworzony ~/hackaton/examples/phone_to_so100/ (skrypty z tagu v0.6.1 + SO101/ z SO-ARM100: URDF identyczny z repo + 31 STL). Dokumentacja: docs/SETUP.md sekcja "lerobot do ACT" z komendami i pulapkami (placo/Windows, override torcha na Pi, hebi-py tylko sdist, brak examples/ po pip install). Torch cu128 po hotspocie: ~1 h. Nie dziala / otwarte: instalacja extras na Pi: pierwszy uv pip install lerobot[phone,...] cofal sie po wersjach hebi-py (sdist ~92 MB kazdy) i chcial wymienic torch 2.14+cpu na generyczny z PyPI (2 GB CUDA); rozwiazane przez --override + jawne skladniki extra phone (dry-run czysty), ale wlasciwa instalacja padla na "network unreachable" przy cmeel-assimp - hotspot sie zrestartowal (laptop dostal nowy adres), Pi nie wrocilo do sieci przez 10+ min. pkill -f przez ssh zabil sam siebie 2x (HARDWARE pulapka 31) - uzywac pgrep -x uv. Uwaga: shoulder_pan ma w kalibracji zakres tylko 1786..2308 tickow (~46 st) - IK z telefonu bedzie ograniczone na boki. Dokonczone w tej samej sesji (10:27-10:38): przyczyna "znikniecia" Pi: laptop sam przeskoczyl na WiFi "hacker-bloc", Pi caly czas bylo na hotspocie pod 172.20.10.4. Po powrocie laptopa na hotspot instalacja na Pi przeszla (90 paczek, 4 MB/s): torch 2.14.0+cpu zostal, torchvision 0.29.0+cpu, numpy 2.2.6, placo 0.9.15, hebi-py 2.11.0, grpcio. Weryfikacja OK: importy teleopu, IK placo na URDF z examples/, robot_client, pyrealsense2, pinecone_bot. Placo ostrzega o samokolizjach URDF w pozie neutralnej (nieszkodliwe). Testy repo na Pi po zmianie numpy: 195/202 zielone; 7 czerwonych to NIE numpy, tylko osierocone pliki na Pi z niezmergowanego brancha claude/robot-pinecone-test-plan-e4ca8e (tests/test_calibrate_target.py - 6, wola collect_average, ktorego nie ma w tools/calibrate_target.py na Pi; tests/test_web_control_estop.py - 1, /stop 404 na starszym web_control.py, test wisi ~2 min czekajac na HTTP). Katalog tests/ na Pi to mieszanka branchy po kolejnych push_to_pi.sh - deploy/push_to_pi.sh kopiuje, nie synchronizuje z usuwaniem. Notatka Tomka docs/STACK.md (branch tomek/docs-stack) zgodna z tym opisem: zero ML w glownym stosie, lerobot tylko jako sterownik serw. Wspomina teleop_mirror.py (leader -> follower, id so101_leader) - jesli ramie leader fizycznie istnieje, nagrywamy lerobot-record --teleop.type=so101_leader i telefon/placo sa zbedne. Odpowiedz frane: leader JEST (sala 435 D). Bez kalibracji (brak so101_leader.json na Pi i laptopie). Pulapka: leader ma ten sam CH343 co follower - regula udev po idVendor/idProduct dalaby obu /dev/robot-arm; odczytany serial followera 5B41532803, deploy/99-robot.rules rozroznia teraz robot-arm (ten serial) i robot-leader (inny CH343). SETUP.md: sekcja "Wariant z leaderem" (kalibracja TYLKO leadera, teleop test, record lokalnie, train na laptopie). Nastepny krok: wgrac regule udev na Pi, wpiac leader, lerobot-calibrate --teleop.* (bez --robot.*), lerobot-teleoperate z wylacznikiem, potem lerobot-record (SETUP.md). Stary plan (gdyby leadera nie bylo): lerobot-record z leaderem (moze byc z laptopa, bez placo). Jesli nie: teleoperate.py na Pi z podmienionym portem (/dev/robot-arm), id="so101" i kamera, z wylacznikiem w rece; iPhone z HEBI Mobile I/O w tej samej sieci co Pi. Potem druga (statyczna) kamera i nagranie. Sprzet: dotkniety zdalnie (tylko instalacja pakietow i odczyt pliku kalibracji na Pi; ramie i baza nie ruszane)

2026-09-27 - frane + Claude - zera stawow vs URDF i kalibracja reka-oko (narzedzia)

Zrobione: Pytanie frane "nie mamy juz ruchu ramienia dla pozycji szczeki?" - nie: IK (legacy/ik_approach, ikpy) nigdy nie zweryfikowane na sprzecie, zera lerobot vs URDF niesprawdzone (HARDWARE 12), transformata kamera-ramie oszacowana. GraspGenX (NVIDIA, generator poz chwytu 6-DOF z chmury punktow) odlozony: potrzebuje IK, kalibracji kamera-ramie i segmentacji, a rozwiazuje tylko "gdzie chwycic" (dla szyszki latwe). Zeby to nadrobic, dwa narzedzia: tools/frame_check.py (dla kazdego stawu ruch +delta, FK placo na URDF, opis przesuniecia koncowki slowami, werdykt operatora t/n, raport JSON; --fake bez sprzetu) i tools/hand_eye_calib.py (marker ArUco -> collect z torque off jak record_motion -> AX=XB Park-Martin w numpy (cv2.calibrateHandEye tylko jako kontrola: CI ma OpenCV 5.0 bez tej funkcji) -> camera_on_arm.json = T_gripper_cam, residua, predict pozycji kamery z FK). Testy: tests/test_frame_check.py (5, atrapa ramienia i plaska kinematyka), tests/test_hand_eye_calib.py (9, syntetyczne AX=XB odzyskuje X z bledem < 0.1 mm, marker syntetyczny wykrywany). 142 testy zielone. Instrukcja dla sesji przy Pi: docs/ARM_FRAMES.md. RUNBOOK: dwa wiersze w tabeli narzedzi. Nie dziala / otwarte: nic z tego nie odpalone na sprzecie. Osie X/Y podstawy URDF nieznane (Z = gora pewne), ustala operator na shoulder_pan. placo ostrzega o samokolizjach URDF w pozie neutralnej (nieszkodliwe). Nastepny krok: sesja przy Pi wg docs/ARM_FRAMES.md: push_to_pi, frame_check.py --fake, potem z ramieniem (wylacznik), potem marker + hand_eye_calib.py collect/solve; wyniki do LOG, camera_on_arm.json do repo. Sprzet: nie (tylko odczyt FK na Pi bez ruchu)

2026-09-27 - frane + Claude - wolniejszy skret w panelu

Zrobione: web_control.py: MAX_STEER 400 -> 200 (A/D w panelu jazdy skreca o polowe wolniej). MAX_PWM bez zmian (500). Nie dziala / otwarte: na branchach frane/* jest MAX_PWM = 100, na master dalej 500 - do ustalenia, co ma byc na master. Nastepny krok: sprawdzic skret na robocie, ewentualnie dostroic MAX_STEER. Sprzet: nie

2026-09-27 - frane + Claude - ACT: leader, nagrywanie, act_pick

Zrobione: leader na Pi (/dev/robot-leader, zamiast kabla hovera), kalibracja leadera skopiowana z followera (decyzja frane) + gripper calibrate_joint.py. motions/drop_box.json nagrany na Pi, przyciety od t8.40, powrot tym samym torem bez postoju (15 s; kopie drop_box_full/_oneway/_old.json). Na Pi lerobot[dataset] (override torch 2.14 cpu). Undervoltage przy 2 ramionach + kamerze: frame is too old w lerobot-record, potem Bus error - uszkodzone pyarrow i av (sprawdzone hashami RECORD calego venv), przeinstalowane; nowe zasilanie -> throttled=0x0. Nagrane: so101_grasp_t2 2 ep., so101_grasp 7 ep., so101_grasp2 12+ ep. (30 fps, 449 klatek/ep.). tools/act_pick.py + tests/test_act_pick.py (5), 150 testow zielonych. Nie dziala / otwarte: czesc osi leadera odwrocona (nie poprawione, drive_mode w pliku leadera). Brak wag ACT. drop_box.json tylko na Pi. torchcodec na Pi nie laduje sie (torch 2.14 vs 0.11) - lerobot uzywa pyav. Nastepny krok: 50 epizodow, trening na RTX 3070, act_pick.py --skip-drop. Sprzet: dotkniety (ramiona, kamera, pakiety na Pi)

2026-09-27 - pawel120 + Claude - podglad kamery w procesie lerobot

Zrobione: tools/cam_preview.py: uruchamia komende lerobot (record/rollout/teleoperate) w swoim procesie i serwer MJPEG na 8081 obok. Hook na lerobot.cameras.camera.Camera.__init__ zapisuje kazda kamere, podglad bierze read_latest() (peek, nie czysci new_frame_event, petla sterowania dostaje te same klatki). Przyczyna, dla ktorej wczesniej sie nie dalo: kamera na wylacznosc jednego procesu, rs_mjpeg_server.py + lerobot = Couldn't resolve requests. act_pick.py --preview-port (domyslnie 8081, 0 = wylacz). Testy: tests/test_cam_preview.py (6), test_act_pick.py (+2), 158 zielonych. Laptop: prawdziwy lerobot OpenCVCamera -> hook -> JPEG po HTTP dziala. Nie dziala / otwarte: nie sprawdzone na Pi z RealSense i lerobot-record (obciazenie CPU przy 10 fps podgladu). Nastepny krok: na Pi tools/cam_preview.py lerobot-record ..., otworzyc http://<IP_PI>:8081/, sprawdzic, czy nie ma frame is too old (jesli jest: --preview-fps 5). Sprzet: nie

2026-09-27 - frane + Claude - trening ACT na laptopie, dataset i wagi na masterze

Zrobione: Od teraz praca prosto na masterze (decyzja frane). Druga sesja nagrala na Pi so101_grasp2 (50 epizodow leaderem, kamera wrist; leader skalibrowany 12:30, kamera to D435 serial 030522070668). Kopia na laptop tar --exclude=tmp* przez ssh (pierwsza kopia w trakcie nagrywania miala uciety parquet). Dataset na masterze w datasets/so101_grasp2 (wideo Git LFS, 2 pliki po ~197 MB > limit 100 MB GitHuba). Laptop: lerobot[dataset, training], CUDA OK. Trening ACT (batch 8, AMP, num_workers 0, pyav): 3 kroki/s po podpieciu zasilacza; loss 26 -> 5.2 (100) -> 2.65 (500) -> 1.24 (2000). Checkpointy co 1000 na Pi (~/models/act_so101_grasp2/), 1000 na masterze (models/, LFS). Na Pi ACTPolicy.from_pretrained 30 s, 0.65 s na paczke 100 akcji (CPU) -> rollout lokalnie. tools/train_win.py (obejscie symlinku checkpoints/last, WinError 1314), pulapki w SETUP.md. Nie dziala / otwarte: rollout na robocie NIE sprawdzony w tej sesji (komenda w SETUP.md). Pierwszy trening padl po checkpoincie 500 (symlink). Laptop na baterii = GPU 210 MHz (krok 1.6 s zamiast 0.14 s). Zabijanie procesow po linii polecen trafilo wlasny push (README zawieral te slowa). LFS: 630 MB z 1 GB darmowego limitu zuzyte. Dokonczenie (15:05): loss 0.79 przy 3000 (l1 0.27). Sesja Claude zrestartowala sie ok. 14:55 i zabila trening (krok 3528), push i transfer; wznowienie z 3000 (--config_path .../003000/pretrained_model/train_config.json --resume=true) padlo na import torch: WinError 1114 przy torch\lib\shm.dll, takze bez CUDA i z PowerShell, RAM 21 GB wolne, pagefile pusty - przyczyna nieznana, najpewniej pomoze reboot. Checkpointy 2000 i 3000 dodane do models/ (LFS) i pushowane jednym pushem. Laptop znow przeskoczyl na hacker-bloc, wiec 3000 na Pi niepotwierdzone. Dokonczenie 2 (15:25): przyczyna restartu: Windows Kernel-Power 41 o 14:55:05 (twardy reset laptopa, najpewniej termiczny pod GPU+CPU). Skutki: 6 DLL torcha z niezgodnym sha256 wzgledem RECORD (reinstall z cache pip, 2 min, bez sieci), 2 z 3 mp4 w ~/datasets uszkodzone (pyav InvalidDataError na kroku 3360; odtworzone z kopii w repo, ktora zgadza sie z LFS). Wznowienie --resume=true z config_path checkpointu 3000 dziala bez symlinku last. Koniec: krok 4000, loss 0.575. Checkpointy 1000-4000 na Pi; 2000-4000 w models/ (LFS). Uplink hotspotu spadl do 50 KB/s, wiec obiekty LFS na GitHub ida godzinami - Pawel bierze wagi z Pi po LAN albo odpala rollout na Pi. Nastepny krok: rollout checkpointu 4000 na Pi z wylacznikiem (SETUP.md); jesli ruch w zla strone - ARM_FRAMES krok 1. Wiecej epizodow (--resume=true) i druga statyczna kamera, jesli polityka nie generalizuje po polozeniu szyszki. Sprzet: dotkniety zdalnie (odczyt kamery lerobot-find-cameras na Pi, kopiowanie plikow; ramie nie ruszane)

2026-09-27 - frane + Claude - diagnoza padnietego treningu ACT, wznowienie

Zrobione: Pytanie frane "co sie dzieje z trenowaniem, wznowic?". Stan: run2 (C:/Users/frane/outputs/act_so101_grasp2_run2) zabity przy kroku 3528 (restart sesji ~14:55), checkpointy 1000/2000/3000 z training_state cale. Blad import torch (WinError 1114 shm.dll) z poprzedniej sesji to NIE uszkodzony torch: pliki torch 2.11+cu128 zgodne z RECORD (11821 plikow), reczne ladowanie wszystkich DLL z torch/lib przechodzi. Import pada TYLKO wewnatrz sandboxa narzedzia Bash/ PowerShell w Claude Code; z wylaczonym sandboxem (dangerouslyDisableSandbox) import torch + CUDA + matmul dzialaja. Przeinstalowanie torcha (15:12, torch_reinstall.log) bylo niepotrzebne. Wznowienie: python tools/train_win.py --config_path=<run2>/checkpoints/003000/pretrained_model/train_config.json --resume=true dziala BEZ symlinku last (lerobot 0.6.1 bierze katalog checkpointu z config_path; "Resuming data order at epoch 1, sample 1544"). Odpalone 15:17:10 jako proces odlaczony (Start-Process, przezywa restart sesji), do 7000 krokow. Nie dziala / otwarte: 20 s pozniej DRUGA sesja Claude (worktree robot-pinecone-test-plan) wznowila ten sam checkpoint do tego samego katalogu z --steps=4000 i do tego samego pliku act_grasp2_run4.log (ta sama numeracja) - oba procesy dzielily GPU (1.7 zamiast 3.3 kroku/s) i obydwa zapisalyby checkpoints/004000 w tej samej chwili. Moj proces zabity (duplikat), trening drugiej sesji zostawiony: 15:24:25 checkpoint 4000 (loss 0.575 (l1 0.255)), koniec. Kroki 4000 -> 7000 NIE trenowane; 4000 lezy tylko na laptopie (.../act_so101_grasp2_run2/checkpoints/004000). Commity z checkpointami 2000/3000 (models/, LFS, branch frane/act-training w tamtym worktree) NIE sa na origin (push nie doszedl; 2 x 207 MB przy 630 MB z 1 GB limitu LFS - kolejne checkpointy do LFS sie nie zmieszcza, wagi na Pi przez scp jak w SETUP.md). Pulapka: dwie sesje przy jednym GPU/katalogu outputs - przed startem treningu Get-CimInstance Win32_Process | ? Name -eq python.exe i wlasna nazwa logu. 15:30 wznowienie 4000 -> 7000 (--config_path=.../004000/... --resume=true --steps=7000, 3.4 kroku/s, loss 0.52 przy ~4300) ZATRZYMANE 15:34 na prosbe frane (nie obciazac laptopa) przy kroku ~4413, przed checkpointem 5000 - te ~400 krokow przepadlo, stan nadal = checkpoint 4000. Log act_grasp2_run5_to7000.err. 15:42 wznowienie od 004000 raz jeszcze (run6), na prosbe frane pauza 15:52-15:57 przez NtSuspendProcess (GPU 0 %, postep zachowany), potem laptop na baterii = 1.1 kroku/s (36 W), po zasilaczu 3.5 kroku/s. 16:05 KONIEC: krok 7000, loss 0.301 (l1 0.198, kld 0.010); checkpointy 5000/6000/7000 w .../act_so101_grasp2_run2/checkpoints/ (laptop). Loss po krokach: 3000 0.79 -> 4000 0.575 -> 7000 0.301. Log act_grasp2_run6_to7000.err. Nastepny krok: wagi 7000 na Pi przez scp (SETUP.md), rollout z wylacznikiem; jesli ruch w zla strone - ARM_FRAMES krok 1. Checkpoint 7000 NIE do LFS (limit 1 GB). Sprzet: nie

2026-09-27 - pawel120 + Claude - panel zbiorczy robota (wizytowka)

Zrobione: tools/robot_panel.py (:8090) + robot_panel.html: jeden panel zamiast trzech okien SSH (panel.md). Nadzorca uslug pinecone_bot/supervisor.py (start/stop SIGINT -> terminate -> kill, logi w pamieci i logs/<usluga>.log, usluga odpalona recznie w SSH widoczna jako "poza panelem" i nie startowana drugi raz, zdrowie Pi z /proc i /sys, liczby do sekcji "co zbudowalismy": testy, linie kodu, moduly, epizody datasetow, commity). Kamera: pinecone_bot/vision_feed.py + tools/vision_web.py (:8020, MJPEG w 4 widokach, /api/detections z liczba cale/uciete, odlegloscia z glebi, historia 60 s, zapis klatki do frames/panel/; zrodlo RealSense, plik, sim albo URL JPEG). tools/arm_web.py: CORS wpuszcza tez :8090. --demo na laptopie: ramie --fake, kamera z symulatora z szyszkami w polu widzenia (prog HSV z domyslnego configu, bo prog z pinecone_config.json jest pod prawdziwe szyszki). Tryb /show na projektor (ciemny, bez sterowania). Testy tests/test_vision_feed.py (8), tests/test_robot_panel.py (11). Nie dziala / otwarte: nic nie odpalone na Pi. Kamere RealSense trzyma jeden proces: panel z kamera nie razem z rs_mjpeg_server.py, pinecone_bot.main ani lerobot-record (wtedy --vision-source http://...jpg). Stan maszyny stanow (SEARCH/APPROACH/...) w panelu jest schematem, nie na zywo: brain.py nie wystawia stanu po HTTP. Nastepny krok: na Pi deploy/push_to_pi.sh (po merge), python tools/robot_panel.py --autostart, otworzyc http://<IP_PI>:8090, sprawdzic kamere, jog i WASD z wylacznikiem w rece; potem ewentualnie jako usluga systemd. Sprzet: nie

2026-09-26 - pawel120 (Claude) - robot wjechal w ramie; cofniety heartbeat z klawiszami, predkosc /2

Zrobione: Po wdrozeniu PR #33 (heartbeat niosl stan klawiszy) robot przy duzym opoznieniu hotspotu wjechal w ramie i je uszkodzil. Prawdopodobna przyczyna (Claude): opoznione heartbeaty dochodza seriami, stare "W wcisniete" po failsafe znow uruchamialy jazde, a puszczenie W przychodzilo pozniej. Dead-man mierzy czas DOTARCIA wiadomosci, wiec spoznione wiadomosci wygladaja na swieze. Cofniete: heartbeat to znow goly ping (po failsafe trzeba wcisnac klawisz od nowa). web_control.py MAX_PWM 500 -> 250, panel ramienia krok 2 -> 1 st/tick (chwytak 4 -> 2). Zdalny STOP po awarii nie doszedl: Pi przestal odpowiadac (ping 100% strat). Nie dziala / otwarte: ramie uszkodzone - ocena. shoulder_lift czyta 116-128 st przy zakresie +-91.6, a wedlug uzytkownika staw jest fizycznie w zakresie -> podejrzenie rozjazdu Homing_Offset w serwie vs so101.json. Dodane tools/calibrate_joint.py (za zgoda uzytkownika): kalibracja JEDNEGO stawu bez lerobot calibrate - domyslnie tylko odczyt (rejestry serwa vs plik), --record S (torque OFF na stawie, reczny przejazd przez caly zakres, propozycja offsetu/limitow), --write (EEPROM + wpis stawu w so101.json po wpisaniu TAK, z kopia pliku). Matematyka sprawdzona na przypadku z 2026-09-25 (offset 1977, zakres ~1056..3039). NIE uruchomione - Pi nie odpowiada. Jazda po hotspocie z opoznieniem > 1 s jest niebezpieczna niezaleznie od kodu: dead-man nie odroznia spoznionych komend. Nastepny krok: ogledziny ramienia; Pi na dobrym zasilaniu; zanim ktos pojedzie zdalnie - znaczniki czasu w komendach jazdy (odrzucac spoznione) albo jazda tylko w zasiegu wzroku z wylacznikiem. Sprzet: dotkniety (robot wjechal w ramie - uszkodzenie)

2026-09-26 - pawel120 (Claude) - HOME pod kamere, chwytanie samym ramieniem na zywo

Zrobione: Nowy HOME = poza ustawiona recznie (odczyt ./arm.sh status): arm_control.HOME_POSE, pinecone_bot/arm.py, motions/home.json; test grasp_mid xfail (nagrany pod stary HOME), test STOP panelu jog w dol (HOME przy gornej granicy barku). pinecone_bot/grasp_table.py (tabela: piksel szyszki w HOME -> pozy nad/chwyt, najblizsza probka, ruch chwytu) + WaypointArm.play(motion), 7 testow. Na zywo przez ssh stdin (nic nie kopiowane na Pi), skrypty w tools/live_grasp/: uczenie reka srodkowej szyszki -> chwyt udany (odczyt chwytaka 6.8, szyszka w szczekach na zdjeciu); celowanie podstawa na obrazie + glebsze zejscie (elbow -4, wrist +8) -> drugi udany chwyt. Automat z kolorem 11 prob, potem z glebia 4 proby: 0 udanych. Nie dziala / otwarte: (1) serwa: P=16, bark stoi na Max_Position_Limit (surowo 3052 = 88.4 st) - male komendy nie ruszaja, potrzebna korekta calkujaca (jest w skryptach). (2) serwo chwytaka przy scisku do 0 raz zniklo z magistrali ("Missing motor IDs: 6") - trzymac z mniejszym celem. (3) kamera na przedramieniu: szczeki w obrazie zaleza od nadgarstka; w pozycji "nad" przy lewej szczece jest cien stereo (glebia slepa), tam widzi tylko kolor. (4) po zmroku kolor bezuzyteczny (ekspozycja 100 ms, gain max - ciemno); glebia z laserem 360 dziala. (5) duza lezaca szyszka nie miesci sie w szczekach - spychana. (6) Moje bledy: reguly "uczenia" wyciagaly wnioski z zlych pomiarow (bark nie wykonywal komend, koncowka szczeki z mapy wysokosci liczona zle) - parametry dryfowaly zamiast sie poprawiac. Pi: raz OOM (svd bez full_matrices=False na 20k punktow). Nastepny krok: przy dziennym swietle: uczyc reka 2-3 szyszki (nad/chwyt) z zapisem zdjecia z pozycji "nad"; punkt celowania brac z tych zdjec, dopiero potem tools/live_grasp/run.sh. Wgrac nowy HOME na Pi (scp arm_control.py, pinecone_bot/arm.py, motions/home.json). Sprzet: dotkniety (ramie: ruchy na zywo, torque wylaczony na koniec; kamera: ustawienia lasera tylko w sesji)

2026-09-26 (noc) - pawel120 (Claude) - chwytanie z demonstracji, dom

Zrobione: Nagranie ruchu reka (2 min, 9 cykli chwyt -> sloik, stawy 30 Hz + zdjecia) i odtworzenie cyklu na ramieniu. Dwie sesje uczenia (robot robi zdjecie glebi w HOME, czlowiek chwyta reka, zapis pozy przy zacisku): 20 chwytow, 8 jednoznacznych. Model liniowy szyszka (kamera HOME) -> stawy, pick.py / pick_loop.py z poprawka po przepchnieciu. Proba korekty w pozie chwytu (grasp_servo.py) i podejscia od gory. Wszystko w tools/live_grasp/ + pi.sh (ssh stdin, bez plikow na Pi), dane bez zdjec w tools/live_grasp/data/, instrukcja docs/LIVE_GRASP.md. Nie dziala / otwarte: 0 udanych autonomicznych chwytow (ok. 15 prob): model ma blad ok. 6 cm (zostaw-jedna), szczeki trafiaja obok albo spychaja szyszke. Kamera na przedramieniu nie widzi szyszki, gdy szczeki sa nad nia. Etykiety sesji 1-2 niepewne (znikalo kilka szyszek naraz), rozne style chwytu. Kinematyka URDF nie zgadza sie z ramieniem (wysokosc szczek przy ziemi rozrzucona o 5 cm). Podstawa: limit EEPROM +-23 st. Pi raz sie zrestartowal (zasilanie z powerbanku). Nastepny krok: docs/LIVE_GRASP.md: czyste uczenie teach_clean.py (1 szyszka naraz, jeden styl, 12 pozycji, swiatlo), fit.py, test pick.py. Alternatywa: kamera na maszt. Sprzet: dotkniety (ramie: ruchy na zywo, torque wlaczony w HOME na koniec; kamera tylko odczyt)

2026-09-26 - pawel120 (Claude) - poradnik odpalania panelu (docs/PANEL.md)

Zrobione: Polaczenie z Pi krok po kroku i odpalenie paneli spisane w docs/PANEL.md (hotspot iPhone / kabel, szukanie IP, dwa terminale SSH: web_control.py + tools/arm_web.py, przegladarka, konczenie pracy, tabela bledow z dzisiejszej sesji). Link w README, notka w docs/SETUP.md, ze WiFi na Pi juz dziala. Na Pi: 136 testow zielonych, ./arm.sh status OK. Nie dziala / otwarte: robot-web.service nie zainstalowany (brak autostartu). Na Pi lezy tests/test_calibrate_target.py z niezmergowanego brancha claude/robot-pinecone-test-plan-e4ca8e (6 bledow, pomijac --ignore). push_to_pi.sh bez rsync nie usuwa starych plikow. Nastepny krok: zainstalowac autostart (deploy/setup_pi.sh krok 7) albo zostac przy recznym starcie w tmux. Sprzet: dotkniety (Pi: SSH, testy, start paneli przez uzytkownika; Claude tylko odczyt stanu)

2026-09-27 - pawel120 + Claude - drive_calib (kalibracja jazdy bez miarki)

Zrobione: tools/drive_calib.py + tests/test_drive_calib.py (9, cale tests zielone): 2x prosto (glebia RealSense do sciany przed/po), 2x obrot (phyphox, na zmiane lewo/prawo), pytanie operatora l/p; dopasowanie prostej pwm = p0 + s*v -> xiao_pwm_min/max i xiao_steer_min/max, znaki steer_sign i heading.sign, --write do configu. Nie dziala / otwarte: nie uruchomione na Pi. Dopiero po napisaniu znalezione istniejace prace na niezmergowanych branchach: pawel/base-calibration (base_test --measure, landmarks.py), frane/gyro-rate-loop (turn_loop.py: stala tabela w->PWM nie opisze hovera), frane/mapa-d435 (localize.py + zygzak.py, jazda po mapie RTAB-Map). Pulapka: bez rsync deploy/push_to_pi.sh idzie przez scp i nadpisuje na Pi motions/drop_box.json (tylko na Pi) placeholderem. Nastepny krok: zdecydowac, ktora kalibracja/jazda zostaje (raczej zygzak po mapie z frane/mapa-d435); Xiao wpiac z powrotem (teraz w jego USB jest leader), test na robocie z wylacznikiem. Sprzet: nie

2026-09-27 - pawel120 (Claude) - panel: zbieranie ACT + sloik

Zrobione: Branch pawel/panel-sloik: przycisk "Zbierz szyszke" w tools/robot_panel.py (zadanie act_pick.py, wagi 007000; panel zatrzymuje ramie i kamere na czas chwytu i sam je wznawia, odmawia gdy chodza poza panelem; STOP i "Przerwij" zabijaja grupe procesow, wiec tez lerobot-rollout). Nowy ruch motions/sloik.json ze sciezki nagranej reka (tools/live_grasp/data/jar_cycle.json, JAR_UP/JAR_BACK z pick.py); act_pick.py wrzuca nim zamiast placeholdera drop_box. grasp_mid i drop_box z "panel": false - schowane w panelu ramienia. Testy: 308 zielonych, UI w --demo. Wczesniej w sesji: panel na Pi po kablu 192.168.137.5 (Pi zrestartowalo sie ok. 16:03), prog HSV na zewnatrz wpisany tylko na Pi (lo [104,40,40] hi [130,125,200], kopia starego configu .bak-20260927-1620-hala). Zygzak nie ruszyl: phyphox na iPhonie nie odpowiadal (port 80 zamkniety, ping OK). Nie dziala / otwarte: przycisk na robocie niesprawdzony; wagi 007000 na Pi niekompletne (2 MB, zawieszony tar od 16:22); ACT nie sprawdza chwytu przed sloik; prog HSV nie w repo. Na laptopie stash@{0} (docs + kopie modeli, identyczne z origin/master) i .git/index.lock po przerwanym git pull (lock usuniety). Nastepny krok: review + merge, push na Pi, wagi 007000, test z wylacznikiem: najpierw sloik z panelu ramienia. Sprzet: dotkniety (Pi: start panelu, restart kamery, prog HSV w configu; ramie i baza nie ruszane przez Claude)

FilesExpand file tree

LOG.md

Latest commit

History

LOG.md

File metadata and controls

Log sesji

Log sesji

2026-09-25 - sesja Claude (hoverboard control panel)

2026-09-25 - sesja Claude (ramie SO-101 + kamera, planowanie pick-and-place)

2026-09-25 - sesja Claude (podglad na zywo RealSense D415)

2026-09-25 - sesja Claude (Raspberry Pi 5: architektura + setup zdalnego sterowania)

2026-09-25 - sesja Claude (Tomek: wykrywanie szyszek po glebi + dystans, dojazd, plan chwytu)

2026-09-25 - sesja Claude (Pi 5: pierwsze uruchomienie calosci + proby chwytu)

2026-09-25 - Replay chwytu + naprawa kalibracji barku

2026-09-25 - Chwyt z kamera: skan -> podjazd -> replay (nieudany, 5 prob)

2026-09-25 - Mapa RTAB-Map z nagrania pokoju (issue #7, sesja Claude na laptopie)

2026-09-26 - pinecone_bot: deterministyczny stos (PR #14) + poprawki z issue #15

2026-09-25 - stan na koniec sesji (dawny NASTEPNY KROK)

Jak sie polaczyc z Pi (stan na koniec sesji)

Jak odpalac (w sesji SSH na Pi)

2026-09-25 - poprzedni NASTEPNY KROK (sesja detekcja + dystans)

2026-09-26 - pawel120 (Claude) - glebia kamery w nizszej rozdzielczosci

2026-09-26 - pawel120 (Claude) - kalibracja HSV na szyszkach

2026-09-26 - pawel120 (Claude) - webowy panel recznego sterowania ramieniem

2026-09-26 - pawel120 (Claude) - panel ramienia bez HOME (kamera na ramieniu)

2026-09-26 - pawel120 (Claude) - blokada jogu poza zakresem, heartbeat jazdy z klawiszami

2026-09-26 - Kajud (Claude) - panel: nagrywanie ruchu i sekwencje jazda+ramie

2026-09-26 - pawel120 (Claude) - jog XYZ ramienia w panelu

2026-09-26 - pawel120 (Claude) - robot wjechal w ramie; cofniety heartbeat z klawiszami, predkosc /2

2026-09-26 - tomek - sciezka S w POKRYCIU

2026-09-26 - pawel120 (Claude) - wylacznik STOP na telefon

2026-09-26 - frane (Claude) - polaczenie z Pi po WiFi + kalibracja HSV V/H

2026-09-26 - pawel120 (Claude) - podglad glebi jak RealSense Viewer

2026-09-27 - frane + Claude - pasy po kursie z telefonu

2026-09-27 - frane + Claude - telefon jako zyroskop dziala

2026-09-27 - frane + Claude - kod z Pi z powrotem w repo (frane/pi-sync)

2026-09-27 - frane + Claude - --no-arm do testow jazdy

2026-09-27 - frane + Claude - zyroskop z telefonu, petla obrotu, kalibracja glebia (branch frane/lidar)

2026-09-27 - frane + Claude - mapa ogrodu D435, zygzak po mapie (branch frane/mapa-d435)

2026-09-27 - frane + Claude - research gotowych polityk lerobot

2026-09-27 - frane + Claude - lerobot do ACT: instalacja laptop + Pi

2026-09-27 - frane + Claude - zera stawow vs URDF i kalibracja reka-oko (narzedzia)

2026-09-27 - frane + Claude - wolniejszy skret w panelu

2026-09-27 - frane + Claude - ACT: leader, nagrywanie, act_pick

2026-09-27 - pawel120 + Claude - podglad kamery w procesie lerobot

2026-09-27 - frane + Claude - trening ACT na laptopie, dataset i wagi na masterze

2026-09-27 - frane + Claude - diagnoza padnietego treningu ACT, wznowienie

2026-09-27 - pawel120 + Claude - panel zbiorczy robota (wizytowka)

2026-09-26 - pawel120 (Claude) - robot wjechal w ramie; cofniety heartbeat z klawiszami, predkosc /2

2026-09-26 - pawel120 (Claude) - HOME pod kamere, chwytanie samym ramieniem na zywo

2026-09-26 (noc) - pawel120 (Claude) - chwytanie z demonstracji, dom

2026-09-26 - pawel120 (Claude) - poradnik odpalania panelu (docs/PANEL.md)

2026-09-27 - pawel120 + Claude - drive_calib (kalibracja jazdy bez miarki)

2026-09-27 - pawel120 (Claude) - panel: zbieranie ACT + sloik