RCL#3 LOG – development log

---

Indice

• RCL#3 LOG – development log
  • 15/08/2022 – setup repository – starter kit
  • 16/08/2022 – modello del robot
  • 17/08/2022 – move_base navigation
  • 18/08/2022 – pddl e manipulation unit – aruco
  • 21/08/2022 – alleggerimento – documentazione
  • 22/08/2022 – documentazione del progetto
  • 23/08/2022 – readme e deployment
  • 24/08/2022 – revisione documentazione
  • Note
    • utilizzo di move base
    • strano warning con move_base

---

• plantUML online

• un altro editor motlo carino per PlantText

• onlineGDB

15/08/2022 – setup repository – starter kit

nuovo assignment, nuova avventura:

• primo setup della repository

• COMMIT: “simil-fork from erl2”

• creazione di un nuovo log pulito (serve a me per riflettere e annotare cose che non so dove metterei altrimenti)

• il progetto per il perfezionamento della RAI è iniziato.

• customizzazione della documentazione (… il 2 diventa un 3?)

• COMMIT: “setup (docs)”

---

• importazione materiale del prof per il terzo assignment

• link starter kit per l’assignment

• modalità di sviluppo al nuovo giocattolo

  • ANZI, per il momento niente modalità di sviluppo

  • più avanti semmai ne inserirò una

• compila? compila (perfetto)

• e senza perdere tempo, voglio una documentazione per il nuovo nodo

  • uml

  • aggiungo anche una minima copde reference

• potrei avere qualche problema col nome dei services più avanti perchè purtroppo adesso /oracle_hint è un servizio, e non più un topic. servirà un remapping … o forse posso semplicemente cambiare nome del servizio nel mission manager, o fare un remapping da launch file

• COMMIT: “setup (starter kit with oracle documentation)”

---

prima di tutto serve avere funzionante il modello del robot. La cosa più ragionevole in questo momento è partire dall’installazione di MoveBasepassando per il modello del robot. Questo terzo assignment utilizzerà una versioneleggermente diversa del robot, equipaggiata con 3 telecamere e con MoveBase integrato. partiamo dal modello e passiamo da move_base; alle telecamere ci pensiamo dopo.

• creazione del nuovo modello URDF

• e creazione del nuovo maledettissimo pacchetto MoveIt (sperando di non combinare casini stavolta)

• la nuova versione del robot avrà come soprannome “hunter”

• adesso tutti i noiosissimi setup (pensa se il setup assistant funzionasse davvero … sarebbe un mondo magnifico no? e invece siamo qui)

  • fix del world file

  • “run” launch file (altro fix da segnare)

  • non avevo fixato RViz … dovrò farlo prima o poi

• direi che il pacchetto è pronto!

• …hmmm però aspetta: e che dire del mastino di Baskerville? che in inglese è the HOUD of baskerville? chiamarlo Hunter sarebbe … un’occasione mancata

  • e quindi, cambiamo tutti i nomi? certo che no.

• COMMIT: “working on robot model (robocluedo HUNTER)”

• e ci si rivede domani

---

16/08/2022 – modello del robot

cotinuiamo a lavorare sul modello del robot (oggi si fa poco…)

• il mio robot avrà ben 4 telecamere (giusto per complicare un po’ la situazione, ecco)

  • una frontale bassa

  • una sul cluedo link

  • un’altra a destra del robot

  • e un’altra a sinistra, un po’ come Spot

• prima il codice per applicare le videocamere

parte Gazebo URDF:

<!-- camera -->
<gazebo reference="camera_link">
<sensor type="camera" name="camera1">
  <update_rate>30.0</update_rate>
  <camera name="head">
	<horizontal_fov>1.3962634</horizontal_fov>
	<image>
	  <width>800</width>
	  <height>800</height>
	  <format>R8G8B8</format>
	</image>
	<clip>
	  <near>0.02</near>
	  <far>300</far>
	</clip>
	<noise>
	  <type>gaussian</type>
	  <mean>0.0</mean>
	  <stddev>0.007</stddev>
	</noise>
  </camera>
  <plugin name="camera_controller" filename="libgazebo_ros_camera.so">
	<alwaysOn>true</alwaysOn>
	<updateRate>0.0</updateRate>
	<cameraName>robot/camera1</cameraName>
	<imageTopicName>image_raw</imageTopicName>
	<cameraInfoTopicName>camera_info</cameraInfoTopicName>
	<frameName>camera_link</frameName>
	<hackBaseline>0.07</hackBaseline>
	<distortionK1>0.0</distortionK1>
	<distortionK2>0.0</distortionK2>
	<distortionK3>0.0</distortionK3>
	<distortionT1>0.0</distortionT1>
	<distortionT2>0.0</distortionT2>
  </plugin>
</sensor>
</gazebo> 

Dovrò aggiungere dei link per farci stare le videocamere…

• e andiamo a modificare il modello del robot

• la camera davanti bassa

  • creazione dei link nel modello URDF

  • compila? compila

  • e creazione della videocamera montata sul link

  • e ora vediamo se funge … e pare che funga

• voglio rivedere meglio la questione dei topic della videocamera

/robot/camera_front_low/camera_info
/robot/camera_front_low/image_raw
/robot/camera_front_low/image_raw/compressed
/robot/camera_front_low/image_raw/compressed/parameter_descriptions
/robot/camera_front_low/image_raw/compressed/parameter_updates
/robot/camera_front_low/image_raw/compressedDepth
/robot/camera_front_low/image_raw/compressedDepth/parameter_descriptions
/robot/camera_front_low/image_raw/compressedDepth/parameter_updates
/robot/camera_front_low/image_raw/theora
/robot/camera_front_low/image_raw/theora/parameter_descriptions
/robot/camera_front_low/image_raw/theora/parameter_updates
/robot/camera_front_low/parameter_descriptions
/robot/camera_front_low/parameter_updates

• il sistema funziona! Ora aggiungiamo quella sul braccio

  • compilare compila

  • e prova con rviz gazebo … ruotata nel verso sbagliat! … e ok

  • telecamera laterale 1 … ok

  • e telecamera laterale 2 … ok

  • genera? genera

  • e in RViz pare funzioni tutto come dovrebbe

• COMMIT: “working on robot model (added cameras)”

---

e adesso, installazione di ArUco e openCV

• prima di tutto, voglio avere delle versioni mie di OpenCV installate sulla macchina, quella effettivamente data per l’assignment (sarà un errore? in caso ho il backup della ws intera)

• installazione di openCV per ROS

  • compila? compila.

• meglio scriversi un piccolo documento dove spiego come installare queste cose

• importazione dei modelli arUco

• compilazione … compila

• e adesso proviamo se i markers funzionano

  • funge!

  • meglio copiare tutt i markers anche nel package worlds

• COMMIT: “setting up openCV and ArUco”

---

adesso che ArUco c’è, possiamo iniziare il lavoro serio

• questo nuovo progetto richiede … un NUOVO PACKAGE

catkin_create_pkg robocluedo_vision roscpp rospy std_msgs geometry_msgs nav_msgs sensor_msgs erl2 exp_assignment3 aruco aruco_msgs dynamic_reconfigure cv_bridge image_transport 

• eeee documentazione, subito

• COMMIT: “working on vision (setup package)”

---

17/08/2022 – move_base navigation

iniziamo subito da move_base, per passare poi al navigation system per il nuovo assignment. ci sarà da rivedere anche il manipulation system, dato che le postures del robot sono cambiate. (magari documentare le postures?)

• installazione di move_base (dalla vecchia versione di erl2)

• devo anche fare una modifica a come viene lanciato RViz in modo da poter scegliere il file di configurazione

• ora dovrebbe esserci tutto: posso provare il navigation stack … e funziona a primo colpo signori

• meglio annotarsi due cose nella documentazione del robot riguardo il navigation stack

  • (mi ringrazierò in futuro, quando dovrò installare di nuovo move_base su un altro robot)

• ultima prova, giusto per capire se è tutto a posto

• COMMIT: “working on robot model (setup move base)”

---

ora, il navigation controller del robot

• anzitutto, il nodo che deve eseguire la navigation: penso avrà lo stesso meccanismo dei nodi di bug_m : trigger, e wait del segnale, e struttura come macchina a stati

• nuovo nodo : move_base_nav.py

  • prima struttura del nodo

  • (c’è voluto un po’ più del previsto…)

• prima di andare avanti, voglio vedere se il nodo si avvia e non crasha

# shell 1
roslaunch robocluedo_robot_hunter run.launch 2>/dev/null

# shell 2
rosparam set des_pos_x 0.0
rosparam set des_pos_y 0.0
rosparam set des_yaw 0.0
rosrun robocluedo_movement_controller move_base_nav.py

# shell 3
rosservice call /nav_stack_go_to_point_switch "data: true" 
rosservice call /nav_stack_go_to_point_switch "data: false" 

• e ora torniamo ad implementare questo bellissimo nodo

• COMMIT: “workign on nvigation (implementation of the new navigation service)”

---

e torniamo al lavoro sul navigation system

• occorre aggiungere la “action” move_base…

  • …che tratterò come un topic per il momento, perchè sono pigro

  • recupero la documentazione su move_base dal vecchiop assignment

  • … e ovviamnete manca la parte su come inviare la richiesta di cancellazione tramite topic, dannato me

• ALT FERMI TUTTI c’è un grosso problema con move_base … al solito

  • il robot continua ad indietreggiare quando move_base è attivo

  • la traiettoria calcolata parte dal retro del robot … eppure go to point ha sempre funzionato, quindi perchè move_base da il comando invertito? forse un problema col modello urdf?

  • che genere di twist viene inviato da move_base?

    linear: 
      x: -0.1
      y: 0.0
      z: 0.0
    angular: 
      x: 0.0
      y: 0.0
      z: 0.0
    

  • non è un problema del modello: è esattamente identico a quello del precedente assignment (erl2 quello vecchio), funzionava, deve continuare a funzionare

  • … se provassi a cambiare il controller?

  • potrebbe esserci un problema col local planner

  • credo che il problema possa essere più stupido di quel che sembra: il robot non riesce a curvare per via delle ruote dietro … l’altro nodo ignorava questo aspetto dinamico, ma a quanto pare a move_base non sfugge proprio nulla. ci fosse un modo per diminuire l’attrito delle ruote dietro e renderle così indifferenti alla rotazione…

• il problema è più fastidioso di quel che sembra: nemmeno annullando l’attrito si riesce. il local planner nella visualizzazione RViz mostra un buco nero davanti al robot, segno che ha individuato un ostacolo, perciò indietreggia… il problema è che non c’è alcun ostacolo!

  • il problema potrebbe essere nel laucnher? ha senso?

    • l’unica cosa regolabile da launch è GMapping, quindi no

  • allora il problema è in qualche configuration file…

  • prima però voglio provare a muovere il robot inviando direttamente un comando su cmd_vel e vedere che succede…

    • muoversi si muove…

• … e mi viene un altro dubbio:

  • i sensori laser vanno ad incidere sulle ruote di fianco … questo in effetti potrebbe portare MoveBase a vedere degli ostacoli attorno al robot, e preferire così un certo tipo di movimento per evitare l’ostacolo

  • la soluzione potrebbe quindi essere spostare il sensore laser in avanti…

  • provo …

  • ora che ho modificato il modello, passo a provare con move base … E PROBLEMA RISOLTO SIGNORI: ora va dove voglio io!

• COMMIT: “working on robot model (move_base laser issue)”

• e andiamo avanti con lo sviluppo del nodo

  • quindi … questa cancellazione?

  • e torniamo ad implementare

  • (oggi sto facendo una fatica incredibile…)

• è arrivata la parte migliore: testare…

# shell 1
roslaunch robocluedo_robot_hunter run.launch world_name:=square_room.world 2>/dev/null

# shell 2
rosparam set des_pos_x 0.0
rosparam set des_pos_y 0.0
rosparam set des_yaw 0.0
rosrun robocluedo_movement_controller head_orientation.py

# shell 3
rosrun robocluedo_movement_controller move_base_nav.py

# shell 4
rosparam set des_pos_x 2.0
rosparam set des_pos_y 0.0
rosparam set des_yaw 0.0
rosservice call /nav_stack_go_to_point_switch "data: true" 
sleep 30
rosservice call /nav_stack_go_to_point_switch "data: false" 

rosparam set des_pos_x 0.0
rosparam set des_pos_y -1.5
rosparam set des_yaw 0.0
rosservice call /nav_stack_go_to_point_switch "data: true" 
sleep 30
rosservice call /nav_stack_go_to_point_switch "data: false" 

• le cose ora iniziano a funzionare… ultimo test:

# shell 1
roslaunch robocluedo_robot_hunter run.launch world_name:=square_room.world 2>/dev/null

# shell 2
rosparam set des_pos_x 0.0
rosparam set des_pos_y 0.0
rosparam set des_yaw 0.0
rosrun robocluedo_movement_controller head_orientation.py &
rosrun robocluedo_movement_controller move_base_nav.py

# shell 3
rosparam set des_pos_x 2.0
rosparam set des_pos_y 0.0
rosparam set des_yaw 0.0
rosservice call /nav_stack_go_to_point_switch "data: true" 
sleep 30
rosservice call /nav_stack_go_to_point_switch "data: false" 

rosparam set des_pos_x 0.0
rosparam set des_pos_y -1.5
rosparam set des_yaw 0.0
rosservice call /nav_stack_go_to_point_switch "data: true" 
sleep 30
rosservice call /nav_stack_go_to_point_switch "data: false" 

rosparam set des_pos_x 0.0
rosparam set des_pos_y 2.0
rosparam set des_yaw 0.0
rosservice call /nav_stack_go_to_point_switch "data: true" 
sleep 30
rosservice call /nav_stack_go_to_point_switch "data: false" 

rosparam set des_pos_x -2.0
rosparam set des_pos_y 0.0
rosparam set des_yaw 0.0
rosservice call /nav_stack_go_to_point_switch "data: true" 
sleep 30
rosservice call /nav_stack_go_to_point_switch "data: false" 

• e funge.

• COMMIT: “working on navigation (move_base navigation node tested, ready to use)”

---

e ora il controller, altro dolore:

• implementazione del controller (molto simile a quello di bug_m)

• compila? alla prima senza errori, sono un campione

• e ora, prova pratica

# shell 1
roslaunch robocluedo_robot_hunter run.launch world_name:=square_room.world 2>/dev/null

# shell 2
roslaunch robocluedo_movement_controller navigation_system.launch

# shell 3
rosrun robocluedo_movement_controller navigation_manager

# shell 4
rosservice call /navigation_manager/set_algorithm "algorithm: 1
enabled: false"

rosservice call /navigation_manager/navigation "target:
  x: 1.5
  y: 2.0
  yaw: 1.0
force_enable: false" 

# this sequence moves the robot
rosservice call /navigation_manager/set_algorithm "algorithm: 1
enabled: true"

rosservice call /navigation_manager/navigation "target:
  x: -1.5
  y: 2.0
  yaw: 1.0
force_enable: false" 

# this sequence moves the robot EVEN IF the component has been turned off
rosservice call /navigation_manager/set_algorithm "algorithm: 1
enabled: false"

rosservice call /navigation_manager/navigation "target:
  x: 1.5
  y: -2.0
  yaw: 1.0
force_enable: true" 

• FUNZIONAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

• COMMIT: “working on navigation (controller implemented and tested, ready to use)”

---

18/08/2022 – pddl e manipulation unit – aruco

oggi, manipulation controller

• anzitutto, documentazione riguardo le poses del robot

• nel manipulation controller bisogna solo cambiare i codici e i nomi delle postures, tutto qui

  • già solo cambiando i nomi delle costanti il lavoro è finito

  • compila? e compila

giusto un piccolo test per capire se ho scritto bene i nomi delle costanti (impossibile escludere qualche errore stupido)

# shell 1
roslaunch robocluedo_robot_hunter run.launch world_name:=square_room.world 2>/dev/null

# shell 2
rosrun robocluedo_movement_controller manipulation_controller 2>/dev/null

# shell 3
rosservice call /tip_pos "command: 0" 
sleep 2
rosservice call /tip_pos "command: 1" 
sleep 2
rosservice call /tip_pos "command: 2" 
sleep 2
rosservice call /tip_pos "command: 3" 
sleep 2
rosservice call /tip_pos "command: 4" 
sleep 2
rosservice call /tip_pos "command: 5" 
sleep 2
rosservice call /tip_pos "command: 6" 
sleep 2
rosservice call /tip_pos "command: 7" 
sleep 2
rosservice call /tip_pos "command: 8" 
sleep 2

# UNKNOWN POSE
rosservice call /tip_pos "command: 9" 
sleep 2

# UNKNOWN POSE
rosservice call /tip_pos "command: -1" 
sleep 2

• funzionare funziona

• COMMIT: “working on manipulation (new postures)”

---

• … ma devo ammettere che non mi piace molto come il robot fa il planning, e non mi convince il fatto di non riuscire a fare il planning cartesiano, non mi convince proprio

• vorrei provare a fare una modifica dell’attuale nodo (in caso, backup e si ritorna a quello funzionante)

  • anzitutto, backup

  • e importazione dell’attuale documentazione MoveIt in questo spazio di lavoro

  • voglio provare con una configurazione più precisa di moveit

  • iniziamo dal definire un end effector

  • compila? compila

  • … ma la definizione dell’end effector non funziona: penso che il lavoro vada fatto da moveit setup assistant, proviamo

  • ho provato ad aggiungere l’end effector da setup assistant, vediamo che fa …

  • sembra acer accettato l’end effector!

per creare l’end effector nel setup assistant: - crea un group che contiene solo un link (usa le advanced options), cluedo_link, chiamalo ee, solite impostazioni per i groups - definisci un end effector di nome cluedo_ee con group ee parent link arm_group e parent link arm_link_03 - aggiorna il package (non serve aggiornare i gazebo, demo e demo_gazebo, dovrai riaggiornare solo i controllers yaml)

e ora vediamo se funge…

• aggiungo al messaggio il target dell’end effector

• e aggiungo anche il planning cartesiano

  • per ora, facile così

  • compila?

fastidiosissimo:

The dependencies of the message/service 'robocluedo_movement_controller_msgs/ManipulatorPosition' have changed. Please rerun cmake.
make[2]: *** [erl3/robocluedo_movement_controller_msgs/CMakeFiles/_robocluedo_movement_controller_msgs_generate_messages_check_deps_ManipulatorPosition.dir/build.make:57: erl3/robocluedo_movement_controller_msgs/CMakeFiles/_robocluedo_movement_controller_msgs_generate_messages_check_deps_ManipulatorPosition] Error 1
make[1]: *** [CMakeFiles/Makefile2:24138: erl3/robocluedo_movement_controller_msgs/CMakeFiles/_robocluedo_movement_controller_msgs_generate_messages_check_deps_ManipulatorPosition.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

e la soluzione ancora meglio… qui

per risolvere questa roba improbabile è bastato ritoccare il cmake (ma veramente, invertire due dipendenze! e nient’altro) per far scattare la parte della compilazione che lui non faceva perchè … motivo ignoto. ma si può? cazz

• comunque, ora compila

• e test … niente, il planner non riesce a trovare la traiettoria

• direi di tornare alla versione precedente.

• COMMIT: “working on manipulation (trying something more … but not working)”

---

ora la parte noiosa: il package ROSPlan

• aggiornamento della topologia nel pddl

  • la topologia del terzo assignmento comprende 6 waypoint (più un centro, è sottinteso)

    Room1: (-4,-3)
    Room2: (-4,2)
    Room3: (-4,7)
    Room4: (5,-7)
    Room5: (5,-3)
    Room6: (5,1)
    

  • modifica al problem pddl

  • risolve? direi proprio di sì. fatto.

• aggiornamento della kb interface per tenere conto dei 6 waypoints

  • aggiornamento

  • e si compila

• l’oracolo dovrebbe pubblicare i markers anche qui (aggiungere la pubblicazione dei marker)

  • solito meccanismo, prendi dall’assignment 2 … o forse sarebbe meglio fare un nodo ausiliario che pubblichi i markers?

  • ecco sì, sarebbe meglio: non voglio modificare il nodo del professore, il gioco è anche un po’ quello, no?

  • e quind, nuovo nodo: marker_publisher (c++, per motivi di profonda … pigrizia)

  • implementazione

  • compila? compila.

  • e adesso proviamolo un po’

# shell 1
roslaunch robocluedo_robot_hunter run.launch world_name:=indoor.world 2>/dev/null

# shell 2
rosrun exp_assignment3 simulation_marker_publisher

• direi che funge!

• aggiornamento della topologia anche nel mission manager (navigation unit)

  • se non ricordo male il nodo leggeva i waypoints direttamente dal canale dei markers…

  • come pensavo, quindi modifiche da fare non ce ne sono

  • toglierei tutto il codice per distinguere le altezze, dato che tutti i markers sono “alla stessa altezza”

    • sia dalla nav unit …

    • … che dalla manip unit (ho altro in servo per lei) NO: qui serve un lavoro più dettagliato

• aggiornamento della selezione del controller nella navigation unit

  • c’era solo da cambiare uno 0 con un 1 …

  • proviamo se funziona ancora, giusto per

  • e infatti NON funziona … fortuna che faccio i test ogni volta che modifico

    # shell 1
    roslaunch robocluedo_robot_hunter run.launch world_name:=indoor.world 2>/dev/null
    
    # shell 2
    roslaunch robocluedo_movement_controller navigation_system.launch &
    rosrun robocluedo_movement_controller navigation_manager &
    rosrun exp_assignment3 simulation_marker_publisher &
    rosrun robocluedo_mission_manager navigation_unit
    
    # shell 3
    rosservice call /robocluedo/navigation_command  "waypoint: 'wp1'"
    rosservice call /robocluedo/navigation_command  "waypoint: 'wp2'"
    rosservice call /robocluedo/navigation_command  "waypoint: 'wp3'"
    rosservice call /robocluedo/navigation_command  "waypoint: 'wp4'"
    rosservice call /robocluedo/navigation_command  "waypoint: 'wp5'"
    rosservice call /robocluedo/navigation_command  "waypoint: 'wp6'"
    rosservice call /robocluedo/navigation_command  "waypoint: 'center'"
    

  • ora funziona.

• l’azione collect hint diventa una simulated action in questa versione del progetto

  • cambiare i percorsi del PDDL nei launcher del plan

• ora, come ultima cosa, la modifica della manipulation unit, dopodichè dovrei essere pronto per iniziare l’implementazione di arUco

  • essendo ora la collect-hint una simulated action, non dovrebbe più servire il servizio per la manipulation

  • e non serve nemmeno ricevere dei markers

  • voglio aprire un topic sul controller per far compiere al braccio movimenti asincroni (voglio che il braccio si muova tra le postures a disposizione mentr eil robot si muove, senza rimanere bloccato in un servizio)

    • per fare questo ovviamente devo creare un nuovo messaggio…

    • implementazione

    • compila? compila

    • (che fatica…)

  • e proviamo

    # shell 1
    roslaunch robocluedo_robot_hunter run.launch world_name:=indoor.world 2>/dev/null
    
    # shell 2
    rosrun robocluedo_movement_controller manipulation_controller 2>/dev/null
    
    # shell 3
    rostopic list | grep tip
    # /tip_pos_async
    
    rostopic pub --once /tip_pos_async robocluedo_movement_controller_msgs/ManipulatorPositionAsync "command: 2
    enabled: true" 
    sleep 15
    rostopic pub --once /tip_pos_async robocluedo_movement_controller_msgs/ManipulatorPositionAsync "command: 4
    enabled: true" 
    sleep 15
    rostopic pub --once /tip_pos_async robocluedo_movement_controller_msgs/ManipulatorPositionAsync "command: 6
    enabled: true" 
    sleep 15
    

  • e funziona

  • ultima cosa: topic aperto come publisher dalla manipulation unit

  • e implementazione del publisher: una psoe a casotra le 9 disponibili ogni 10 secondi

  • siccome potrebbe darmi fastidio che questo pubblichi una pose nuova senza dirmi nulla, voglio anche uno switch per questo nodo, basta una set bool

  • compila? compila.

  • e si prova:

    # shell 1
    roslaunch robocluedo_robot_hunter run.launch world_name:=indoor.world 2>/dev/null
    
    # shell 2
    rosrun robocluedo_movement_controller manipulation_controller 2>/dev/null
    
    # shell 3
    rosrun robocluedo_mission_manager manipulation_unit
    
    # shell 4
    rosservice list | grep tip
    # /tip_pos
    # /tip_pos_auto_switch
    
    rosservice call /tip_pos_auto_switch "data: true"
    # 6 different poses
    sleep 60 
    rosservice call /tip_pos_auto_switch "data: false"
    

  • funziona.

  • adesso, la domanda spigolosa: dove mettere le richieste per la automanipulation? dipende dal landmark

    • dirty e solve non richiedono questo movimento automatico

    • mentre collect lo richiede

  • e la modifica va fatta in …

    • posso farla nel mission manager direttamente

  • quindi, modifiche

  • (non posso provare il mission manager ora, ma se compila è tutto a posto per il tipo di modifiche che ho fatto)

• COMMIT: “changing PDDL topology, RViz markers, auto manipulation”

---

e iniziamo a lavorare su aruco:

• anzitutto, la simulazione funziona? funziona.

roslaunch robocluedo_robot_hunter run.launch world_name:=assignment3.world 2>/dev/null

• nuovo nodo: aruco_detection.cpp

  • iniziamo con la struttura del nod

  • e implementazione

  • compila? … no

  • ero convintissimo di aver già installato open cv nel package vision … mi sbagliavo

  • ora compila

• e facciamo subito un test molto veloce (basta solo che la finestra funzioni come si deve e che si vedano le immagini dalle videocamere)

# shell 1
roslaunch robocluedo_robot_hunter run.launch world_name:=assignment3.world 2>/dev/null

# shell 2
rosrun robocluedo_vision aruco_detection

• AAAAAAA LA VIDEOCAMERA CAMBIA IN CONTINUAZIONE! ok, meglio correggere questa cosa prima che mi venga una crisi epilettica

  • ros::Time non sembra funzionare bene, per qualche strana ragione: la comparison è sempre vera, quindi la videocamera cambia sempre

  • … dovrò farmi un metodo a manina per comparare due tempi … e ora funziona

• ora però c’è un altro problema: è lentissimo.

  • posso limitare la frequenza dei topic con una rate.sleep( ) nei subscriber (non un’ottima idea ma potrebbe funzionare)

  • provo anche a diminuire il rate delle immagini dalle videocamere

    • 12fps possono bastare, spero

• ti ricordi quando dicevamo che funzionava bene lo switch? SCHERZONE: è tornato a switchare come un pazzo … motivo sconosciuto (ho tolto un log!)

  • temo che dovrò usare wallTime invece che il time normale

  • ora funziona sul serio

• rimane comunque molto pesante…

  • per ridurre ancora, posso droppare qualche richiesta usando il mutex con trylock piuttosto che lock, e quandoil thread non riesce a bloccare il myutex, ritorna immediatamente

• per il momento son soddisfatto così.

• COMMIT: “working on vision (aruco detection node)”

---

possiamo passare ora all’ultimissimo nodo della vision: il decode

• nuovo nodo: aruco_decode

  • (il nodo rimane in ascolto degli ID dal nodo aruco_detection; quando ne arriva uno, chiede all’oracolo che significa e ne ritorna il messaggio al mission manager)

  • anzitutto, bisogna rimappare il topic dell’oracolo affinchè non ci siano conflitti

    <?xml version="1.0"?>
    
    <launch>
    
    <node pkg="exp_assignment3" name="final_oracle" type="final_oracle" required="true" output="screen" >
    	<remap from="/oracle_hint" to="/original_oracle_hint" />
    </node>
    <!-- <node pkg="exp_assignment3" name="simulation_marker_publisher" type="simulation_marker_publisher" required="true" output="screen" /> -->
    
    </launch>
    

• adesso,

  • struttura di aruco_decode

  • e implementazione

  • e proviamolo un po’

# shell 1
roslaunch exp_assignment3 run.launch

# shell 2
rosrun robocluedo_vision aruco_decode.py

# shell 3
rostopic echo /oracle_hint

# shell 4
rostopic pub --once /aruco_detected_ids std_msgs/Int32 "data: 0"
rostopic pub --once /aruco_detected_ids std_msgs/Int32 "data: 1"
rostopic pub --once /aruco_detected_ids std_msgs/Int32 "data: 2"
rostopic pub --once /aruco_detected_ids std_msgs/Int32 "data: 3"
rostopic pub --once /aruco_detected_ids std_msgs/Int32 "data: 4"
rostopic pub --once /aruco_detected_ids std_msgs/Int32 "data: 5"

• …no comment… ma prchè c’è quel diavolo di -11 nell’oracolo ??????

// oracle_hint
bool oracleCallback(exp_assignment3::Marker::Request &req, exp_assignment3::Marker::Response &res)
{
	res.oracle_hint = oracle_msgs[req.markerId-11];
	return true;
} 

• e anche questa è andata

• COMMIT: “aruco decoder ready”

---

e pronti per il testing completo!

• anzitutto, ho un documento per il module testing, che vorrei rivedere per questo caso specifico

  • il piano è sempre lo stesso: pezzo per pezzo fino al progetto completo

• … direi che i test con aRMOR li possiamo anche skippare

• aggiungo subito i test appena fatti con ArUco

• testing di rosplan

• la parte del testing del robot va aggiornata

• i test della parte di navigation vanno aggiornati tutti (anche se però sarebbe bello avere a disposizione veramente due tipi di navigation…)

  • sai cosa? faccio la modifica

  • ora ci sono 3 launch file (più due giusto per non dover rifare tutti i nomi in qualunque script io abbia scritto finora)

  • a questo punto facciamo i test sulla navigation come se dovessero esserci tutti e due i sistemi operativi sullo stesso robot

  • eliminerei il test del wall follow … a dirla tutta, devo proprio eliminare il nodo

  • il test sul manipulation controller è cambiato, ce ne sono di più adesso

• e siamo arrivati quasi ai test finali (il momento della verità si avvicina…)

  • tutti i componenti del precedente assignment vanno benone

  • ho anche fatto un po’ di aggiornamento

• gli output dei test sono perfettamente inutili, eliminare

• ora, tutto tranne il mission manager

  • per questo serviranno dei test che non ho ancora scritto (faccio subito)

• va quasi tutto bene. aruco_detection non invia i marker sul topic

• (intanto un checkpoint nel dubbio…)

• COMMIT: “testing (problems with aruco_detection not publishing the ids)”

• il mio piano geniale avrebbe anche funzionato … se non fosse che le dimensioni dei vettori non fossero misurate in size_t piuttosto che come int …

per capirci, vector.size() - 1 ritorna questo orrore senza Dio:

[ INFO] [1660844701.851857500, 951.527000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844702.040326800, 951.626000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844702.292802100, 951.729000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844702.493988200, 951.831000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844702.703035300, 951.926000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844702.888891100, 952.026000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[INFO] [1660844702.891754, 952.028000]: (aruco_decode ) ready
[ INFO] [1660844703.047278100, 952.127000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844703.309153800, 952.226000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844703.534099100, 952.326000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844703.534168700, 952.326000000]: (aruco_detection ) switching to camera with ID=2
[ INFO] [1660844703.744395000, 952.426000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844703.981569700, 952.527000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844704.258705100, 952.629000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1
[ INFO] [1660844704.427318800, 952.726000000]: (aruco_detection ) size-1=18446744073709551615 -- idx=-1

• e come si risolve la faccenda?

• se scrivo questo ((int)ids_to_publish.size( )) - 1 il problema sembra risolto, mentre se scrivo ids_to_publish.size( ) - 1 viene fuori quella roba là sopra

[ INFO] [1660844957.321987100, 957.825000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844957.521214800, 957.925000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844957.792062300, 958.025000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844957.993540900, 958.125000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844958.220654500, 958.225000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844958.471494800, 958.325000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844958.720852300, 958.425000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844958.984896700, 958.525000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844959.329034600, 958.625000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844959.619499500, 958.725000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844959.789824700, 958.826000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844960.082557000, 958.935000000]: (aruco_detection ) size-1=-1 -- idx=-1
[ INFO] [1660844960.082637800, 958.935000000]: (aruco_detection ) switching to camera with ID=3
[ INFO] [1660844960.283390600, 959.028000000]: (aruco_detection ) size-1=-1 -- idx=-1

• proviamo anche la condizione così scritta: … eandiamo!

• ho notato inoltre che certe volte il decode non riesce a contattare l’oracolo (quando il sistema inizia ad essere piuttosto saturo di cose da fare, che accada qualche problema sulle chiamate a servizio c’è da aspettarselo … purtroppo)

  • meglio aggiungere qualche strategia di recupero al decode

• ISSUE ho fatto girare un po’ il programma … e dopo 5min buoni ha crashato a seguito di una ricezione di un ID pari a 174…

  • … e ricordo che nel precedente assignment, ogni tanto l’oracolo crashava prchè l’ID era troppo alto, non definito (aridanghete)

  • sensato?

direi proprio confermato:

int markerID[30]; 
erl2::ErlOracle oracle_msgs[30];

// oracle_hint
bool oracleCallback(exp_assignment3::Marker::Request &req, exp_assignment3::Marker::Response &res)
{
	res.oracle_hint = oracle_msgs[req.markerId];
	return true;
}

• per risolvere il problema, il decoder dovrebbe usare l’operatore di modulo (le specifiche non trattano di preciso questo caso … perciò mi reputo autorizzato a fare quello che voglio qui)

  • piccola modifica al decoder

  • e ora funziona tutto a meraviglia

• COMMIT: “testing (aruco_detection publisher, oracle crash solved)”

---

siamo moooolto vicini al momento della verità: questa sera gli dsi da il colpo di grazia a questo progetto! poi sotto con la documentazione, e si consegna.

• anzitutto, piccola modifica al decode in modo da supportare l’invio in un secondo momento dell’hint

  • (il principio: non riesco ad inviarlo ora? bene: me lo metto da parte, e lo invio in seguito)

  • pare che funzioni

• il tempo di replanning del nodo di move base è veramente troppo poco: solo 15s è niente, e rende il path piuttosto instabile

  • alzarlo a 30s mi pare la cosa migliore

• ora un test con i movimenti “a caso” del braccio

  • riesce a prendere ancora più hint adesso! che bello

• COMMIT: “final testing (ready to test the whole system)”

---

e andiamo con l’ultimo test: il mission manager

• anzitutto, script del test

• e voglio attivare la modalità di sviluppo nel mission manager, giusto per

• essiamoprontiperprovare

congratulazioni.

• COMMIT: “happy commit!”

---

21/08/2022 – alleggerimento – documentazione

il piano di oggi è: alleggerire (per quanto possibile) l’applicazione, partendo dall’eliminare i log inutili, e documentare. Siccome c’è grande somiglianza tra i due progetti, posso partire col documentare il terzo per poi trasferire gran parte della documentazione sul secondo progetto. Per la documentazione del codice ci vorrà un pochino più di lavoro, ma per il resto dovrebbe risparmiarmi un bel po’ di fatica. E domani, scrittura dei due readme e via così.

• (iniziamo dal lavoro di alleggerimento)

• fattori che riducono notevolmente le prestazioni:

  • (OK) essendo RViz solo uno strumento di visualizzazione, si potrebbe magari usare solo Gazebo per visualizzare la simulazione

    • quindi l’attuale launcher per eseguire il progetto dovrebbe permettere di scegliere se lanciare solo Gazebo oppure entrambi

  • (OK) gmapping continuamente in esecuzione; sarebbe meglio usare amcl

    • link wiki ufficiale AMCL

    • bisognerà creare una mappa con teleop

    • … oppure posso fare uno script che mappa l’area in automatico? è possibile?

    • fare uno script che crei una mappa in automatico dell’area usando l’attuale nav system e tutto il resto

  • logging dai programmi, che dovrebbero essere mostrati solo in caso di modalità di sviluppo

    • tutte le applicazioni fanno logging inutile

    • sarebbe meglio poter attivare la modalità di sviluppo a tempo di compilazione…

    • … o ancora meglio, da parameter server (ma potrebbe risultare un po’ scomodo)

    • quindi, attivare le modalità di sviluppo a tempo di compilazione

    • quindi usando un approccio identico a quello impiegato nel mission manager

  • il nodo wall-follow non viene usato, perciò sarebbe meglio eliminarlo

    • fare la modifica in modo tale che la stessa cosa funzioni anche nel secondo assignment

    • bisognerà modificare i launcher

    • e anche bug_m

    • e anche il controller

    • una modifica al controller: impossibile attivare un controller quando uno dei canali necessari non risponde

---

e quindi, iniziamo da RViz e da AMCL:

• simulazione solo con Gazebo piuttosto che con Gazebo/RViz

  • l’attuale inizializzazione è un po’ lunga per quanto riguarda missio manager / run.launch … introduco un parametro init

    • init false -> tutti i parametri vengono inizializzati a false

  • nuovo parametro with_rviz per decidere se lanciare o no anche RViz

  • questo richiede una modifica del launcher del robot…

    • c’è un modo di fare operazioni logiche negli if dei launch file?

    • vedi questo post ufficiale

    • quindi non con l’if, però c’è un replacement che si chiama “eval” e che esegue operazioni sui parametri

    <group if="$(eval arg('debug') ==0)">
    	<node pkg="xxx" type="yyy" name="yyy">
    </group>
    

    • altro esempio, sempre nello stesso post:

    <arg name="team" default="Red"/>
    <arg name="type" default="painter"/>
    
    <group if="$(eval team == 'Red')">
      <group if="$(eval type == 'painter')">
    	<param name="robot_description" 
    	  command="$(find xacro)/xacro $(find robopaint)/urdf/red/paintbot_red.urdf.xacro" />
      </group>
      <group if="$(eval type == 'attacker')">
    	<param name="robot_description" 
    	  command="$(find xacro)/xacro $(find robopaint)/urdf/red/attackbot_red.urdf.xacro" />
      </group>
    </group>
    
    <group if="$(eval team == 'Blue')">
      <group if="$(eval type == 'painter')">
    	<param name="robot_description" 
    	  command="$(find xacro)/xacro $(find robopaint)/urdf/blue/paintbot_blue.urdf.xacro" />
      </group>
      <group if="$(eval type == 'attacker')">
    	<param name="robot_description" 
    	  command="$(find xacro)/xacro $(find robopaint)/urdf/blue/attackbot_blue.urdf.xacro" />
      </group>
    </group>
    

    • mi ero anche dimenticato dell’esistenza dei raggruppamenti…

    • devo ristrutturare il run

    • meglio creare un run2.launch piuttosto di fare strane modifiche a roba che già funziona

    • aggiungo già un parametro e una zona del launch per lanciare AMCL

    • qualche test sul launch del robot, giusto per verificare di non aver scritto cose stupide …

    roslaunch robocluedo_robot_hunter run2.launch sim_type:=gazebo gazebo_paused:=false
    roslaunch robocluedo_robot_hunter run2.launch sim_type:=rviz rviz_config_file:=moveit.rviz launch_nav_stack:=false
    roslaunch robocluedo_robot_hunter run2.launch sim_type:=gazeborviz 
    

    • e ora torniamo sul launch generale

    • e si prova

    roslaunch robocluedo_mission_manager run_components.launch init:=false launch_robot:=true robot_env_type:=gazebo 1>/dev/null 2>/dev/null
    roslaunch robocluedo_mission_manager run_components.launch init:=false launch_robot:=true robot_env_type:=rviz 
    roslaunch robocluedo_mission_manager run_components.launch init:=false launch_robot:=true robot_env_type:=gazeborviz 1>/dev/null 2>/dev/null
    roslaunch robocluedo_mission_manager run_components.launch init:=false launch_robot:=true world_name:=assignment3.world
    roslaunch robocluedo_mission_manager run_components.launch init:=false launch_robot:=true robot_env_type:=gazebo robot_nav_config:=gmapping 
    

  • funziona tutto.

---

è il momento di AMCL

• anzitutto, documentazione

• e modifica ai launch files

• e test … funziona!

  • la localizzazione è un po’ più instabile su RViz, però sembra andare abbastanza bene.

• ora bisognerebbe provare il launch generale: come reagisce con tutta la simulazione attiva usando AMCL?

  # shell 1
  roslaunch robocluedo_mission_manager run_components.launch init:=false launch_robot:=true robot_env_type:=gazeborviz robot_nav_type:=amcl 1>/dev/null 2>/dev/null
  
  # shell 2
  roslaunch robocluedo_mission_manager run_components.launch launch_robot:=false launch_mission_manager:=false 
  
  # shell 3
  roslaunch robocluedo_mission_manager run_components.launch init:=false launch_mission_manager:=true
  

  • e funge! il comportamento del robot è leggermente più instabile, ma pare che sia riuscito a ridurre di qualche secondo le tempistiche di esecuzione

• COMMIT: “improving localization performances with AMCL”

---

passiamo alla questione dei logs

• per quanto riguarda i nodi C++, l’idea sarebbe quella di creare un sistema simile a quello del mission manager

• ci vuole un piccolo template, da adattare a seconda del caso.

• per i nodi C++,

  globale:

  #define DEVELOP_MODE false
  
  #define DEVELOP_PRINT false
  #define WTLOG( msg )  { if( DEVELOP_PRINT ) { ROS_INFO_STREAM( OUTLABEL << msg ); } }
  #define WTWARN( msg ) { if( DEVELOP_PRINT ) { ROS_WARN_STREAM( OUTLABEL << msg ); } }
  #define WTERR( msg )  { if( DEVELOP_PRINT ) { ROS_WARN_STREAM( OUTLABEL << msg ); } }
  
  #define DEVELOP_WAIKEY false
  #define WAITKEY { if( WAITKEY_ENABLED ) { std::cout << "press ENTER to continue ... " ; std::cin.get( ) ; std::cout << "go!" << std::endl ; } }
  

• per i nodi py la questione al solito non è così semplice… ci pensiamo poi

• provo la nuova macro sulla manipulation unit … pare funzionare

• e vai con le sostituzioni

  • completare la manipulation unit

con cose del genere…

		if( req.data )
			WTLOG( "auto manipulation ENABLED" );
		else
			WTLOG( "auto manipulation DISABLED" );

il compilatore ritorna un errore stranissimo:

/root/ros_ws/src/erl3/robocluedo_mission_manager/src/manipulation_unit.cpp:146:3: error: ‘else’ without a previous ‘if’
  146 |   else

rendendo esplicito il contesto, il problema se ne va:

		if( req.data )
		{
			WTLOG( "auto manipulation ENABLED" );
		}
		else
		{
			WTLOG( "auto manipulation DISABLED" );
		}

• e ora, navigation unit … liscio liscio

• in armor ce ne sono davvero pochi … però quelli della ontology non mi vanno proprio benissimo

  • penso che metterò l’output della ontology su log

  • quelli della armor interface direi che non si toccano… almeno per il momento

• e ora il movement controller

  • manipulation controller

  • navigation manager

• e per quanto riguarda i nodi py?

  • preferisco una soluzione più … elementare: meglio commentare direttamente

  • quindi bug_m

  • go to point

  • head orientation

  • move base nav

  • wall f… tanto devo eliminarlo

---

e si continua:

• andamo con rosplan

  • il pipeline manager

  • kb interface (c++)

• COMMIT: “deleting comments from the code (develop mode)”

---

e andiamo ad eliminare il nodo wall follow

• anzitutto, eliminazione da bug_m

• test (giusto per capire se funziona … ancora) …

  • avevo introdotto qualche bug nei file python

  • ora è tutto risolto

• modifica dei lauch files

  • (che fatica)

  • il run.launch va … leggermente ristrutturato

lo si prova un po’ questo nuovo launch file:

roslaunch robocluedo_movement_controller run.launch nav_type:=bugm
roslaunch robocluedo_movement_controller run.launch nav_type:=navstack
roslaunch robocluedo_movement_controller run.launch nav_type:=all

# for each of them,
rosnode list

• funziona tutto (a parte per qualche errore di expected indentation)

• wall follow eliminato!

• COMMIT: “wall follow deleted”

---

e ora si parte col lavoro di documentazione vera, sempre con la solita filosofia: inizia a lavorare sull’assignment 3, e riporta la documentazione nel 2 per quanto possibile.

• robocluedo_armor

  • pulizia dei documenti già presenti

  • gli schematic vecchi li posso togliere

  • (tutto quel che c’è da fare l’ho segnato nel todo)

• robocluedo_vision

  • mancano le code reference…

    • le posso aggiungere subito senza problemi

  • il resto mi toccherè aggiungerlo in seguito

• robocluedo rosplan

  • …

• COMMIT: “documentation review”

---

avanti con la documentazione:

• robocluedo rosplan

  • pddl and rosplan

  • gli UML per ROSPlan non mi convincono molto…ma quelli più estesi sono veramente difficili da tracciare: ci sono un sacco di connessioni, sono tutti ingarbugliati, e anche guardandoli non se ne capirebbe il senso. quindi, meglio tenersi sul semplice.

• COMMIT: “writing documentation”

---

22/08/2022 – documentazione del progetto

continuiamo con la scrittura della documentazione (per il momento, overview veloce della documentazione; più avanti passiamo a rivedere nel dettaglio gli altri punti)

• robocluedo rosplan

  • documento sulla rosplan pipeline

  • metodi nel feedback manager

• robocluedo dependencies

  • anche vision cv ha la sua documentazione

  • provo ad importarla… ok

  • aggiorno la documentazione sul modello del robot …

  • manca la parte su amcl

  • e revisione di tutto il codice riportato nel documento (c’è voluto un bel po’)

• robocluedo movement controller

  • la documentazione su AMCL meglio spostarla qui dentro…

  • gli UML del movement controller vanni aggiornati

  • va documentato move_base_nav

• giusto un’occhiata al resto della documentazione

  • se non è essenziale per la comprensione del progetto, direi di nasconderla

• una nota su come avviare il progetto (ottima occasione per fare un’ultimo test prima della consegna)

  • mi sono accorto che manca un documento su come lanciare l’intero progetto col launcher! cazz

  • lo scrivo subito

• e test …

  • … poteva mai andare tutto bene? certo che no.

  • c’è un problema con l’unità del mission manager che gestisce la manipulation…

  • (devo aver fatto qualche stupida modifica al codice)

un piccolo test (proviamo a capire dove sta l’errore):

# shell 1
roslaunch robocluedo_mission_manager run_components.launch init:=false launch_robot:=true robot_env_type:=gazeborviz robot_nav_type:=amcl 1>/dev/null 2>/dev/null

# shell 2
roslaunch robocluedo_mission_manager run_components.launch init:=false launch_motion_controllers:=true

# shell 3
roslaunch robocluedo_mission_manager run_components.launch init:=false launch_mission_manager_components:=true

# shell 4

• noto che non viene avviato il manipulation controller … ci sarà qualcosa di sbagliato nel launch file del motion controller

• e in effetti nel launch file manca! fortuna che stavolta è stato semplice risovlere questo problema: stavo iniziando a pensare al peggio (fortuna che testo sempre…)

• e proviamo ancora … e ovviamente ci sono degli errori sul launch file…

• il launch file globale crasha, ma i singoli componenti no

  • sono costretto a fare una esecuzione step by step per capire dove sta il problema…

• potrebbe anche essere successo che sia scattato qualche timeout, dato che il servizio sulla manipulation non era stato attivato: non vedendo il servizio pubblicato, qualche nodo si è chiuso, determinando così la chiusura dell’intero programma

• e altro errore, ovviamente! sempre dal manipulation.

process[manipulation_controller-7]: started with pid [2768]
[ERROR] [1661161333.204855700]: Robot semantic description not found. Did you forget to define or remap '/robot_description_semantic'?
[ INFO] [1661161333.206055300]: Loading robot model 'robocluedo_robot'...
[ INFO] [1661161333.206203300]: No root/virtual joint specified in SRDF. Assuming fixed joint
[FATAL] [1661161333.344392200]: Group 'arm_group' was not found.
terminate called after throwing an instance of 'std::runtime_error'
  what():  Group 'arm_group' was not found.
================================================================================REQUIRED process [manipulation_controller-7] has died!
process has died [pid 2768, exit code -6, cmd /root/ros_ws/devel/lib/robocluedo_movement_controller/manipulation_controller __name:=manipulation_controller __log:=/root/.ros/log/a12e59a4-21fe-11ed-a404-0242ac110002/manipulation_controller-7.log].
log file: /root/.ros/log/a12e59a4-21fe-11ed-a404-0242ac110002/manipulation_controller-7*.log
Initiating shutdown!
================================================================================

• e se provassi ad avviare anche RViz?

  • con anche RVIZ sembra che vada …

  • … ma ieri andava anche senza RViz … cos’è cambiato?

• quindi … senza RViz stavolta, MoveIt non va

  • ieri ha funzionato anche senza … oggi niente, boh

  • può essere un problema nel run2 del robot

• potrei aver capito dove sta il problema… proviamo così: ho creato un gazebo2.launch che è come demo_gazebo.launch ma senza lanciare RViz … se ho intuito bene, questo dovrebbe lanciare sia gazebo che il modello del robot, cioè quello che serve per non far crashare quel launch file

# shell 1
roslaunch robocluedo_robot_hunter gazebo2.launch

# shell 2
roslaunch robocluedo_mission_manager run_components.launch init:=false launch_motion_controllers:=true

# shell 3
roslaunch robocluedo_mission_manager run_components.launch init:=false launch_mission_manager_components:=true

# shell 4
rosnode list

• problema risolto! La mia intuizione era corretta: il file di base generato dal setup assistant per lanciare solo Gazebo non esegue anche tutti gli strumenti che serve avviare per usare il framework moveit. Creando questo secondo launch file sono riuscito ad eseguire con successo anche la parte di manipolazione usando solo Gazebo

• adesso ho da aggiungere un 2 a qualunque cosa nel codice …

  • nel launch generale non servono modifiche

  • modifica nel run2

  • (non è stato così tragico…)

  • vado a segnalare la issue nella documentazione del modello URDF

• e riproviamo a lanciare il progetto, stavolta senza RViz …

• (pensandoci bene, ieri non ho testato fino in fondo questa feature… comunque oggi l’ho fatto, bene che c’ho pensato)

• E FUNZIONA!

• COMMIT: “documentation, ISSUE Gazebo-only SOLVED, improving launch files”

---

già che ci sono, voglio testare un minimo le performances confrontando due casi:

• SLAM/Gmapping e RViz+Gazebo : il real time factor non scende sotto 0.30, si mantiene in media su 0.39

# shell 1
roslaunch robocluedo_mission_manager run_components.launch launch_mission_manager:=false robot_env_type:=gazeborviz robot_nav_type:=gmapping 1>/dev/null 2>/dev/null

# shell 2
roslaunch robocluedo_mission_manager run_components.launch init:=false launch_mission_manager:=true

• AMCL e solo Gazebo : il real time factor si mantiene sui 0.42 più freqentemente, e non scende sotto 0.38 (quindi sì, il lavoro tra ieri e oggi ha funzionato!)

# shell 1
roslaunch robocluedo_mission_manager run_components.launch launch_mission_manager:=false robot_env_type:=gazebo robot_nav_type:=amcl 1>/dev/null 2>/dev/null

# shell 2
roslaunch robocluedo_mission_manager run_components.launch init:=false launch_mission_manager:=true

• COMMIT: “playing a bit with the complete project, refreshing docs”

---

direi che adesso possiamo iniziare a fare il lavoro che mi sto segnando tra ieri e oggi, tra un bug e l’altro:

• (andiamo con la documentazione seria del codice)

• robocluedo vision

  • aruco detecton c++

  • (c’è voluta un bel po’ di attenzione…)

• COMMIT: “code documentation (aruco_detection)”

• robocluedo vision

  • aruco decode

• COMMIT: “code documentation (aruco decode)”

• robocluedo rosplan

  • (tentiamo di seguire una logica…)

  • action replan

  • move-to

  • move to center

  • (tutte le altre servivano per il secondo progetto, per questo non servono)

  • kb_interface

  • kb tools

  • feedback manager … già documentato (me ne sto)

  • pipeline manager

• COMMIT: “code documentation (robocluedo rosplan)”

• (è il momento di soffrire per davvero) robocluedo movement controller

  • (anzitutto, una minima occhiata in giro…)

  • bug_m

  • go to point

  • head orientation

  • move base nav

  • meglio scrivere ora il documento su come aggiornare il navigation manager…

  • navigation manager

  • manipulation controller

• (mi sono totalmente dimenticato dei launch files in giro per il progetto)

• launch files:

  • movement controller

• COMMIT: “code documentation (…endless…)”

---

avanti con la documentazione dei packages:

• launch files:

  • movement controller (pronto)

  • vision

  • rosplan

  • armor … già fatto? sono efficientissimo

• (e stop, il mission manager l’ho documentato stamattina, quindi tutto ok)

• e riprendiamo con la documentazione del codice (ormai ne manca poco, per fortuna)

  • minimo lavoro di revisione, giusto per capire se è tutto a posto…

• ancora documentazione del codice (ultimo round) mission manager

  • navigation unit

  • manipulation unit

  • mission manager

• ancora un giro nella documentazione per capire se c’è altro che posso fare (dovrei aver terminato il lavoro sul codice)

• UML generale del progetto (stavolta molto semplice … inutile stressare troppo plantUML: rimane comunque uno strumento abbastanza limitato, per quanto utile)

• anche all’ultimissimo test è sopravvissuto

• COMMIT: “documentation (ready for the README)”

---

23/08/2022 – readme e deployment

Andiamo subito con la scrittura del readme per il progetto. Fatto questo, lavoro sull’aggiornamento della documentazione per la seconda parte del progetto, e si pubblica.

• prima impostazione del readme (stavolta però tutte le sezioni riguardanti il setup vanno nella documentazione, così il readme viene un po’ più corto)

  • seguendo la struttura nelle slides

  • nonostante le dimensioni dell’attuale documentazione, vorrei che il readme fosse più terso possibile, semplice ed essenziale

Note

struttura del readme:

1. Brief introduction (couple of sentences).

2. Software architecture, temporal diagram and states diagrams (if applicable). Each diagram should be commented with a paragraph, plus a list describing ROS messages and parameters.

3. Installation and running procedure (including all the steps to display the robot’s behavior).

4. A commented small video, a GIF or screenshots showing the relevant parts of the running code.

5. Working hypothesis and environment (1 or 2 paragraph).

6. System’s features (1 or 2 paragraph).

7. System’s limitations (1 or 2 paragraph).

8. Possible technical Improvements (1 or 2 paragraph).

9. Authors and contacts (at least the email).

• scrittura readme

• penso ci voglia un diagramma UML globale più ricco che mostri tutti i componenti e tutti i packages del progetto

• purtroppo c’è davvero molto da scrivere… tento di tenerlo più conciso possibile, ma l’architettura è davvero troppo complessa per poterla spiegare in poche righe. Posso fare affidamento sui diagrammi, ma anche quelli non possono dire proprio tutto.

• per il momento meglio fare le cose in sphinx, per poi portare tutto su GitHub

• è arrivato il tanto temuto momento dei temporal diagrams …

• azitutto, ci vuole un elenco dei diagrammi necessari

  • navigation usando move_base

    (selezione algoritmo, movimento)

    ROSPlan action move_to navigation unit navigation manager – navigation controller move_base move_base_nav head orientation

  • navigation usando bug_m

    (selezione algoritmo, movimento)

    ROSPlan action move_to navigation unit navigation manager – navigation controller bug_m bug_m head orientation go to point

  • manipulation sincrona (RCL#2)

    ROSPlan action manipulation manipulation unit manipulation controller moveit

  • manipulation asincrona (RCL#3)

    manipulation unit manipulation controller moveit

  • esecuzione di un plan col mission manager (in gran parte è identico a quello dell’assignment 2)

    mission manager armor interface pipeline manager kb_interface rosplan kb rosplan dispatch oracolo

  • (forse per il mission manager è meglio un flow chart…)

• forse sarebbe meglio ricorrere a diagrammi innestati piuttosto che fare diagrammi troppo lunghi:

  • i diagrammi temporali generali mostrano solo la comunicazione tra packages, senza menzionare (se non al di sopra delle frecce) i componenti

  • i diagrammi temporali dei nodi rappresentano invece i doni all’interno di un solo package

• alcuni rudimenti di sintassi plantText sui diagrammi temporali, nello specifico del progetto:

@startuml

''' titolo e tutto il resto
header un header piuttosto arguto
footer un footer ancora più arguto
title un titolo perfetto per un diagramma perfetto

''' entità
'''    FUNZIONA ANCHE SENZA DICHIARAZIONI 
'''     ma in caso...
participant "node name" as NODE_NAME
collections "package name" as PACKAGE_NAME

''' collegamenti tra entità
'''     LINEA CONTINUA ->
''      LINEA DASHED -->
''      LINEA col pallino in fondo ->o
node1 -> node2 : andata ... 
node1 <- node2 : ... e ritorno

''' sezioni di diagramma
== A Diagram Section ==

''' annotazioni
'''    STILE 1
node1 -> node2 : andata ... 
note right: una nota di andata
node1 <- node2 : ... e ritorno
note left: una nota di ritorno

'''    NOTE OVER stile 1
note across: a very long, exaustive, note

node2 -> node3 : andata ... 
note left: una nota di andata
node1 <- node3 : ... e aridanghete
note right: una nota di ritorno

'''    STILE 2
node2 -> node3 : andata ... 
note right
    una nota di andata
    una nota piuttosto lunga
end note

'''    NOTE OVER stile 2
note across
	another very long, exaustive, note
end note


@enduml

esempio di temporal:

altro esempio molo stupido:

• pronti per UML-eggiare

  • navigation with move base

  • temporal diagram packages

  • (manca ancora il node diagram)

• COMMIT: “documentation (writing the readme)”

---

• navigation with move base

  • temporal node diagram

  • (per i components non sarà il massimo … ma per i temporal, plantUML è fenomelae, comodissimo, e fa dei diagrammi molto belli)

• navigation usando bug_m (inizio a mettere avanti un po’ di lavoro per l’altro progetto)

  • temporal package diagram

  • e temporal node

• COMMIT: “documentation (temporal diagrams)”

---

• asynchronous manipulation

  • in questo caso solo il node diagram, dovrebbe essere già abbastanza chiaro così

• serve anche un temporal su robocluedo vision

  • package temporal diagram … non serve

  • node diagram

• e ora, il worflow generale

  • penso che questa volta userò un grosso diagramma di flusso … come si fanno i diagrammi di flusso?

e andiamo ad imparare come si fanno i diagrammi di flusso in plantText:

@startuml

''' inizio del diagramma
(*) --> A

''' fine del diagramma
A --> (*)

''' etichette sulle frecce
(*) -->[this is a label] A
A -->[this is a label] (*)

''' branches
(*) --> A
if "condizione" then
 -->[true] B
B --> C
else
 -->[false] C
endif
C --> (*)


@enduml

• …i fork sono inguardabili …

• meglio preferire uno state diagram, molto meglio

@startuml

''' INIT
[*] --> A


''' END
A --> [*]


''' aggiungere cose sotto uno stato
A : testo stato
A : altro testo stato


''' DICHIARAZIONE ESPLICITA DI STATO usata anche per suddividere il diagramma in sottostati
state MACROSTATE_A {
	[*] --> A
	A --> B
	B --> C
	B --> A
	C --> [*]
}

state MACROSTATE_B {
	[*] --> MA
	MA --> MC
	MC --> MC
	MC --> MB
	MB --> MA
	MC --> [*]
}

B --> MB
A --> MC


''' separatore orizzontale
''     SERVE PER SOTTOLINARe operazioni concorrenti
state MACROSTATE_B {
	ME --> MF
	MF --> ME
	---
	MC --> MD
	MD --> MC
	---
	MA --> MB
	MB --> MA
}

''' c'e anche il separatore verticale, stesso significato
state MACROSTATE_B {
	ME --> MF
	MF --> ME
	||
	MC --> MD
	MD --> MC
	||
	MA --> MB
	MB --> MA
}

''' stati fork e join
[*] --> a
state my_fork <<fork>>
a --> my_fork
my_fork --> b
my_fork --> c
my_fork --> d
state my_join <<join>>
b --> my_join
c --> my_join
d --> my_join
my_join --> e
e --> [*]
e --> a
e --> c


@enduml

anche il diagramma a stati è abbastanza osceno … ma perlomeno meglio dell’altro

• adesso, il diagramma a stati

• COMMIT: “documentation (temporal diagrams done)”

---

• qualche commento ai diagrammi nel readme (ma gusto pochissimi)

• diagrammi mancanti

  • pianificazione di un landmark con il pipeline manager

• direi di fare un plan per ogni landmark:

  • REPLAN

  • … e gli altri sono identici

• COMMIT: “documentation (landmarks execution diagram)”

---

e torniamo al lavoro:

• (per l’installazione ci penso più tardi)

• (la runnin procedure è ampiamente spiegata con dovizia di particolari nella documentazione del progetto)

• workig hypotheses and environment

• COMMIT: “documentaton (working assumptions)”

---

• scrittura delle ultimissime parti del readme …

• sai cosa ti dico? Il readme sta nella documentazione. Non voglio alcun readme visibile su Git, se non un semplice link che rimanda alla documentazione con la classica mia card che mostra una prima overview dei link. Ho fatto uno sforzo immane per tenere tutto all’interno della documentazione e per renderla completa.

• scrittura del “readme fantoccio”

  • mantenendo la documentazione in Sphinx è più semplice aggiornarla e linkare ad altre pagine rilevanti della documentazione, mentre tenendola in un semplice readme di Git devo ogni volta fare il noiosissimo lavoro di rimaneggiare i link … ho fatto questa esperienza su ben 5 assignment, e non ci tengo a ripeterla la sesta volta.

• dovrei aggiungere qualche parola per ogni package, almeno i nodi all’interno

  • armor interface è già abbastanza documentato

  • le dipendenze non contengono nodi che non siano stati documentati, ad eccezione di quelli per opencv, che comunque non sono un problema mio

  • mission manager

  • mi sono appena accorto che mancano gli UML dei nodi del mission manager!

  • (una barba infinita…)

  • vision

    • e che fai? del diagramma UML del vision te ne privi?

  • rosplan direi che èè stato già ampiamente documentato

  • e così anche il movement controller

  • un UML del module testing non serve a nulla

• allineamento verticale in PlantUML … vedi la magia più usa together {…}

  • anche questa guida sul layout è molto utile

• ho una cosa in testa … voglio provare a fare un commit da script

• COMMIT: “script commit”

• giusto un altro giretto nella documentazione per essere sicuro (poi setup e run?)

• la documentazione dovrebbe essere pronta

• COMMIT: “documentation (finally, ready for the final setup)”

---

• nuova pagina per il setup

• e proviamola dunque questa installazione!

• COMMIT: “deployment (working on setup)”

• nuovo docker pulito…

  • E FUNZIONAAAAAAAA – fine dei giochi (almeno per quanto riguarda il terzo assignment)

• COMMIT: “deployment (the end … maybe?)”

---

24/08/2022 – revisione documentazione

• revisione generale della documentazione (giusto capire se c’è qualcosa di migliorabile nell’aspetto grafico dei diagrammi o nella chiarezza degli scritti)

• COMMIT: “docs review and refresh”

Note

utilizzo di move base

• il nodo che si occupa di fare la navigation aggiorna il plan parecchie volte, perchè sulle lunghe tratte move_base tende a far andare il robot in percorsi che non hanno molto senso

• rifacendo il panning ogni tot si assicura una certa sitabilità sul path prescelto

• unico difetto: il robot si ferma spesso per fare replanning, causando delle oscillazioni in avanti un po’ brusche

strano warning con move_base

Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 942.458000 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cppWarning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 942.458000 according to authority unknown_publisher

         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.459500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.459500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.460500 according to authority unknown_publisher
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.460500 according to authority unknown_publisher
         at line          at line 278278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.461500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.461500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.462500 according to authority unknown_publisherTF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.462500 according to authority unknown_publisher

         at line 278         at line  in 278/tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp in 
/tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.463500 according to authority unknown_publisherWarning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.463500 according to authority unknown_publisher
         at line 
278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.464500 according to authority unknown_publisher
TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.464500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp         at line 278
 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.465500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.465500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.466500 according to authority unknown_publisher
         at line 278TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.466500 according to authority unknown_publisher in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp

         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.467500 according to authority unknown_publisher
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.467500 according to authority unknown_publisher
         at line          at line 278 in 278/tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp in 
/tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 942.467000 according to authority unknown_publisher
Warning:          at line TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 942.467000 according to authority unknown_publisher278 in 
         at line /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp278
 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.468500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.468500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.469500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.469500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.470500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cppWarning: 
TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.470500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.471500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.471500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.472500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.473500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.472500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.473500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.474500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.474500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.475500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.475500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.476500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.476500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.477500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.477500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.478500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cppWarning: 
TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.478500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.479500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.479500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 942.479000 according to authority unknown_publisherTF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 942.479000 according to authority unknown_publisher

         at line 278         at line  in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp

Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.480500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.480500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.481500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.481500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.482500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.482500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.483500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.483500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.484500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.484500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 942.483000 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame base_link at time 942.483000 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.485500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.485500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.487500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.487500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.488500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.488500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.489500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.489500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.490500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.490500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.491500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.491500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.492500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.492500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.493500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.493500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.496500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.496500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.497500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.497500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.498500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.498500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.499500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.499500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.500500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.500500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.501500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.501500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.502500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame odom at time 942.502500 according to authority unknown_publisher
         at line 278 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp