-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mesh and URDF for the Create1 #27
Conversation
@@ -0,0 +1,31 @@ | |||
Software License Agreement (BSD License) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't see this particular 3-clause license in the create_description package of the turtlebot_create repo. I think it will suffice to add a link in the README (as I have for the existing URDF and mesh files) instead of including this file. I will probably make the README a little more verbose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got this license from the header of the source files of the turtlebot driver, but it probably is better just to link in the Readme. I didn't notice that you had already done that for other files.
These changes seem to have broken running the description for me and I'm not sure why. I get a xacro error: Traceback (most recent call last):
File "/opt/ros/indigo/share/xacro/xacro.py", line 62, in <module>
xacro.main()
File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 696, in main
eval_self_contained(doc)
File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 626, in eval_self_contained
eval_all(doc.documentElement, macros, symbols)
File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 553, in eval_all
eval_all(body, macros, scoped)
File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 609, in eval_all
result = eval_text(at[1], symbols)
File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 483, in eval_text
results.append(handle_expr(lex.next()[1][2:-1]))
File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 470, in handle_expr
return eval_expr(lex, symbols)
File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 444, in eval_expr
result = eval_term(lex, symbols)
File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 418, in eval_term
result = eval_factor(lex, symbols)
File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 398, in eval_factor
return neg * eval_lit(lex, symbols)
File "/opt/ros/indigo/lib/python2.7/dist-packages/xacro/__init__.py", line 369, in eval_lit
raise XacroException("Property wasn't defined: %s" % str(ex))
xacro.XacroException: Property wasn't defined: u'prefix'
Invalid <param> tag: Cannot load command parameter [robot_description]: command [/opt/ros/indigo/share/xacro/xacro.py '/home/autolab/jacob/create_ws/src/create_autonomy/ca_description/urdf/create_2.urdf.xacro'] returned with code [1].
Param xml is <param command="$(find xacro)/xacro.py '$(find ca_description)/urdf/create_2.urdf.xacro'" name="robot_description"/> |
It works fine for me, but I'm running Jade so that might be the difference. My guess is that it is something to do with the macro that generates the wheels, because that is the only place I know of where "prefix" is used. Possibly the version of xacro in indigo doesn't like macros defined inside of other macros? |
This appears to be the error: http://answers.ros.org/question/204400/can-i-define-a-xacro-with-params-by-another-xacro/ |
Would you rather that I push more commits to this branch (and then squash them before merging) or just keep force pushing a single updated commit? |
</xacro:macro> | ||
|
||
<xacro:macro name="create_base" params="diffdrive_update_rate:=40 wheel_separation wheel_diameter:=0.072 wheel_width:=0.024 wheel_torque:=1.0 wheel_accel:=1.8 mass_kg:=3.5 base_diameter *mesh"> | ||
<xacro:property name="PI" value="3.1415926535897931" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to documentation I don't think you can place property tags inside macro tags. It complains in Indigo at least. You can just move the PI property outside I think, and just replace instances of wheel_radius
with wheel_diameter / 2
(or maybe better, just make the parameter wheel_radius
to begin with).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jade seems to be a lot more lenient for some reason.
How ever you prefer to commit. Both sound fine to me. |
LGTM 👍 You can squash and I'll merge. |
…ing a common base. Include a mesh for the Create 1, borrowed from turtlebot_create. Update launch files to support Create 1.
This PR adds a URDF file for the Create 1, along with a mesh. I refactored the URDF files so that common elements for all Creates/Roombas are in one file. The Create 1 and 2 URDF files include the base file and add elements that are specific to their model. At the moment, the only difference between the two is the wheel separation distance. I did not add the light bumpers for the Create 2 (which would have helped with #17), simply because I don't know where they are located, but if you want to add them they can easily be added to
create_2.urdf.xacro
.I also included a mesh for the Create 1, which I borrowed from turtlebot_create. I included the license from this project in the
meshes
folder because, as I understand it, this is required by the BSD license.I also updated the launch files to support the Create 1. I removed
joint_state_publisher
from the description launch files because there is really no use for it on the Create. From what I have read, it seems to be most commonly used for testing URDF models - by using the sliders on its GUI to manually simulate joint movements. The way it was configured in your launch files meant that it was doing nothing. On a real robot, usually the robot's driver will publish JointState messages to cause the model to match the real state of the robot. In the case ofca_driver
, #26 does this.