Closed ipa-kut closed 11 months ago
Wheel drop sensors are not simulated. I suppose you can implement them easily by checking if motor wheel links are in contact with anything other than the robot base. U can do so in the plugin: https://github.com/corot/kobuki_desktop/tree/melodic/kobuki_gazebo_plugins and use bumpers as reference
Wheel drop sensors are not simulated. I suppose you can implement them easily by checking if motor wheel links are in contact with anything other than the robot base. U can do so in the plugin: https://github.com/corot/kobuki_desktop/tree/melodic/kobuki_gazebo_plugins and use bumpers as reference
Thank you for the suggestion! I am not sure yet if I want to do this, but I will update this post if I do.
I have added contact sensors to the wheel_left link based closely on the bumpers on base_link : here
I have also added ros plugins to publish these on topics for both the contact links : here
Furthermore, I added a name to the collision tag of the wheel_left link to closely match base_link : here
What I now observe is that the topic published by the ros plugin of the base contact sensor (/bumpers_contact) shows some good values. but the wheel_left contact sensor (/wheel_left_contact) does not.
Furthermore, these wheel_left contacts are also not picked up in the C++ code here. I expect the contact_size() to show counts for all contacts of both the base link and wheel left link, but only the base link contacts are counted. I may also not have understood this part correctly.
@corot , could you please suggest where I could fix this or what I could try instead?
I have added contact sensors to the wheel_left link based closely on the bumpers on base_link : here I have also added ros plugins to publish these on topics for both the contact links : here Furthermore, I added a name to the collision tag of the wheel_left link to closely match base_link : here
What I now observe is that the topic published by the ros plugin of the base contact sensor (/bumpers_contact) shows some good values. but the wheel_left contact sensor (/wheel_left_contact) does not.
Furthermore, these wheel_left contacts are also not picked up in the C++ code here. I expect the contact_size() to show counts for all contacts of both the base link and wheel left link, but only the base link contacts are counted. I may also not have understood this part correctly.
@corot , could you please suggest where I could fix this or what I could try instead?
I figured out that the collision name that I should give in the gazebo plugin should match the collision name generated in the sdf from the urdf (based on an this answer) I have since fixed this line and now it works as expected by publishing on to the ROS topic directly!
Cool, thanks! I'll give a try this week, but cannot tell when I'll have time. But why do you need the libgazebo_ros_bumper.so? You can get the sensor readings within the kobuki base plugin and publish there wheel drop events, as happens with the bumpers. See the code on kobuki node for reference: https://github.com/yujinrobot/kobuki/blob/melodic/kobuki_node/src/library/kobuki_ros.cpp#L318
Created two PRs to address this:
https://github.com/yujinrobot/kobuki/pull/425
https://github.com/yujinrobot/kobuki_desktop/pull/64
I also have a version in my fork where I add some additional features that I need for my experiments:
libgazebo_ros_p3d.so
If any of these features seem useful to the main repo, please let me know, and I can include them in the PRs as well.
Merged to melodic Requires pulling https://github.com/yujinrobot/kobuki too
I use the melodic branch of this repo, and start up the simulation with
roslaunch kobuki_gazebo kobuki_playground.launch
.I get the topics for the events for the bumper and cliff sensors under the namespace
/mobile_base/events
, but not the wheel drop sensors.Is there any easy way I can expose this data via a topic as well?
Else, if I need to write some source code to make this happen, could I please be pointed to the right files to edit? This would save me the many hours required to study the architecture of this stack and trace the origin point.