Backport parameters

[pablogs9]

No description provided.

[codecov-commenter]

Codecov Report

Merging #263 (23e1f99) into foxy (97d7ac8) will increase coverage by 0.65%.
The diff coverage is 61.33%.

@@            Coverage Diff             @@
##             foxy     #263      +/-   ##
==========================================
+ Coverage   59.64%   60.29%   +0.65%     
==========================================
  Files          11       14       +3     
  Lines        1011     1549     +538     
  Branches      327      505     +178     
==========================================
+ Hits          603      934     +331     
- Misses        277      339      +62     
- Partials      131      276     +145     

Impacted Files	Coverage Δ
...c_parameter/test/rclc_parameter/test_parameter.cpp	31.53% <31.53%> (ø)
...clc_parameter/src/rclc_parameter/parameter_utils.c	56.09% <56.09%> (ø)
...lc_parameter/src/rclc_parameter/parameter_server.c	72.47% <72.47%> (ø)
rclc/src/rclc/executor.c	55.78% <0.00%> (+0.13%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 97d7ac8...23e1f99. Read the comment docs.

[pablogs9]

Do we have any idea on why CI RCLC Foxy / build (ubuntu-20.04, foxy) is passing one every 4 or 5 times and Fpr__rclc__ubuntu_focal_amd64 always is ok?

Do you know @JanStaschulat who is in charge of those ROS 2 actions? I would like to ask them if they are seeing the same behaviour in other packets

[Acuadros95]

I am going to test this on in our foxy hardware in the loop test bench

[JanStaschulat]

Do we have any idea on why CI RCLC Foxy / build (ubuntu-20.04, foxy) is passing one every 4 or 5 times and Fpr__rclc__ubuntu_focal_amd64 always is ok?

Do you know @JanStaschulat who is in charge of those ROS 2 actions? I would like to ask them if they are seeing the same behaviour in other packets

https://github.com/osrf/infrastructure

[JanStaschulat]

There seems to be a timing issue at the build farm:

   1: [ RUN      ] Test.rclc_node_init_default
  1: 
  1: >>> [rcutils|error_handling.c:108] rcutils_set_error_state()
  1: This error state is being overwritten:
  1: 
  1:   'parameter is a null pointer, at /__w/rclc/rclc/ros_ws/src/fh2edn9qp2a/rclc/rclc_parameter/src/rclc_parameter/parameter_server.c:234'
  1: 
  1: with this new error message:
  1: 
  1:   'node is a null pointer, at /__w/rclc/rclc/ros_ws/src/fh2edn9qp2a/rclc/rclc_parameter/src/rclc_parameter/parameter_server.c:236'
  1: 
  1: rcutils_reset_error() should be called after error handling to avoid this.
  1: <<<
  1/6 Test #1: rclc_parameter_test ..............***Timeout  60.06 sec

[Acuadros95]

Local test in hardware looks good

[JanStaschulat]

Local test in hardware looks good

how long did the test take? Especially the rclc_parameter_test?

[Acuadros95]

I used this test: https://github.com/micro-ROS/micro_ros_renesas_testbench/blob/foxy/test/micro_ros_renesas_testbench/test.cpp#L437
With the following micro-ROS code: https://github.com/micro-ROS/micro_ros_renesas_testbench/blob/foxy/test/micro_ros_renesas_testbench/client_tests/Parameters.c

I did not try the actual rclc package tests

Related: micro-ROS/micro_ros_renesas_testbench#113