Goal position should be visible in the GUI as a globe

[Erfi]

Description: Both for the purpose of debugging and for aesthetic reasons, the desired goal position should be visible.

Implementation: Make a call withing the reset() to the simulation and create the goal sphere according to the position sampled from the observation space.

Acceptance Criteria: Call to env.reset() + env.render() should show the desired goal as a sphere (preferably colored in a visible way).

[shamilmamedov]

In my branch dev_s I modified URDF files (almost all of them), so that the visualizer can visualize the goal position. To makes visualization easier I implemented FlexibleArmVisualizer that gets instantiated with a urdf_path and simulation step size. Then one can call visualoze_trajectory method and pass joint trajectory and a goal position. Using this class it should be straightforward to modify the env.render().

[Erfi]

I looked at your solution, but then figured that we could just add the goal sphere after loading the Robot's URDF (programmatically) and there is no need for modifying the URDF files. Conceptually I see the URDF info as description of physical objects (robot) and since this goal sphere is rather an imaginary object, I would rather have it added programmatically later in the scene. (We also might want to later add other things in the scene such as a number of small spheres representing the trajectory of the expert and such in a similar way).

See commit above (b8d29b5). This will make is easier to reset the goal as well.

[Erfi]

@shamilmamedov I will close this issue with this fix. Let me know what you think.

[shamilmamedov]

That's indeed a neat solution. I haven't worked with Panda3d visualizer directly. It seems that you define only once before starting the visualization. My solution that involves an overhead of changing a URDF allows changing the goal position on the fly allowing not only stationary goal, but also a moving ones. We have to think which solution is the best in the long run.

[Erfi]

I see. The points (spheres) can also be moved using the pandas3d, but if we are talking about the objects that are attached to the robot, I agree that they should be part of the URDF. So perhaps the following can be done:

• For Imaginary (not attached to the physical robot: no mass, no collision) we can use the panda3d engine to create them
• For physical objects that influence the robot (have mass, possible collision) we add them to the URDF (example: the wall)

[shamilmamedov]

I like your way of reasoning, but I would go even one step further and separate the robot from the environment. The whole thing can be done as follows:

• In the URDF define only the robot
• The environment takes the robot model and obstacles (Define class for an obstacle)

The reason why this solution is better because obstacles are not gonna be fixed and could be changed programmatically. Unfortunately, this solution would take more time to implement. Let me know if you think it is worth it

[Erfi]

Just to write down what we discussed in the call. I like you idea of dynamic obstacles, but this will: 1- Take more time 2- Become a transfer learning setting

This might be too difficult of a problem to solve for ICRA 2024. The dynamic goal sampling is already generalizing the environment to the multi-tasking problem!

So for now we will stick to multi-tasking, and leave the multi-tasking + transfer learning for next time!