ROS driver

[zayfod]

People have integrated Cozmo with ROS using the official Cozmo SDK. It will be really convenient to get a Python ROS driver, based on PyCozmo though.

At a minimum, such a driver should make accessible:

• motor control
• odometers
• accelerometers and gyros
• the camera

[brean]

While doing this some example documentation/video "How to build your first ROS driver" would be awesome.

[brean]

I decided to start implementing a ROS-2-integration over the weekend. ROS-1 does not have official python3 support, pycozmo needs Python 3.5 or higher. I have not worked with ROS-2 yet, so I will also learn something new 😉.

[zayfod]

This is great news! :)

[solosito]

Hi @zayfod I started working on this topic and I already got to control Cozmo motors using the keyboard_teleop from ROS2 by subscribing to a Twist msg as well as publishing the images from the camera to a topic.

I will try to summarize what I did and push the changes before continuing :)

[solosito]

Hi @zayfod I pushed the first implementation using your wrapper to cozmo_ros2_nosdk.

This repository is used in cozmo_ros2_ws to run it with ROS2. There are some issues with the camera when using the callback with one_shot=False. Is it possible to set a max rate for the event dispatcher?

[zayfod]

Thanks for your work @solosito .

Would you please, describe the issue that you are seeing with image acquisition with one_shot=False ?

What do you mean by "set a max rate for the event dispatcher"?

Currently Cozmo pushes camera images automatically at a rate of ~15 FPS and each successfully received image generates an event.

[solosito]

Hi, sorry for my vague description. I already solved the problem. I was using it wrong.

Regarding the this issue, I already got working all that you were asking:

• motor control
• odometers
• accelerometers and gyros
• the camera

Check this out: https://github.com/solosito/cozmo_ros2_ws/

[zayfod]

Good to hear.

I am looking forward to playing with your code.

Would you be willing to merge your work in PyCozmo or you plan to keep it separate? Both approaches make sense to me and have their advantages and disadvantages.

[solosito]

I was considering the same. I just finally decided to go with this approach just for keeping separated the PyCozmo library from the ROS2 wrapper. A ROS (1) wrapper could be created the same way I did for ROS2.

Nevertheless, I am opened to suggestions.

[zayfod]

I agree that there is an advantage of keeping the ROS2-specific code separate. At the moment though, PyCozmo is heavily under development and significant changes to the client API are to be expected. For example, I just changed the Vector3 type of the pose member variable to a new Pose type, which break the compatibility with your code.

I lean toward integrating the ROS2 support in PyCozmo directly for the following 2 reasons:

• the client API will keep changing for awhile
• you already seem to be using your own branch of PyCozmo

This would allow more people to have a working solution, out of the box.

The ROS2 support can be handled as a "pip extra" - https://packaging.python.org/tutorials/installing-packages/#installing-setuptools-extras

For example, the original Cozmo SDK handles dependence on OpenGL in a similar fashion.

What do you think?

[snowgoon88]

Hello, I have begun to write ROS (1) node(s) for the Cozmo => CozmoBot on github. I have only tested on the noetic version of ROS as it uses python3.

Only basic functions are available (camera image, moving wheels, head and lift) for now. There is also a cozmo_joy node that allows a crude Remote Control ( #37). I am also playing with OpenCv to try to detect the cubes of the cozmo... You can see it is a work in progress, where a lot of progress is still to be made :o) (#35).

I will have a look to the ROS2 driver. To learn and maybe standardize topics.

So, it works but it is in pre-alpha state...