UDP client-server protocol

[alaurenzi]

Hi, let's use this issue to find an agreement on the UDP protocol to be followed in the upcoming demo(s).

I have prepared a draft packet, that you can check here.

Based on this packet layout, we could implement a minimal state machine as follows.

UDP server (i.e. slave side, or robot)

• wait for a UDP master2slave packet on a given port (8081 at the moment)
• upon reception, reply to the client with a slave2master feedback packet
• if master2slave::run was true, the received pose command is forwarded to the IK

See this ROS-based example.

UDP client (i.e. master side, or tele-operation device)

• send UDP master2slave packet to the server's address/port; master2slave::run is set to false, as the client does not know how to initialize its pose command; master2slave::ee_id is the URDF name of the link to control;
• try to receive the response packet from the server (i.e., non-blocking recvfrom); the first time a response packet is received, the client's pose command is initialized with the received feedback data, and master2slave::run is set to true

[alaurenzi]

A docker based on the latest commit of the demo2022 branch is now available for testing.

How to

• On the host machine, setup a clean ROS network (roscore)
• From the repo's root folder, issue a ./docker/run-docker.bash
• Wait for image to download
• A terminator instance will appear
• Split the terminal in two
• On terminal A: mon launch centauro_cartesio_config centauro_manipulation.launch gui:=true
• On terminal B: tom_centauro_udp_server_ros
• [Optional] On a third terminal C: tom_centauro_udp_client_ros
• The robot arm moves up and down

@siddharthdeore

[siddharthdeore]

Hi @alaurenzi,

Docker image is perfect, I have updated the packet and tested it with new dummy client, pushed to the branch.

Master to Robot

• Quaternion for rotation in packet master2slave and slave2master
• Two axis joystick states x and y in master2slave varies in range -1 to 1 and three button states.
• Desired heading about z axis. (absloute angle or velocity)
• base position in x, y (can be velocity command)`

Robot to Master

• base position and heading (if controlling base with velocity command, do we need it?)

Thanks.

[alaurenzi]

Super! I am pushing the updated docker image with latest changes that you have done. Maybe you can pull it and give it a go. Then, we can move on the base motion.

[alaurenzi]

@siddharthdeore I added support for velocity control (useful for commanding the mobile base). Also, there is a new launch file to run the IK engine, which is kept inside this repository. The ee_id for the base control is car_frame.

Pull the image to see the changes: docker pull arturolaurenzi/tom_centauro:latest

Updated steps

• run a fresh roscore on host machine
• ./docker/run-docker.bash
• Terminal A: mon launch tom_centauro centauro_collision_avoidance.launch gui:=true
• Note: velocity control must be enabled via ROS service. To do it, on terminal B: rosservice call /cartesian/car_frame/set_control_mode velocity
• Terminal B: tom_centauro_server_ros
• [Optional] Terminal C: tom_centauro_client_velocity_ros car_frame 1.0 0.0 0.0 # ee_id vx vy vtheta
• The robot moves forward at full speed

[siddharthdeore]

Hi, @alaurenzi , I have pulled latest image with tag arturolaurenzi/tom_centauro:latest, although I see old packet structure perhaps old code inside container. For now I will manually building image and with updated source.

Can you confirm if build image is pushed to dockerhub?

PS: I have tried clearing all image cache and pulled fresh image.

Thanks

[alaurenzi]

My bad, should be fixed now