"multi_robot_sim" tutorial, custom_joint_controller_ros_irotate problem about grade-rr HOT 13 CLOSED

To successfully run iRotate you need also to run this. That will download all the packages necessary for the exploration with the ground robot which follows our iRotate method and not FUEL.

Regarding your question, that is correct. Be sure that you "signal" that in the config file accordingly.

from grade-rr.

Hi, thanks for pointing that out. Are you trying to have multiple drones or a drone and the groove ne robot?

from grade-rr.

Thank you for replying me!

I'm trying to have 2 drones(drone_paper.usd) and a ground robot (robotino.usd) like original multi_robot_sim tutorial code (multi_robot_sim.py)

from grade-rr.

Ok, got the issue.
So, can you confirm that your setup is as follow:
something/catkin_ws with the FUEL, the 6dof controller etc
something/second_catkin_ws with the other packages for robotino
and that you added both on the setup_python_env.sh script (the second with the --extend keyword)?

In that case, your solution should work as intended.

What happened is that we were planning to merge the two controllers and use a single branch, but I did not yet finished that piece of code completely.
Checking out the correct fork of the iRotate repository will get this 6dof controller on your second workspace. The code in there, which you can find here, uses different ROBOT_IDs when launching to enact different code workflows. That's why your solution should work as well. Indeed, you specify the robot id here. Also, I've just noticed the absolute path few lines above, I'll correct also that one.

One thing that I can recommend is putting a [i]pdb.set_trace() just after the nodes have been launched and check the parameters and perhaps use a debug print to be certain that everything works correctly. If you notice issues, please go into the second catkin workspace, in which you have the controller, and change the package.xml and CMakeLists.txt to compile the controller as custom_joint_controller_ros_irotate. At that point remember to clean and recompile the workspace and everything should work as intended.

Sorry for this confusion. In the next few days I'll try a clean installation and check it out again. Perhaps merging the code in a single branch and updating the instructions.

If you have any issue at all please let me know.

from grade-rr.

I confirmed that my build process is little bit different with your response. I did not generate the second workspace for robotino.
I generated the only one workspace (/something/catkin_ws) with the FUEL, the 6dof controller etc followed only here. I'm sorry for my mistake. I'll try to generate the second workspace!

And then I wanna ask you one more question,
If I use only drone usd file, I don't need to generate the second worksapce(/something/second_catkin_ws) for robotino (related to irotate)? and Is it okay that i change the code from "custom_joint_controller_ros_irotate" to "custom_joint_controller_ros" in function (ros_launchers_setup) in robot_utils.py?

Thank you so much

from grade-rr.

Thank you for your replying!

For your help, I could run the code and publish the topics (imu, rgb).
But I have a question about the rosbag file.

when I published the topics(imu, rgb) using the code(paper_simulation.py) and manually recorded the imu/rgb topics to rosbag file, I could confirm that the total duration of rosbag was shorter than the actual time I recorded.

For example, i recorded the topics for a minute, but the recorded rosbag file duration is about 15 seconds. I can check this is because of the below code ( physics_dt (1/240) ). When i reduce the physics_dt to 60, the topic hz is set to 60 hz and the duration of rosbag file become similar as i actually acquired the file.

simulation_context = SimulationContext(physics_dt=1.0 / config["physics_hz"].get(),
	                                       rendering_dt=1.0 / config["render_hz"].get(),
	                                       stage_units_in_meters=0.01)

So I felt that it seemed that the data was being acquired in fast-forward.

To sum up :

• I would like to ask why the actual acquisition duration and the recorded bag file time are different.

from grade-rr.

what's the command you used to record the rosbags? can you share them?

from grade-rr.

Yes sure,

Just, I run the code (paper_simulation.py) and when the topics are published, I do below command in terminal
rosbag record {topic name /imu} {topic name /rgb}
( In terminal, I did roscore and rosparam set use_sim_time true before I run the paper_simulation.py )

Is the recording(rosbag) method wrong?

from grade-rr.

That seems correct. Personally, i usually record also the /clock message. But that shouldn't matter.also, I start recording while the simulation is still launching (i do not wait "manually" to see a topic).
Did you modify anything by chance? I asked because for that specific code i did several fresh installs and never had an issue.

Can you tell me how many messages are you getting in the standard settings (dt 1/240), and what is your experiment length? (From rosbag info).
Also, be sure to set the sim time before the rosbag record. Because from what you wrote there seems to be a timing problem since you have 15s 240hz, ~60s(15*4) 60hz (240/4).

from grade-rr.

Also, with the recorded bags we run ,this processing step to get the "reindexed" ones. But with the sleep call after the clock publishing this shouldn't be necessary.

from grade-rr.

Hi @Harin99 any news?

from grade-rr.

I'm so sorry for late reply. Since then, the experiment has not been able to proceed. I'll start again today and will comment in here.

Thank you so much for your help :)

from grade-rr.

Hi @Harin99. I am going to close this since I'm not able to reproduce. Please feel free to reopen if you can come up with additional info.

from grade-rr.