DASL Wiki

In this section I will briefly explain the PODO side of moving the DRC-Hubo model using a controller. This section will not help you control the model better but will help your understanding of how PODO and ROS worked together a little. This will also introduce ways you can find out how other pre-programmed buttons work and the code needed to do certain functions.
I will split this section into two smaller parts:

• PODO side
• PODO ROS connection

Open qt, open the simulator session and expand the PODOGUI project. Expand the Forms folder and open he TutorialDialog.ui file.

Since the .ui file is a design file it will open up in the Design tab. Right click the ROS Mode button and select Go To Slot.

Then just click ok on the pop up window.

This will take you to the place within the TutorialDialog.cpp file where the button's function is called when clicked. Here we see that the the command 'OMNIWHEEL_AL_ROS' is going to 'ALNum_Wheel'. If you go close to the top of the code you will see that ALNum_Wheel is actually the OmniWheel AL.

Thus when you press the ROS Mode button it is sending the message 'OMNIWHEEL_AL_ROS' to the AL OmniWheel. So now we can go to the OmniWheel Al and go to it's main.cpp file.

In the Initialization thread if you use Ctrl+f to find the 'OMNIWHEEL_AL_ROS' command you will see that it is leading to the Real Time Thread. This is what the _localCommand is. The 'WHEEL_ROSMODE' is the real time thread case that is used.

If you use Ctrl+f one more time to find 'WHEEL_ROSMODE' in the real time thread you can finally see the code that moves the motors on the model.

The first set of code calls the velocity values from the shared memory into the code. The second and third set of code then takes it and converts it into a degree value usable by the motor. The final set of code then sends the degree value to the motors. The SetMoveJoint command uses this syntax:([motor name], [Degree of movement], [time in milliseconds], [type of movement])

This is the PODO side of the code. We now need to find out how ROS and PODO are connected through the shared memory.

From the ROS side when you run the simulator and run ROS Mode if you run the command:

rostopic list

You will see all of the topics in use. Close to the top you will see cmd_vel. If you run the command:

rostopic info cmd_vel

This command will show you what programs are subscribed and publishing to the topic. You will see the that podo connector is subscribed to the topic.

If you go into the podo_connector.cpp file you will see that it takes the values given by cmd_vel and puts them into the shared memory. If you use Ctrl+f to find cmd_vel you will see that it is using a call back. If you right click the call back and select follow symbol under cursor it will take you to where the call back was defined.

Here we see that the data from cmd_vel is taken and put written into shared memory using the write() function.

This data is then taken from shared memory and put back into vel_cmd to use for the OmniWheel AL. This is how ROS and PODO work together. There has to be middle man (e.g.Daemon) that is able to take input from outside PODO and put it into shared memory in a way that is usable by programs inside PODO.

NOTE: This is a simplified picture, as when the command goes from PODOGUI it goes through shared memory to get to the AL as well but I though too many arrows going to shared memory would be confusing.
In this case with the controller, the input from the controller is taken by ROS and given to the middle man code (podo_connector) and converted into data usable by shared memory. This is then taken by the Omniwheel AL when prompted by the PODOGUI. The data in shared memory is then converted into a motor output and sent through Daemon (middle man) to be sent to ROS and used by the simulator. Finally we see the model in the simulators move.