Jesus/#169 camera info yaml

[JesusSilvaUtrera]

🦟 Bug fix

Closes #169

Summary

I have added a YAML file with the default camera intrinsics to load into the camera.launch.py file. I also included as a comment the link to the info of the camera, just in case we need more technical parameters of it.

The path to the YAML file is included as a parameter in the launch file, just in case it needs to be modified.

[JesusSilvaUtrera]

I have tried running it but as I don't possess an Andino at home, I haven't been able to fully test it, although no errors were found about the new YAML file.

[jballoffet]

Thanks @JesusSilvaUtrera for contributing to Andino!

Please notice that the DCO check is failing because the commit is not signed. See https://github.com/Ekumen-OS/andino/pull/231/checks?check_run_id=22874979577 for instructions on how to fix it.

On the other hand, I would appreciate it if you could use the full PR description template (nit).

Thanks!

[francocipollone]

Note that the camera intrinsics are used to publish a CameraInfo message typically at camera_info topic

https://docs.ros2.org/foxy/api/sensor_msgs/msg/CameraInfo.html

Here you are adding ros2 parameters via a yaml file. Which is actually good however those aren't intrinsics paremeters to the camera.
(Camera intrinsics and extrinsics )

The issue is aimed to provide intrinsics values (Ideally can be obtained via calibration, we could opt for something grabbed from out there typically for the RaspiCam) so as to be loaded by the v4l2_camera_node(or any other node that works for us) and to be ultimately published to the camera_info topic.
(e.g when running the simulation you will notice that you have two topics for the camera: The image and the camerainfo)

[JesusSilvaUtrera]

@francocipollone I have been looking into this and I have some questions (maybe some are silly, sorry in advance about that jaja):

• First, I have seen that in the gazebo simulation the 'libgazebo_ros_camera.so' plugin is used, which is trivial, but I have seen a strange behavior, since the camera_link is provided as the frame but in the camera_info topic the frame is base_link, as you can see here:

Also, I assume those distortion coefficients are set to 0 by default, not because a calibration has been done, and I also assume that when the intrinsics are computed (via calibration or via copying from the internet) they should also be specified here, as well as in the YAML file.

• Secondly, I have tried to see if I can find those intrinsic params somewhere for this camera model but so far the only site I have seen is this, and here no distortion coefficients are specified, so perhaps the best way to do this is just use the camera_calibration package and see the results for our specific case:

ros2 run camera_calibration cameracalibrator --size 7x9 --square 0.02 --ros-args -r image:=/my_camera/image_raw -p camera:=/my_camera

• Lastly, if you explain to me better which node is the responsible for publishing the CameraInfo message when it is being used with the real hardware, because from what I have seen in the docs of v4l2_camera this is only publishing the image, not the info, that is why in the YAML I only added parameters for that node, not the intrinsic parameters of the camera.

We can discuss these topics in a meeting if you prefer.

Thanks in advance!

[agalbachicar]

First, I have seen that in the gazebo simulation the 'libgazebo_ros_camera.so' plugin is used, which is trivial, but I have seen a strange behavior, since the camera_link is provided as the frame but in the camera_info topic the frame is base_link, as you can see here:

Interesting finding indeed! A couple of references:

• Where the frame_id is determined.
• Where the value is set in the published message.

That is expected behavior given how it is built (see here and here ). Note the function SensorFrameID(). Given that the description does not have a frame_name tag, it'll return the unscoped parent link name.

[agalbachicar]

Also, I assume those distortion coefficients are set to 0 by default, not because a calibration has been done, and I also assume that when the intrinsics are computed (via calibration or via copying from the internet) they should also be specified here, as well as in the YAML file.

Correct. I think we should try to unify them in one place and source them everywhere else.

[agalbachicar]

Lastly, if you explain to me better which node is the responsible for publishing the CameraInfo message when it is being used with the real hardware, because from what I have seen in the docs of v4l2_camera this is only publishing the image, not the info, that is why in the YAML I only added parameters for that node, not the intrinsic parameters of the camera.

Here you can find where the camera info is published in the very same v4l2_camera_node.

However, the publisher is used only when using intra_process_communication. I honestly don't know why that default. The way we are launching the node makes it behave that way, see the default rclcpp::NodeOptions::use_intraprocess_comm value (false). Reference to our launchfile and reference to the node executable.

To the best of my knowledge, to get the camera_info topic to be published we should have our own executable that takes care of creating and spinning the node.

[JesusSilvaUtrera]

So, just to recap after reviewing all of @agalbachicar references:

• The problem with the frame is a spelling mistake (the tag on andino_gz_classic.xacro is frameName and it should be frame_name to work.
• We need to perform the calibration of the camera (following this tutorial for example with the camera_calibration package). When the calibration is done, we should unify the camera intrinsics in one place to source it to everywhere else.
• The camera info is used always, but the topic camera_info is only published when use_intra_process_comms() evaluates to true. However, checking the code I don't see anywhere that it is expecting to receive the intrinsic parameters of the camera, the code just receives a camera_info_url (see here for all params) and load the intrinsic params from that URL. If that URL is not provided, the code just skips that part.
• As Agus suggested, we will need our own executable to change the rclcpp::NodeOptions and enable that flag (or others we may need).

We can discuss all of this and see which actions are better to take.

[agalbachicar]

Per F2F conversation with @JesusSilvaUtrera , we should be able to set also the intra_process_comms flag in the launch file preventing the creation of a custom binary to launch the node.

[francocipollone]

Sorry for the radio silence here.
Let me know if it is ready for review. I notice there are a couple of conflicts.

[JesusSilvaUtrera]

Sorry for the radio silence here. Let me know if it is ready for review. I notice there are a couple of conflicts.

Don't worry about this for now, it won't be ready until I have the camera and calibrate it (Javi has it right now, I will probably get it the next day we meet).

I will let you know when this is ready, thanks Franco!

[JesusSilvaUtrera]

Some notes here:

• I have performed the calibration of the raspi cam, and included the result in andino_bringup package in raspicam.yaml file. I tested it and it loads fine.
• With the tests made, I think we can close Enable compressed image transport #170 along with Adds camera_info yaml file #169.
• I have added in andino_hardware/README.md instructions the new steps to make the raspi cam work in Ubuntu Mate 22.04, so I think we can also close Camera from RPI has a driver issue in Ubuntu Mate 22.04 which prevents proper loading #198.

Let me know what do you think @francocipollone @jballoffet, thanks!

[francocipollone]

Thanks a lot for this contribution.
I haven't tested locally but I will. I left some comments to go

[francocipollone]

LGTM

[francocipollone]

nit: not sure where this name is being used however it catches my attention it says stereo when it is actually mono

[JesusSilvaUtrera]

Yeah, but the name is fixed by the hardware (happens the same when I used my webcam) so there is anything we can do about that. If I change the name on the YAML it won't use that file because it doesn't have the right name.

[JesusSilvaUtrera]

@francocipollone BTW, since Javi is OoO and I don't think he will review this, feel free to merge it once you don't have anything else to discuss (I can't do it because I don't have wrote permissions) . Thanks!