TredBobek's profile - activity

Well here's a solution (although it's not perfect): I ditched the ros_control idea, and now the simple robot uses the libgazebo_ros_diff_drive.so plugin. I can spawn it near the UR5, and I can move it around, but the problem is that my robot is not a differential wheeled robot, so a linear.x=1 won't move it forward, but in circles. But luckily that was my goal (for now...)

I don't know if the floating joint idea works or not. Yes, it throws a warn about changing it to a fixed, but in reality it will move like it has a floating joint (except if you want to move it by hand with the gazebo interface, it will count as one model).

Hope it helps.

Hi!

Currently I have a dif_wheeled_robot and a kinect inside Gazebo (these are separate "robots", not connected by any joint). The diff_wheeled_robot has it's own scanner, has an AMCL launch made etc. I can navigate it around, and while moving if I put an obstacle in front of it, it will go around it. The kinect has a depthimage_to_laserscan node, so it's basically a laser scanner.

My goal is to make the diff_wheeled use the kinect's scan data to navigate instead of it's own hokuyo scanner, which is attached to it.

(basically I want to navigate the robot around, but with a scanner that's in a fixed position. In reality I can't put the kinect on my robot, but I still want my robot to avoid (dynamic) obstacles based on what the kinect sees).

AMCL wants scan data from the /scan topic, and that part is alright, the kinect sends data on that topic. The problem is, the AMCL wants a base_frame_id and an odom_frame_id, so it can connect the robot frame to the odom, and do it's computing and stuff, but my kinect isn't connected to either of these.

(in the tf tree, the diff_wheeled_robot and the kinect is separate. The diff_wheeled_robot's base_footprint connects to the odom, and that connects to the map. The kinect's root ends at it's own base_footprint_kinect)

If I disable the diff_wheeled's hokuyo, then the AMCL will throw this:

[ WARN] [1469782994.436635986, 36.386000000]: Timed out waiting for transform from base_footprint to map to become available before running costmap, tf error: . canTransform returned after 0.103 timeout was 0.1.

My question: Is it possible to use AMCL/Gmapping and navigation with a mobile robot and a detached/fixed kinect (not fixed to the mobile robot)?

If yes, how?

If no, then am I able to use the ros move_base navigation without AMCL? (so use navigation and collision avoidance with the same setup, on the fly. The obstacles are not static)

Than you.

Update #1: Okay, it seems like not the AMCL is the one throwing the warning, but the move_base. Still, no idea how to solve it. Maybe the better question is, can I use move_base with my setup?

Hi!

Currently there's an UR5 robot, which is working and doing it's stuff (with moveit).

My task is to have a robot that goes around in circles near the UR5 (so later the UR5 can do stuff with it). I already made a simple robot that can move around, go in circles, if I publish on a certain topic. It has it's own URDF, gazebo ros control, launch file etc. (let's call it simple robot)

And of course the UR5 has these too.

I tried launching both of these with a launch file, which of course didn't work. I saw all kind of tutorials about spawning the same robot multiple times, which isn't what I want. I want to spawn two different robots.

Spawning the complete UR5 and the simple robot model (without a controller, just the model) is easy, but when it comes to control the simple robot too (spawning a gazebo_ros_control, or somehow using the UR5's), that's where things get nasty. One of the problems (I think) is that both URDFs have a "<plugin name="ros_control" filename="libgazebo_ros_control.so">" part, and I think spawning 2 ros controllers won't really work. Deleting this plugin from the simple robot's URDF won't help, I can't control it (I can't remember, but I think even thought the .yaml is loaded, it can't find the controllers or something like that)

Maybe I have to make it global somehow...

The other problem is probably namespace. Making a correct namespace for the simple robot isn't hard, but for the UR5... I think that's a bit complex.

I tried making a merged URDF, so the simple robot is part of the UR5's system (so there won't be problem with namespaces and stuff), but the problem is that I need to connect the simple robot to the UR5.

Simple, there's a world link already for the UR5, I just connect the simple robot to the world with a floating joint... yeah, well it seems like floating is not supported, or I don't know, but when I start the program it says:

[ WARN] [1469109391.706616642]: Converting unknown joint type of joint 'world_simple_joint' into a fixed joint

Connecting the simple robot with a fixed joint to the word seems to be a bit of a problem.

I tried searching everywhere on the internet, but there's nothing on spawning different robots. Just the usual multirobot system, where there's one URDF, one robot, that's being spawned multiple times in different namespaces. I found a post about two different things (an arm and a hand) being put together, but that uses a fixed joint (and system where there's an arm, and a tool at the end of it is quite common).

Is there a way to do this?

Thank you.

I might be late, but the problem is, that the URDF you have for the gripper only has visuals and collision attributes. Gazebo requires inertial. And I think you need transmissions too for Gazebo (in the URDF).

That URDF (and the whole gripper you linked from github) wasn't made for Gazebo