Changing the joint position on a robot

edit

Hmm i think you're right! I'll give it a shot for sure, ty!

I'm guessing the only downside would be that i won't see the sensor model itself anymore right?

If you include the sensor model in the urdf, but then not attach it using a joint but using a TF, you can still visualise the model.

So you wouldn't publish the sensor frame, but the TF between your robot and the model of the sensor (which would itself define the sensor frame (ie: the frame to which measurements are relative)).

RViz (and every other consumer of the URDF) probably won't be happy until you start publishing the TF, but it should work.

Hmm so if i comment out the joint and leave the link declared i get the following error Failed to find root link: Two root links found: [base_footprint] and [left_front_rplidar_link] Furthermore, I don't believe gazebo will care if I change the tf right? I think gazebo only looks at the sdf that is created with the spawner.py once and then never looks at it again. I think a solution would be to just do a test run -> change the urdf -> delete the robot model -> spawn new model

I'd sort-of missed the part where you're using Gazebo.

That complicates things a bit.

You could perhaps go into the direction of a Gazebo plugin which is responsible for updating the model, but I'm not sure how that would work.

If you're reusing the URDF for Gazebo as well, perhaps going the way of editing the .urdf/.xacro itself might be more scalable/less involved.

If you end up doing this, post it as an answer and accept your own answer.

I'll leave my answer but prefix it with a comment clarifying how Gazebo makes this more complex.

Will do. Following this, do you think it would be possible to spawn the robot and the sensor separately (but maintaining them connected). This way I could just delete the sensor model and spawn another one instead of spawning the whole robot all over again.

I would personally not do that, as I'm not sure it's going to work correctly (there are many parts of the infrastructure which may not like you doing that).

So just the whole robot would probably be safer?

Yes, I'd think so. But I haven't checked.

I would probably restart everything, just to make sure. Especially if you're going to use this setup for experiments: identical circumstances for each iteration would seem like they'd be important/required, and you can't guarantee that unless you shutdown and restart.

Okay, thank you! Btw, a little of topic, but to keep the same path for the robot with each run I was trying to record /cmd_vel topic and just replay it every time run a new test trail. However the robot is not following the same path. Is this known problem when replaying a /cmd_vel bag or could i be doing something wrong?

cmd_vel topics carry geometry_msgs/Twist messages in most cases.

Those encode velocities. Not positions.

So you're not recording a path, but the first time-derivative of one.

As friction is also simulated by Gazebo, and there are numerical inaccuracies (which also accumulate over time), it's very likely replaying velocities will not result in the exact same positions.

If you're only interested in comparing the output of SLAM algorithms, but not use them to navigate or explore each time (ie: you want to provide each algorithm with the exact same input), then I would not use Gazebo at all for your experiments.

Record a rosbag while navigating your simulation world. The .bag contains the sensor data.

Now for each algorithm, play back the .bag.

Each algorithm will get the exact same input, greatly increasing repeatability of your experiments, avoiding simulation overhead and also making my suggestion (using TF) possible again.

Yes i've done just that in my previous experiments but now the situation is different. With the results that I have obtained from the comparison of the different SLAMs i will now pick just one SLAM and try to improve it's performance by changing the position/orientation of the laser which will in turn change the /scan messages that I receive. Therefore, with every test loop (same SLAM different position/orientation of sensor) i still require gazebo to run. Since the /cmd_vel is changed i see that one option to keep an "similar" path with each run would be to record a number of goals and just replay them with some kind of planner. Also, maybe instead of replaying the /cmd_vel maybe i can record and playback the position of the robot over time?