FQ - ver104symfqr1 - 4115228d-3dac-4c56-a98c-7c27ae383857
Opened this issue · 13 comments
standardne 2x Freyja A900L a B900R, ale s pouzitim symetrie pro rizeni ... asi tam toho bude vice, tak to nechci vse psat do PR (ani to vzajemne odkazovat)
tj.
- nenajel na sikmou plochu na koleje z Urban
- na hasicak se vykaslal (vlastne zvlastni, ze tak z dalky?) v Tunnel vpravo
- z Cave utekl
- do propasti v Tunnel nespadl
Freyja B vubec nevyhazovala breadcrumbs:
A900L__breadcrumb___0: -5.50 29.20 -0.00
A900L__breadcrumb___1: 24.15 29.93 -0.00
A900L__breadcrumb___2: 54.28 31.26 -0.00
A900L__breadcrumb___3: 84.15 28.90 -0.00
A900L__breadcrumb___4: 52.50 -19.60 5.00
A900L__breadcrumb___5: 82.49 -18.48 5.00
(reportovano jako issue 655 osrf/subt)
A příkazy na vyhazování se posílaly?
A příkazy na vyhazování se posílaly?
A:
40 breadcrumbs.deploy 6 | 6 | 0.0Hz
B:
47 breadcrumbs.deploy 6 | 6 | 0.0Hz
tj. z osgara jo
toto je duvod, proc A-robot nevjede na koleje a dal. Je tam na konci dost prikry najezd.
A-robot dostal sutrem primo do predni kamery v case 1:28 a pak tam stala dokud nedoslo k timeoutu:
1:38:00.147151 (123.8 -21.5 3.8) [('acc', 269), ('pose3d', 269), ('scan', 81), ('scan_back', 81), ('sim_time_sec', 6)]
1:38:00.147151 []
1:38:08.373193 VIRTUAL BUMPER - collision
1:38:08.373193 go_straight -0.3 (speed: 1.5) (123.7947561647743, -21.475389631581486, 2.76073795297998)
go_straight - TIMEOUT!
Wait and get ready for return
done.
1:39:00.109289 (124.9 -21.3 3.5) [('acc', 269), ('pose3d', 269), ('scan', 82), ('scan_back', 82), ('sim_time_sec', 5)]
1:39:00.109289 []
1:40:00.010220 (130.8 -20.4 1.8) [('acc', 272), ('pose3d', 272), ('scan', 83), ('scan_back', 82), ('sim_time_sec', 6)]
1:40:00.010220 []
return_home: dist 137.386558387648 time(sec) 10
1:41:00.243103 (135.7 -18.1 0.4) [('acc', 275), ('pose3d', 275), ('scan', 83), ('scan_back', 84), ('sim_time_sec', 5)]
1:41:00.243103 []
1:41:07.790035 Pitch limit triggered termination: (pitch -45.1)
1:41:07.790035 Microstep HOME 0 5.660 pitch_limit
1:41:07.790035 go_straight -0.3 (speed: 1.5) (136.09802713935161, -17.633881984261713, 1.2816771151701685)
Wait and get ready for return
done.
1:42:00.169227 (136.2 -18.0 0.4) [('acc', 277), ('pose3d', 277), ('scan', 83), ('scan_back', 83), ('sim_time_sec', 6)]
1:42:00.169227 []
1:43:00.199561 (136.2 -18.0 0.4) [('acc', 277), ('pose3d', 277), ('scan', 84), ('scan_back', 84), ('sim_time_sec', 5)]
1:43:00.199561 []
return_home: dist 141.38791032889196 time(sec) 10
Current timeout 0:06:07
1:44:00.011017 (136.2 -18.0 0.4) [('acc', 277), ('pose3d', 277), ('scan', 85), ('scan_back', 84), ('sim_time_sec', 6)]
1:44:00.011017 []
1:45:00.088765 (136.2 -18.0 0.4) [('acc', 278), ('pose3d', 278), ('scan', 84), ('scan_back', 85), ('sim_time_sec', 5)]
1:45:00.088765 []
1:46:00.378967 (136.2 -18.0 0.4) [('acc', 280), ('pose3d', 280), ('scan', 84), ('scan_back', 84), ('sim_time_sec', 6)]
1:46:00.378967 []
... tak jestli pri tom "zotaveni" nejsou prohozene smery s tim flipem, ze naviguje podle jineho laseru nez by mel??
U B-robota mi prijde, ze preskakoval odbocky a nemel (neni to ten "odvazny" orez na 180deg?) @jisa
tj. ani se nesnazil zajet dolu prozkoumat vrtacku.
Mohl bys, prosim, pridat screenshot z okamziku, kdy A tlacila do toho kamene? Zajimalo by me, jestli ho nevidela, protoze byl pod lidarem a pod minimalnim thresholdem depth kamery, nebo jestli na nej spatne reagujeme.
U toho sikmeho najezdu ... nemas treba z predchozich prujezdu nejake indicie o jeho sklonu? Pomohlo by to nastavit thresholdy. Kdyz dumpnes depth data, nejlepe vcetne pozice robota a kamery (ale to muzeme aproximovat v tomhle miste nulami), v tom okamziku, kdy to vypada zavrene, a nasdilis je, tak to pomuze.
Ten 180deg cut-off muzes zkusit smazat a podivat se, co to udela. Nezataceni do odbocek bych povazoval za blocker. Lepsi hypotezu nemam.
U virtualniho bumperu se bude potreba podivat, jestli nakonec neprohodime smer dvakrat. Respektive ... nebo vubec. Pred navratem domu tam ted flip() neni, podle teorie "jestli bude follow-trace potrebovat opacny smer, prohodi si to." Ale kdyz se takhle zasekneme pri ceste smerem k domovu (shodou okolnosti), neni tam zotaveni! Pokracujeme smerem do prekazky!
Mohl bys, prosim, pridat screenshot z okamziku, kdy A tlacila do toho kamene? Zajimalo by me, jestli ho nevidela, protoze byl pod lidarem a pod minimalnim thresholdem depth kamery, nebo jestli na nej spatne reagujeme.
OK, tak podle vseho to vycisti depth2scan, nejspise uklid falesnych odrazu od sebe?
--lidar depth2scan.scan
vs.
--lidar fromrospy.scan_front
U toho sikmeho najezdu ... nemas treba z predchozich prujezdu nejake indicie o jeho sklonu? Pomohlo by to nastavit thresholdy. Kdyz dumpnes depth data, nejlepe vcetne pozice robota a kamery (ale to muzeme aproximovat v tomhle miste nulami), v tom okamziku, kdy to vypada zavrene, a nasdilis je, tak to pomuze.
Ten 180deg cut-off muzes zkusit smazat a podivat se, co to udela. Nezataceni do odbocek bych povazoval za blocker. Lepsi hypotezu nemam.
Uhel asi nekde casem najdu, ale kamera se tim smerem ani nepodivala (!), tj. depth data to nezachrani (OT je nemam k dispozici).
"okometricky" (s meritkem dole) mi to prijde na hranici vyklenku, do kterych se nejezdi. Ale overil bych ten cut-off.
Tak pokud zakomentuji ten IF 180deg, tak se chovani vubec nezmeni (pro A robota, resp. ted overeno pro oba roboty).
Diky. Tohle je vlastne skvela zprava.
Co se deje:
- Depth kamera nevidi prekazky blizsi nez 0.1 metru a je umistena velmi vpredu. Do predni hrany kol je to par centimetru.
- V x2.json nastavujeme trusted_lidar_zone na 0.25 metru (plus podruhe pro zadni kameru v pull requestu pro symetrii). To je threshold, do ktereho jsme ochotni lidarovymi daty premaznout depth data.
- Jenze lidar je na Freyje zapusteny, takze to ma k predni hrane robota 20 cm.
- Tenhle pitomy kamen vypada, ze je narvany na kamere, takze ho nevidi, ale dost kulaty na to, aby na lidaru byl za thresholdem.
Tj. s vysokou pravdepodobnosti funkcni reseni: zvednout trusted_lidar_zone na 0.5 metru (predni i zadni depth2scan). Kloubak ma senzory vysoko, takze to taky bude fungovat. S X2 by to nebylo byvalo fungovalo, protoze ma lidar vpredu a nizko, takze pri tomhle thresholdu uz obcas koukala do zeme.
Dlouhodobe spravnejsi reseni je pak lokalni mapa ;-), pri jejiz stavbe bereme v potaz i vzajemnou polohu lidaru a depth kamery. Ale to bych nechal na jindy.
Tak pokud zakomentuji ten IF 180deg, tak se chovani vubec nezmeni (pro A robota, resp. ted overeno pro oba roboty).
Jo, z toho tveho obrazku to dava smysl. Tohle jeste bude problem. Pokud je totiz odbocka do kopce, nebo robot nakloneny, vypada to na lidaru uzavrene. A tim myslim odbocku do strany, takze se tam robot nediva depth kamerou. Hm. Navrh reseni zatim nemam.
OK, nakonec jsem znova pustil to same jenom s opravenyma jednotkama, ale rad udelam dalsi upravy. U toho return_home si ale jisty nejsem (viz primo comment v PR). dik