Setup test environment for vidualizing data from the walking controller

[nunoguedelha]

We describe here the setup for activating the visualization of the walking controller "exogenous" signals published on the logging port /walking-coordinator/logger/data:o and collected by the data logger module WalkingLoggerModule. Visualizing that data will allow to:

• verify the port data format (BipedalLocomotion::YarpUtilities::VectorsCollection)
• test the parsing and plotting of the data in the iCub telemetry online visualizer.

Refer to https://github.com/ami-iit/component_ANA-Avatar-XPRIZE/issues/355.

[nunoguedelha]

Building the WalkingModule

Following the entry point https://github.com/ami-iit/component_ANA-Avatar-XPRIZE/issues/355, and discussing with @paolo-viceconte:

• we get the Pull Request integrating the telemetry logging in the walking module: Use the telemetry logger in the WalkingModule robotology/walking-controllers#97.
• the PR is currently merged on devel and we will be using commit robotology/walking-controllers@d45c670.

For building the superbuild with this PR, we followed the steps below:

• build the superbuild release tag v2021.11.0
• select the walking-controllers commit d45c670 and check the dependencies introduced/upgraded between tag v0.4.1 and d45c670

Introduced/upgraded dependencies:

• UnicyclePlanner: v0.3.0 -> v0.4.0
  • iDynTree: v0.9.2 -> v4.3.0 (already under v2021.11.0)
• bipedal-locomotion-framework: v0.4.0 -> v0.6.0
  • YARP: ≥ v3.5.0 (already v3.5.1 under v2021.11.0)
  • qhull: ≥ v8.0.0 (already v8.0.2 under v2021.11.0)
  • manif: ≥ v0.0.4 (already v0.0.4.1 under v2021.11.0)
  • OsqpEigen: v0.6.4 -> v0.7.0
  • LieGroupControllers: ≥ v0.1.1 (already v0.1.1 under v2021.11.0)
  • nlohmann_json: ≥ v3.7.3 (already under conda v3.10.5)
  • tomlplusplus: ≥ v2.4.0 --> MISSING (OK, compilation is deactivated, YARP is selected instead)
  • YARP_telemetry: no version specified

The WalkingModule target build was initially failing (as mentioned during the Telexistence meeting) because I had mistakenly let the UnicyclePlanner tag set to v0.3.0.

Running the WalkingModule and publishing the data on port /walking-coordinator/logger/data:o

• Set the superbuild environment

  conda activate robotologydeps
  export YARP_ROBOT_NAME="iCubGazeboV2_5"
  source <path-to-robotology-superbuild>/build/install/share/robotology-superbuild/setup.sh
  

  with robotologydeps as the conda environment where we installed all the superbuild dependencies.
• Follow the procedure described in https://github.com/ami-iit/yarp-openmct#prior-testing-the-visualization-tool-on-gazebo, steps 3 to 6, but before step 6, which runs the WalkingModule, activate the data dumping in https://github.com/robotology/walking-controllers/blob/devel/src/WalkingModule/app/robots/iCubGazeboV2_5/dcm_walking_with_joypad.ini, setting dump_data to 1, and run the logger module

  YARP_CLOCK=/clock WalkingLoggerModule
  

  After running the WalkingModule

  YARP_CLOCK=/clock WalkingModule
  

  The port /walking-coordinator/logger/data:o is created and automatically connected to /logger/data:i.
• Connect to the RPC server

  yarp rpc /walking-coordinator/rpc
  

• Run the RPC commands

  >>prepareRobot
  >>startWalking
  

  The WalkingModule starts publishing data on the port /walking-coordinator/logger/data:o.
• Read the port /walking-coordinator/logger/data:o in a termnal:

Port output

(
("com::position::desired" (0.0299999999999999988898 0.0 0.529899988757150275376)) 
("com::position::desired_macumba" (0.0299582133856958268692 0.000636738510544524924893 0.529899988757150275376)) 
("com::position::measured" (0.0305933314364956326914 0.000359349307267581297154 0.529458777506558897485)) 
("com::velocity::desired" (-0.0 -0.0 0.0)) 
("dcm::position::desired" (0.0299999999999999988898 0.0)) 
("dcm::position::measured" (0.0300396691878435651013 -0.00199682250252393705264)) 
("dcm::velocity::desired" (0.0 0.0)) 
("joints_state::positions::desired" (0.167904785687212843026 0.000160539041597503533794 -1.05770855588642660896e-05 -0.139094811089196718212 0.409184060910528113464 0.187738282501441478001 0.531822783012821820314 -0.139142431096789948031 0.408918175195152888701 0.187790167902857657589 0.531838499396436348299 0.0937185864284725833606 0.0223706281450002271438 -0.00446971439403916984828 -0.570005863711324445298 -0.370976381195379067979 -0.022099725580994527413 0.093240678046986422145 0.0240571897996484408699 -0.00488468657359045124039 -0.568331743771818609368 -0.369790025389783671983 -0.0252609266331014527263)) 
("joints_state::positions::measured" (0.177096007814525641111 -0.000588960220514245236245 -5.08469771771657974568e-05 -0.134937183159136386834 0.402775504983848675611 0.188807824348990599406 0.529731722659134263154 -0.134910547909866007643 0.403038256818131657155 0.188787307693771416739 0.529719064766377201181 0.0938021907453325809456 0.023174044442737518068 -0.00498655167820416522773 -0.575216070170718296595 -0.374753551950340713095 -0.022722878139411761822 0.0926697981852733360109 0.0247647892174729378212 -0.00560531336972847158556 -0.573748108180393678879 -0.374443296569439532107 -0.0255572824354075578412)) 
("joints_state::positions::retargeting" (0.154310356633131584569 -0.000154747966471365341109 3.8020401181747699032e-05 -0.0628816183723791277682 0.439704772199912663488 0.182527959237560294392 0.53871307853172911706 -0.0628469730878784826889 0.439686975741236885096 0.182542780657905301389 0.538695288958387252798 0.0899197810340430919718 0.023264924712665994988 -0.00458217478333733298917 -0.565609528032070540959 -0.373813503991503204293 -0.0236095055249985787127 0.0902435304130759646801 0.0232188257931553593272 -0.00445370376506189474125 -0.565830858266296532477 -0.373708007641638362273 -0.0237441493739279953223)) 
("joints_state::velocities::measured" (-0.00354051453501100015994 -0.0144402914585711715512 -0.00147239716918570111119 0.000526107274269146073242 0.00405264973647161998171 -0.000340574108314335970843 -0.000138306351171390944088 -0.00092194793785219976423 -0.00268092211097094735434 0.000137009211976376124587 4.37418231601528068042e-06 -0.00038534374368892534285 0.000414347342531321688464 -0.00314579614120415575543 -0.00465224751277207911743 0.00171012775295329181799 -0.020294616360614470274 -0.00724045444607844881912 0.00387092256089002946517 -0.00350031286614762519177 0.0101128277499450986571 0.00445221047720269387515 -0.0111461346779671757051)) 
("left_foot::angular_torque::measured" (-1.43421505355065548315 -4.94352032564792587266 -0.141064519201841626073)) 
("left_foot::angular_velocity::measured" (0.0 0.0 0.0)) 
("left_foot::linear_force::measured" (-6.12114961001202750879 3.40984773953337683139 156.042166594865676643)) 
("left_foot::linear_velocity::measured" (0.0 0.0 0.0)) 
("left_foot::orientation::desired" (0.0 -0.0 0.0)) 
("left_foot::orientation::measured" (0.0 -0.0 0.0)) 
("left_foot::position::desired" (0.0 0.0800000000000000016653 0.0)) 
("left_foot::position::measured" (0.0 0.0800000000000000016653 0.0)) 
("right_foot::angular_torque::measured" (1.42308421029612675035 -6.12894446114969682071 0.497879747125423877119)) 
("right_foot::angular_velocity::measured" (0.0 0.0 0.0)) 
("right_foot::linear_force::measured" (-9.92281011978284865904 -8.78855241710837020719 161.619708388976761171)) 
("right_foot::linear_velocity::measured" (0.0 0.0 0.0)) 
("right_foot::orientation::desired" (0.0 -0.0 0.0)) 
("right_foot::orientation::measured" (-0.000806915656784123786101 -8.56759114403120468546e-06 0.000861318132556340926645)) 
("right_foot::position::desired" (0.0 -0.0800000000000000016653 0.0)) 
("right_foot::position::measured" (-0.00026029841533876263036 -0.080776921812099194975 7.56672502068428398658e-05)) 
("zmp::desired" (0.0300436361066279203347 -0.00219650475277633101812)) 
("zmp::desired_planner" (0.0299999999999999988898 0.0)) 
("zmp::measured" (0.0347198336025381637526 -0.00181835508065580214732))
)

Note

If the port /logger/data:i doesn't exist by the time we run WalkingModule, the module fails since the connection to /logger/data:i is automatic and assumes its existence. Actually, for now the logging is locked to the use case where we dump the data, but in the future, logging and dumping the data could be independent, and in such case, the parameter could be renamed (CC @GiulioRomualdi ).

For using this logging feature with yarp-openmct telemetry visualizer, we need to connect /walking-coordinator/logger/data:o to an input port handled by yarp-openmct. As for the other signals handled earlier for visualization in yarp-openmct, the visualizer shall use a topic for creating a persistent connection, this way it doesn't need to assume the existence of the telemetry source port /walking-coordinator/logger/data:o.

Observed structure

<bottle>
   |___ <bottle>
   |         |____ <string> "com::position::desired"
   |         |____ <vector> (0.0299999999999999988898 0.0 0.529899988757150275376)
   |___ <bottle>
   |         |____ <string> "com::position::desired_macumba"
   |         |____ <vector> (0.0299582133856958268692 0.000636738510544524924893 0.529899988757150275376)
   |