Closed mikepurvis closed 10 years ago
Usage docs updated on ROS wiki: http://wiki.ros.org/jackal_simulator
With the husky, I've made a front facing laser basically default (no options required). Don't wanna use it? Ignore it. It doesn't take up that much processing power.
I don't think we'll need to provide a custom URDF for every different mounting location of the LIDAR (back_laser, mast_laser etc.), unless the customer specially requests it. This is mostly because it will vary depending on what OTHER payloads we mount on the robot.
The thing is, the front mount is prime real estate— that's also the obvious place to mount a bumblebee or monocular camera. I think each accessory option should be a simulator flag to enable, so a more tricked out unit might be like:
roslaunch jackal_gazebo jackal_world.launch front_laser:=true back_mast:=true mast_bumblebee:=true bumblebee_angle:=-0.52
Once there's a macro capable of spawning the accessory with a prefix, the cost of adding more mount location options is low. cf. https://github.com/jackal/jackal/pull/9/files#diff-4bb4e73ce391b39373a7fdbc18dd2d52R5
Yea, I understand that. That would be awesome. My only issues is when you set back_mast:=true, the simulation may not match what you get in the box. Because depending on what other payloads you have, the location of the back_mast will vary, I don't want the customer to have the wrong expectation of where a back mast (or a bumblebee mount etc) would be mounted based on the boilerplate options in gazebo. What they get in the box may not match (atleast it doesn't with all the variants of the husky we make :S).
In general, it should be, though. The suite of standard integration packages for Jackal is larger than for Husky, so most users really will get what they see in simulation. Any system that's the result of custom integration will have a separate design/signoff phase (as presently happens with customized Husky units).
Okay yea, if its WYSIWYG between the simulation and the box, this looks good!
I like this idea a lot! We could integrate this with a technical sales team, so that when someone buys a Husky/Jackal, we trivially spin up a mockup, send the simulation their way to play with right away.
Simulator companion to https://github.com/jackal/jackal/pull/9
Usage is:
Concept is that there would be multiple (many?) similar options, eg back_laser, mast_laser, front_stereo_camera, front_camera, etc. We will implement and test these as the payload packages are assembled.
@Shokoofeh, @rgariepy to review.
@pmukherj, if you have a moment, I'd appreciate your thoughts too. Is this a reasonable and scalable approach? I'm assuming a really serious or highly customized user would use these building blocks to create their own description, or at least a wrapper launchfile that passes the relevant args in for them.