Integrate with Gazebo #68

tahsinkose · 2020-06-11T10:42:31Z

~~Needs a bit more work to have the minimal intrusion.~~

Now it should be ready. The bulk of the change is due to now filled moveit.rviz. The version in the base repo is an almost empty -- default Rviz config file, whereas now all the juicy MoveIt stuff is loaded within.

config/panda.srdf

davetcoleman · 2020-06-11T19:28:03Z

config/ros_controllers.yaml

@@ -0,0 +1,93 @@
+# MoveIt-specific simulation settings


so as to not get confused with
https://github.com/ros-planning/panda_moveit_config/blob/melodic-devel/config/panda_controllers.yaml

Can we rename this file to something like gazebo_ros_controllers.yaml?

But this file is the one auto-generated through the Setup Assistant tutorial. If I rename this, Gazebo integration tutorial should be updated and it might be confusing to have ros_controllers.yaml and gazebo_ros_controllers.yaml at the end of two tutorials (one after the other).

Moreover, I couldn't find any actual use of panda_controllers.yaml. Are you sure it is being used?

FWIW, panda_controllers.yaml was used here.

davetcoleman · 2020-06-11T19:28:54Z

config/sensors_3d.yaml

@@ -0,0 +1,10 @@
+# The name of this file shouldn't be changed, or else the Setup Assistant won't detect it


how is this file different from
https://github.com/ros-planning/panda_moveit_config/blob/melodic-devel/config/sensors_kinect_pointcloud.yaml

? @Ridhwanluthra

This was auto-generated as well along with sensors_kinect_pointcloud.yaml and sensors_kinect_depthmap.yaml 🙂

launch/move_group.launch

davetcoleman · 2020-06-11T19:30:22Z

launch/move_group.launch


    <!-- Publish the planning scene of the physical robot so that rviz plugin can know actual robot -->
    <param name="planning_scene_monitor/publish_planning_scene" value="$(arg publish_monitored_planning_scene)" />
    <param name="planning_scene_monitor/publish_geometry_updates" value="$(arg publish_monitored_planning_scene)" />
    <param name="planning_scene_monitor/publish_state_updates" value="$(arg publish_monitored_planning_scene)" />
    <param name="planning_scene_monitor/publish_transforms_updates" value="$(arg publish_monitored_planning_scene)" />
-
-    <remap from="/joint_states" to="/joint_states_desired" />


you probably want to keep this

If I keep this, MoveIt can't fetch proper joint values. In demo.launch there is:

<node name="joint_state_desired_publisher" pkg="topic_tools" type="relay" args="joint_states joint_states_desired" /> followed by the inclusion of this launch file. When used in conjunction, these two work. But demo_gazebo.launch lacks that hence just reverting this won't work.

launch/ompl_planning_pipeline.launch.xml

tahsinkose · 2020-06-13T16:55:56Z

launch/move_group.launch

-    <arg name="moveit_controller_manager" value="panda" if="$(eval not arg('fake_execution') and not arg('load_gripper'))"/>
-    <arg name="moveit_controller_manager" value="panda_gripper" if="$(eval not arg('fake_execution') and arg('load_gripper'))"/>


I'm not sure why this difference has been ever introduced, there is no specified namespacing regarding to panda_gripper in the base repo in any of the controller configurations.

There is launch/panda_gripper_moveit_controller_manager.launch.xml as well as src/panda_moveit_config/launch/panda_moveit_controller_manager.launch.xml.

tahsinkose · 2021-01-23T11:50:02Z

@davetcoleman PTAL.

tahsinkose · 2021-01-23T19:57:08Z

Needs frankaemika/franka_ros#126 to be merged.

simonbogh · 2021-01-29T15:08:02Z

Thanks @tahsinkose for putting the effort into getting Panda available in Gazebo, hope to see this merged soon.

I tested both your PRs together and everything works on my end, though the gripper fingers are a bit "soft" so maybe the gains need to be adjusted, see at 0:32 https://youtu.be/JrAq8LK5l1M.

Any suggestions?

simonbogh · 2021-01-30T22:32:01Z

Also, panda_controllers.yaml is still present but seems to never be used/loaded.

tahsinkose · 2021-01-31T09:18:11Z

@simonbogh thank you very much for the video. I didn't actually test grippers for grasping. I'm not an expert on gripper dynamics, so cannot give any suggestions. Try to increase P gains of the fingers to have a stiffer grasp.

tahsinkose · 2021-01-31T09:19:38Z

Also, panda_controllers.yaml is still present but seems to never be used/loaded.

I'm not cleaning up all the auto-generated files, so there may be artifacts that are not used at all. Please ignore them in this PR.

simonbogh · 2021-01-31T10:30:43Z

Also, panda_controllers.yaml is still present but seems to never be used/loaded.

I'm not cleaning up all the auto-generated files, so there may be artifacts that are not used at all. Please ignore them in this PR.

Alright, as long as it is working 😊 (just a disclaimer, I am not an officiel reviewer, just here as a user).

I also changed my local version to use effort controllers instead as I need that.

Do you remember what version of moveit setup asssistant the package was generated with? I made a quick test importing it into the current 1.0.7 (Melodic), and besides some manual settings (e.g. PID gains), there seems to be some changes. According to the timestamp in .setup_assistant it was last generated in Feb. 2018, but I don't know if this is accurate. It could maybe make sense to regenerate the package with the latest setup assistant.

tahsinkose · 2021-03-10T22:08:16Z

Do you remember what version of moveit setup asssistant the package was generated with?

Unfortunately not 😞

fwalch · 2021-03-18T12:33:23Z

I didn't look into this in detail yet, just wanted to report some results on Noetic. I'm trying to run roslaunch franka_example_controllers move_to_start.launch robot_ip:=<ip>.

With d99e64f (current melodic-devel of panda_moveit_config) and frankaemika/franka_ros#126, this executes without issues.

With this branch and frankaemika/franka_ros#126, I'm getting the following:

[ WARN] [1616070427.320851483]: Link 'panda_hand' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322043080]: Link 'panda_hand' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322078747]: Link 'panda_hand' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322097331]: Link 'panda_hand' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322114854]: Link 'panda_hand' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322132436]: Link 'panda_hand' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322150106]: Link 'panda_hand' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322167521]: Link 'panda_leftfinger' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322185301]: Link 'panda_leftfinger' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322202800]: Link 'panda_leftfinger' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322219829]: Link 'panda_leftfinger' is not known to URDF. Cannot disable collisons.
[ WARN] [1616070427.322236838]: Link 'panda_leftfinger' is not known to URDF. Cannot disable collisons.
[ INFO] [1616070427.322355330]: Loading robot model 'panda'...
[ WARN] [1616070427.322384402]: Skipping virtual joint 'virtual_joint' because its child frame 'panda_link0' does not match the URDF frame 'world'
[ INFO] [1616070427.322402792]: No root/virtual joint specified in SRDF. Assuming fixed joint
[ INFO] [1616070427.375235427]: Publishing maintained planning scene on 'monitored_planning_scene'
[ INFO] [1616070427.377156874]: MoveGroup debug mode is OFF
Starting planning scene monitors...
[ INFO] [1616070427.377204891]: Starting planning scene monitor
[ INFO] [1616070427.378503155]: Listening to '/planning_scene'
[ INFO] [1616070427.378538420]: Starting world geometry update monitor for collision objects, attached objects, octomap updates.
[ INFO] [1616070427.379716602]: Listening to '/collision_object'
[ INFO] [1616070427.380909800]: Listening to '/planning_scene_world' for planning scene world geometry
[ INFO] [1616070427.388197131]: Listening to '/camera/depth_registered/points' using message filter with target frame 'world '
[ INFO] [1616070427.394604908]: Listening to '/attached_collision_object' for attached collision objects
Planning scene monitors started.
[ INFO] [1616070427.433130766]: Using planning interface 'OMPL'
[ INFO] [1616070427.435098071]: Param 'default_workspace_bounds' was not set. Using default value: 10
[ INFO] [1616070427.435418519]: Param 'start_state_max_bounds_error' was set to 0.1
[ INFO] [1616070427.435714579]: Param 'start_state_max_dt' was not set. Using default value: 0.5
[ INFO] [1616070427.436015285]: Param 'start_state_max_dt' was not set. Using default value: 0.5
[ INFO] [1616070427.436297072]: Param 'jiggle_fraction' was set to 0.05
[ INFO] [1616070427.436582894]: Param 'max_sampling_attempts' was not set. Using default value: 100
[ INFO] [1616070427.436642656]: Using planning request adapter 'Add Time Parameterization'
[ INFO] [1616070427.436676221]: Using planning request adapter 'Resolve constraint frames to robot links'
[ INFO] [1616070427.436701223]: Using planning request adapter 'Fix Workspace Bounds'
[ INFO] [1616070427.436724797]: Using planning request adapter 'Fix Start State Bounds'
[ INFO] [1616070427.436748357]: Using planning request adapter 'Fix Start State In Collision'
[ INFO] [1616070427.436764898]: Using planning request adapter 'Fix Start State Path Constraints'
[INFO] [1616070427.562306]: Controller Spawner: Waiting for service controller_manager/load_controller
[INFO] [1616070427.571215]: Controller Spawner: Waiting for service controller_manager/switch_controller
[INFO] [1616070427.575872]: Controller Spawner: Waiting for service controller_manager/load_controller
[INFO] [1616070427.581625]: Controller Spawner: Waiting for service controller_manager/unload_controller
[INFO] [1616070427.584948]: Controller Spawner: Waiting for service controller_manager/switch_controller
[INFO] [1616070427.590181]: Loading controller: position_joint_trajectory_controller
[INFO] [1616070427.592954]: Controller Spawner: Waiting for service controller_manager/unload_controller
[INFO] [1616070427.602346]: Loading controller: franka_state_controller
[INFO] [1616070427.624754]: Controller Spawner: Loaded controllers: position_joint_trajectory_controller
[INFO] [1616070427.631478]: Controller Spawner: Loaded controllers: franka_state_controller
[ INFO] [1616070427.633593568]: FrankaHW: Prepared switching controllers to joint_position with parameters limit_rate=1, cutoff_frequency=100, internal_controller=joint_impedance
[INFO] [1616070427.634894]: Started controllers: position_joint_trajectory_controller
[INFO] [1616070427.638682]: Started controllers: franka_state_controller
[ WARN] [1616070432.449204725]: Waiting for panda_arm_controller/follow_joint_trajectory to come up
[ WARN] [1616070438.449375320]: Waiting for panda_arm_controller/follow_joint_trajectory to come up
[ERROR] [1616070444.449532523]: Action client not connected: panda_arm_controller/follow_joint_trajectory

The warning [ WARN] [1616070427.322384402]: Skipping virtual joint 'virtual_joint' because its child frame 'panda_link0' does not match the URDF frame 'world' has already been there, the other warnings/errors are new.

fwalch · 2021-03-18T17:31:27Z

config/ros_controllers.yaml

+    - panda_joint5
+    - panda_joint6
+    - panda_joint7
+  gains:


Are these used for a position controller? I thought they only apply to effort/velocity controllers.

@fwalch, I had the same understanding. I think the PID gains are a residual from the original commit of @erdalpekel in which an effort hardware interface was used. @tahsinkose, do you know if this is the case?

In a more recent commit, Erdal also migrated to using a position hardware interface. I, therefore, think the PID gains could be removed.

While doing this, I noticed that I could not remove the PID gains set for the gazebo_ros_control plugin. In my current understanding, this is because of a known problem with gazebo (see this gazebo answers question for more information).

Alternatively, we could also change the controller interface to effort_controllers/JointTrajectoryControllerbut then we also need to change the hardware interface in the franka_ros/franka_description/robots/panda.control.macro (see this [franka_ros](https://github.com/rickstaa/franka_ros/tree/noetic-devel-simulation-effort-hardware-interface and panda_moveit_config branch). I, however, think removing the PID gains and keeping the joint hardware interface, and the joint controller is cleaner.

No they are not. This will be removed with https://github.com/tahsinkose/panda_moveit_config/pull/3

@fwalch tahsinkose#3 was replaced by tahsinkose#4

tahsinkose · 2021-05-05T11:05:21Z

The warning [ WARN] [1616070427.322384402]: Skipping virtual joint 'virtual_joint' because its child frame 'panda_link0' does not match the URDF frame 'world' has already been there, the other warnings/errors are new.

@fwalch Probably there is a namespace mismatch. I'll try to look into it.

rickstaa · 2021-04-30T14:54:31Z

config/ros_controllers.yaml

+    - panda_joint5
+    - panda_joint6
+    - panda_joint7
+  gains:


@fwalch, I had the same understanding. I think the PID gains are a residual from the original commit of @erdalpekel in which an effort hardware interface was used. @tahsinkose, do you know if this is the case?

In a more recent commit, Erdal also migrated to using a position hardware interface. I, therefore, think the PID gains could be removed.

While doing this, I noticed that I could not remove the PID gains set for the gazebo_ros_control plugin. In my current understanding, this is because of a known problem with gazebo (see this gazebo answers question for more information).

Alternatively, we could also change the controller interface to effort_controllers/JointTrajectoryControllerbut then we also need to change the hardware interface in the franka_ros/franka_description/robots/panda.control.macro (see this [franka_ros](https://github.com/rickstaa/franka_ros/tree/noetic-devel-simulation-effort-hardware-interface and panda_moveit_config branch). I, however, think removing the PID gains and keeping the joint hardware interface, and the joint controller is cleaner.

rickstaa · 2021-05-05T11:25:14Z

config/ros_controllers.yaml

+    - panda_joint5
+    - panda_joint6
+    - panda_joint7
+  gains:


@fwalch tahsinkose#3 was replaced by tahsinkose#4

tahsinkose · 2021-05-06T20:30:58Z

Action client not connected: panda_arm_controller/follow_joint_trajectory

This was because ros_controllers.launch was included only in gazebo.launch. Now I moved it to move_group.launch. Please try again @fwalch.

rickstaa · 2021-07-16T14:14:07Z

@tahsinkose Is this pull request ready to be merged? I added https://github.com/tahsinkose/panda_moveit_config/pull/7, which can also be included in this pull request. This pull request gives users the ability to specify the hardware interface that is used. It needs to be merged together with https://github.com/tahsinkose/franka_ros/pull/1.

tahsinkose · 2021-07-30T08:50:27Z

@rickstaa it requires approval from @fwalch.

rickstaa · 2021-08-26T11:01:56Z

@tahsinkose Now that https://github.com/frankaemika/franka_ros/releases/tag/0.8.0 has been released #68 might need some changes. In v0.8.0 the robot urdf were modified such that they contain all the components needed for creating a gazebo simulation. Further, Franka Emika also added the franka_gazebo package which contains a more stable/accurate simulation.

For ROS noetic, I implemented two versions of the panda_moveit_config:

Fixes the gazebo simulation rickstaa/panda_moveit_config#40 uses the gazebo_demo.launch file that is supplied by the moveit_setup_assistant to create a gazebo simulation. This is similar to how it is done in this pull request.
Adds 'franka_gazebo' gazebo simulation rickstaa/panda_moveit_config#39 uses the franka_gazebo package to create a more stable/accurate simulation.

These pull requests are currently on an orphan branch. I did this so that it is easier to track the changes needed after the 'moveit_setup_assistant' was run. I am however happy to rebase them onto the noetic-devel and melodic-devel branches. I however think that the @ros-planning team first needs to decide which version they want to include inside the https://github.com/ros-planning/panda_moveit_config repository and which version they want to add to the https://github.com/ros-planning/moveit/tree/master/moveit_setup_assistant.

To give my two cents. I think adding version 2 would make the most sense since it is more closely related to the real robot. The downside is that it is different from the implementation that is created when running the moveit_setup_assistant. In this case, we therefore also need to decide which files we want the moveit_setup_assistant to create. Maybe, since the moveit_setup_assistnat is meant to be more general, let's use version 1 there and use version 2 for the panda_moveit_config.

tahsinkose · 2021-08-26T11:24:47Z

Unfortunately, I'm unable to take any action on this branch as I can't allocate time for this PR as of now @rickstaa. It needs to wait a couple of more weeks. Sorry for the inconvenience.

rickstaa · 2021-08-26T11:53:19Z

@tahsinkose No problem, let's wait for some feedback from the @ros-planning team before we proceed with finalizing this feature.

rickstaa · 2021-08-30T09:03:13Z

I created this issue to alert the Franka team about the issues we are having with the JointPositionInterface.

rickstaa · 2021-09-27T15:39:46Z

The following steps need to be performed when we want to use the new franka_gazebo package for the Gazebo simulation (see version 2 above):

Fixes franka_gripper_sim GripperCommand action frankaemika/franka_ros#173 needs to be merged. The current implementation supplied by frankaemika contains a small bug that prevents users from setting specific gripper widths.
We need to find PID gains for the effort_controllers/JointTrajectoryController. The current PID gains lead to several issues (see [feature_request] Adds ability to switch gazebo hardware interface frankaemika/franka_ros#161 (comment)). I created [feature_request] Adds ability to switch gazebo hardware interface frankaemika/franka_ros#161 to see if frankaemika is able to provide a better solution.

rickstaa · 2021-10-20T14:21:33Z

The gazebo simulation is working on the noetic branch. We can backport it to melodic-devel when rhaschke#8 is merged.

rickstaa · 2021-10-21T09:38:33Z

@rhaschke I think @tahsinkose can safely backport c46c81c into the melodic branch? To my knowledge, franka_ros v0.8.1 works with melodic (see https://github.com/frankaemika/franka_ros-release).

rhaschke · 2021-10-21T10:34:00Z

@rhaschke I think @tahsinkose can safely backport c46c81c into the melodic branch?

If it was tested on Melodic, sure.

tahsinkose · 2021-10-21T11:57:42Z

Tested and not working. I think c46c81c alone doesn't suffice.

rickstaa · 2021-10-21T12:06:20Z

@tahsinkose did you install franka_ros from source and pull all the upstream changes. You can use my branch to test it out. If so what are the problems you encounter?

tahsinkose · 2021-10-21T12:10:23Z

@tahsinkose did you install franka_ros from source and pull all the upstream changes

Yes sure. I'm already using your branch. My configuration is as follows:

The issue is No such file or directory: /home/tahsincan/franka_ws/src/franka_ros/franka_description/robots/panda_arm_hand.urdf.xacro when I run roslaunch panda_moveit_config demo_gazebo.launch.

This commit adds demo_gazebo.launch using the gazebo simulation of the franka_gazebo package Additionally, the virtual_joint is removed from the move group definition.

tahsinkose · 2021-10-21T14:35:46Z

@rhaschke, @rickstaa we should stop targetting the latest release of franka_ros in panda_moveit_config:melodic-devel. This PR now sufficiently works with rickstaa/franka_ros@f9128cd, which adds position and velocity motion generators.

I suggest merging frankaemika/franka_ros#181 ASAP and fixating the updated franka_ros version with version_eq in this PR with a final commit. I'm deliberately suggesting version_eq -and not version_gte- because launch file (now this repo depends on franka_gazebo/panda.launch) changes are much harder to detect and there is no integration testing pipeline between here and franka_ros. Just one unused argument change without notice and everything would be broken. Melodic EOL is 1.5 years from now on and I say this should remain stable till then. There is simply no point in having all the newest stuff for this version.

TL;DR: If someone needs more sim2real alignment in panda robot, then relatively more unstable Noetic is the way to go :P melodic-devel should stay just as a PoC for MoveIt-Gazebo integration, that's it.

Docs todo:

Copy https://github.com/ros-planning/moveit_tutorials/tree/master/doc/gazebo_simulation to moveit_tutorials:melodic-devel and update according to the latest changes enforced here and franka_ros dependency.

rickstaa · 2021-10-21T15:18:19Z

@tahsinkose Sounds good to me.

rhaschke · 2021-10-21T18:36:56Z

All this strongly depends on how franka_ros evolves. This repo needs to adapt to franka_ros. Honestly, I suggest that panda_moveit_config should be handled by Franka again. Having responsibilities shared didn't turn out to be fruitful.
@davetcoleman: What is your take on this?

tahsinkose · 2021-10-21T19:48:38Z

@rhaschke I'm not saying that this repo should not evolve. The latest version -in this case noetic-devel- should of course evolve simultaneously with franka_ros ideally with the same ROS versions (although they still seem to actively bump melodic and noetic with the same tags). Even more, they should have a simple integration pipeline that would at least inform maintainers of both sides about the possible breaks. However, this is just a dream 🙂

Again, the idea behind this PR was to provide a proof of concept MoveIt-Gazebo integration, which was the subject of https://ros-planning.github.io/moveit_tutorials/doc/gazebo_simulation/gazebo_simulation.html. Yet it inadvertently evolved to full support of all the new changes from franka_ros. This very effort is being invested in panda_moveit_config:noetic-devel already. I can't see a strong reason for doubling it for Melodic that will EOL in 17 months. Would it be the last ROS1 version, it might be continued until that time, but that guy is Noetic. It is not ROS2 after all 🤷🏼‍♂️

My point is focusing dev efforts of this repo on Noetic. So that means stopping Melodic with what we have now in this PR - an integration PoC- with a trace to a sufficiently working version of franka_ros.

rhaschke · 2021-10-21T20:05:36Z

I completely agree with you regarding focussing our efforts on Noetic (or even better ROS2).
However, when you state to merge this PR as a PoC as is, I cannot agree. As you wrote, it relies on some unmerged and unreleased features (frankaemika/franka_ros#181). Hence, it's not (yet) working with a set of standard debian packages. Further, we don't have control over the evolution franka_ros. If they decide to release breaking changes, this repo needs to be adapted accordingly.

tahsinkose · 2021-10-21T20:13:11Z

However, when you state to merge this PR as a PoC as is, I cannot agree. As you wrote, it relies on some unmerged and unreleased features (frankaemika/franka_ros#181)

I already suggested to wait for the immediately next minor of franka_ros after frankaemika/franka_ros#181 🙂. Assuming that is done, why would any breaking changes on newer releases break melodic-devel as long as we make a version_eq dependency to that minor?

rhaschke · 2021-10-21T20:18:06Z

Ah. Now I understand your reasoning. The problem is: ROS apt repos don't maintain old versions. Hence you cannot lock to a specific version.

tahsinkose · 2021-10-21T20:44:59Z

Hmm, that's very sad. Then this will definitely break sometime in the future, it is just a matter of when 🙂 I got your reasoning too 👍🏼

v4hn · 2021-10-22T10:08:54Z

Then this will definitely break sometime in the future, it is just a matter of when 🙂 I got your reasoning too 👍🏼

Again, that depends on upstream. noetic is under active development and melodic matured a lot and is considered mostly stable these days. I fail to understand why they still push breaking changes there. They really shouldn't. Either way it would definitely be a good idea to add a paragraph somewhere stating the exact commit/version for the franka repository the demo was tested with. Everything after that *might* be supported, but could fail.

rickstaa · 2021-10-24T08:20:58Z

@tahsinkose Thanks again for back-porting the noetic-devel simulation into your pull request. Can you maybe also apply the changes made in #91 (review) when it is merged.

@rhaschke is also working on a panda simulation that doesn't require the franka_gazebo package see rhaschke#9. I think we should also back-port this into your pull request when it is finalized. After that, I think we can merge #68 into the melodic-devel branch.

rhaschke · 2021-10-24T10:30:22Z

I'm tempted to close this issue in favour of #89 and rhaschke#9.

rickstaa · 2021-10-25T08:24:57Z

@rhaschke Do you mean back-porting those pull requests into the melodic-devel or updating the melodic-devel branch with all the code found in the noetic-devel branch?

I think both cases are fine and greatly improve maintainability. It looks like there were no breaking changes regarding the XML and xacro syntax between ros-noetic and ros-melodic but I'm not 100% sure (see http://wiki.ros.org/noetic/Migration).

rhaschke · 2021-10-25T08:48:50Z

I was thinking of updating/overring melodic-devel by merging noetic-devel. As long as franka_ros is the same on Melodic and Noetic, I don't expect any incompatibilities.

rickstaa · 2021-10-25T08:58:16Z

@rhaschke Sound like a good idea. Makes the melodic-devel branch easier to maintain.

rhaschke · 2021-11-08T08:43:29Z

Superseded by new noetic-devel branch.

davetcoleman reviewed Jun 11, 2020

View reviewed changes

tahsinkose commented Jun 13, 2020

View reviewed changes

tahsinkose marked this pull request as ready for review June 13, 2020 16:59

tahsinkose requested a review from davetcoleman June 16, 2020 09:51

tahsinkose mentioned this pull request Jun 16, 2020

Add MoveIt+Gazebo Integration tutorial for panda arm moveit/moveit_tutorials#499

Merged

simonbogh mentioned this pull request Feb 9, 2021

"Unable to identify any set of controllers that can actuate the specified joints: ..." Gazebo Simulation moveit/moveit#2237

Closed

tahsinkose mentioned this pull request Mar 15, 2021

Make Panda robot Gazebo compatible frankaemika/franka_ros#126

Closed

fwalch reviewed Mar 18, 2021

View reviewed changes

rickstaa approved these changes May 5, 2021

View reviewed changes

This comment has been minimized.

Sign in to view

This was referenced Aug 27, 2021

Noetic devel update rickstaa/panda_moveit_config#26

Closed

[feature_request] Adds ability to switch gazebo hardware interface frankaemika/franka_ros#161

Closed

rickstaa mentioned this pull request Aug 30, 2021

WIP: Generated using the latest features from MoveIt #74

Closed

3 tasks

rickstaa and others added 3 commits October 21, 2021 15:30

Add demo_gazebo.launch using franka_gazebo

7619355

This commit adds demo_gazebo.launch using the gazebo simulation of the franka_gazebo package Additionally, the virtual_joint is removed from the move group definition.

Fix parameters.

458e66f

Do not load robot description if it is not explicitly asked.

aebdd0a

This was referenced Oct 22, 2021

Noetic release #89

Closed

Cleanup #91

Merged

This was referenced Nov 2, 2021

Fix poses and update disabled collisons #93

Closed

IMPORTANT: Noetic-devel branch will be merged into the melodic devel branch #94

Closed

rhaschke closed this Nov 8, 2021

		@@ -0,0 +1,10 @@
		# The name of this file shouldn't be changed, or else the Setup Assistant won't detect it

		<arg name="moveit_controller_manager" value="panda" if="$(eval not arg('fake_execution') and not arg('load_gripper'))"/>
		<arg name="moveit_controller_manager" value="panda_gripper" if="$(eval not arg('fake_execution') and arg('load_gripper'))"/>

Integrate with Gazebo #68

Integrate with Gazebo #68

Conversation

tahsinkose commented Jun 11, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tahsinkose Jun 13, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tahsinkose commented Jan 23, 2021

tahsinkose commented Jan 23, 2021

simonbogh commented Jan 29, 2021

simonbogh commented Jan 30, 2021

tahsinkose commented Jan 31, 2021

tahsinkose commented Jan 31, 2021

simonbogh commented Jan 31, 2021

tahsinkose commented Mar 10, 2021

fwalch commented Mar 18, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tahsinkose commented May 5, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tahsinkose commented May 6, 2021

rickstaa commented Jul 16, 2021 • edited Loading

tahsinkose commented Jul 30, 2021

This comment has been minimized.

rickstaa commented Aug 26, 2021 • edited Loading

tahsinkose commented Aug 26, 2021

rickstaa commented Aug 26, 2021 • edited Loading

rickstaa commented Aug 30, 2021

rickstaa commented Sep 27, 2021

rickstaa commented Oct 20, 2021

rickstaa commented Oct 21, 2021 • edited Loading

rhaschke commented Oct 21, 2021

tahsinkose commented Oct 21, 2021

rickstaa commented Oct 21, 2021 • edited Loading

tahsinkose commented Oct 21, 2021

tahsinkose commented Oct 21, 2021 • edited Loading

rickstaa commented Oct 21, 2021

rhaschke commented Oct 21, 2021

tahsinkose commented Oct 21, 2021

rhaschke commented Oct 21, 2021

tahsinkose commented Oct 21, 2021

rhaschke commented Oct 21, 2021

tahsinkose commented Oct 21, 2021

v4hn commented Oct 22, 2021 via email

rickstaa commented Oct 24, 2021

rhaschke commented Oct 24, 2021

rickstaa commented Oct 25, 2021 • edited Loading

rhaschke commented Oct 25, 2021

rickstaa commented Oct 25, 2021

rhaschke commented Nov 8, 2021

tahsinkose commented Jun 11, 2020 •

edited

Loading

tahsinkose Jun 13, 2020 •

edited

Loading

fwalch commented Mar 18, 2021 •

edited

Loading

tahsinkose commented May 5, 2021 •

edited

Loading

rickstaa commented Jul 16, 2021 •

edited

Loading

rickstaa commented Aug 26, 2021 •

edited

Loading

rickstaa commented Aug 26, 2021 •

edited

Loading

rickstaa commented Oct 21, 2021 •

edited

Loading

rickstaa commented Oct 21, 2021 •

edited

Loading

tahsinkose commented Oct 21, 2021 •

edited

Loading

rickstaa commented Oct 25, 2021 •

edited

Loading