ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

monkeyiq's profile - activity

2017-10-11 11:51:20 -0500 received badge  Famous Question (source)
2017-10-11 11:51:20 -0500 received badge  Notable Question (source)
2017-07-12 23:17:25 -0500 received badge  Famous Question (source)
2017-04-24 20:21:46 -0500 received badge  Notable Question (source)
2017-04-24 20:21:46 -0500 received badge  Popular Question (source)
2017-02-21 01:13:03 -0500 asked a question MoveIt setup assist restricted motion on a cheap 6 dof robot arm

TLDR: Having trouble with generated moveit configuration allowing movement in two of the three axis for the end effector position. Almost certainly an error in my actions / urdf.

In the last 6 months cheap alloy robot arms have appeared on ebay, total cost of less than $100. I can link to the specific one but have not right off the bat to not be an advert.

I have created an xacro file describing the arm. I know I have not modeled the gripper correctly, it is a reasonably common design using a single servo controlling two pincers that close. Modeling that part is hopefully an issue for later playing.

When I use the MoveIt setup assistant I get an output that is working in some cases. If I set the goal state to random valid the plan and execute moves the arm as one would hope. I can only grab and move one of the three sets of arrows to manually adjust the end effector position in rviz. The one available allows movement along the wrist axis. I can not move the end effector directly left/right or up/down with those axis arrows. The arrows move but make no change to the position of the arm state. Rotation is similar with only one rotator working.

Any thoughts from folks who have hit similar issues would be wonderful.

Setup Assistant Session:

roslaunch moveit_setup_assistant setup_assistant.launch

Start

  1. Choose create new MoveIt Configuration Package
  2. Load /.../src/six_dof_arm_czb/urdf/arm.xacro
  3. Arm image can be seen on the right

Self Collisions

  1. Generate Collision Matrix

Virtual Joints

  1. Not used at start. It is assumed the arm is fixed in location.

Planning Groups

Add Group

 1. name: arm
 2. kinematic solver: KDLKinematicsPlugin
 3. Add Joints: bottom_joint, shoulder_pan_joint, elbow_joint, wrist_pitch_joint, wrise_roll_joint

Add Group

 1. name: pincer
 2. Kinematic solver: None
 3. Joints: pincer_joint

Robot Poses

  1. Add Pose. name: home

End Effectors

Add

 1. name: pincer
 2. end effector group: pincer
 3. parent link: wrist_roll_link

Passive Joints

  1. Nothing

Configuration Files

  1. Save path: /.../src/six_dof_arm_czb_moveit
  2. Generate Package
2016-08-08 20:29:24 -0500 received badge  Popular Question (source)
2016-05-26 07:16:44 -0500 commented question Navigation goal overshoot (dd,amcl,move_base)

The odom and tf stuff is all getting through ok, as seen both on the console and in rviz.

2016-05-26 07:15:50 -0500 commented question Navigation goal overshoot (dd,amcl,move_base)

Looking at the plans that are made, they seem fairly valid. I've disabled the actual motion in my robot base so I can just drop in goals and see the plans as they change and that all seems ok. I had thought that maybe the planner expects the wheels to be oriented rotated 1.57 from where they are.

2016-05-26 07:13:40 -0500 commented question Navigation goal overshoot (dd,amcl,move_base)

Starting with the simpler, the 2D pose estimate setting doesn't seem to help. I have the initial pose setup (initial_pose_x et al) in the amcl launch file. So the pose is about right relative to where the robot is at startup. Doing a post estimate as well doesn't help with the overrun.

2016-05-20 04:48:25 -0500 received badge  Student (source)
2016-05-19 19:17:31 -0500 asked a question Navigation goal overshoot (dd,amcl,move_base)

I'm bringing up a custom robot using ROS and the navigation stack. It's differential drive with a kinect for object avoidance and mapping. I have done the preliminary things making sure that the kinect data and odometer are sane, eg, moving towards a wall and seeing lagged laser data is written over itself and rotations in place rescan at the same place after a closed loop.

I have a static map made with gmapping and served with the map_server. amcl gives a reasonable posearray and tightens that up nicely when the robot moves around a bit. With map_server, amcl, and move_base all running I can teleop around the map just fine and the laser scan data does what it should, the local_costmap/costmap seems ok and is over the static map where it should be. In general things are refined to a point where everything makes sense as I move around.

Unfortunately, when I set a goal /move_base_simple/goal the robot overshoots the goal and keeps on going.It's a baby step goal, 1 meter forwards from the current pose (and tight poseArray from amcl). I stop things by lifting the robot off ground before impact with a wall. This second part is a worry as the local_costmap and laser data would surely indicate to move_base to halt anyway (don't hit the walls). Oddly, even after that, when I stop the robot running and check rviz I see the NavfnROS/plan still looks valid. It thinks the robot magically made it through the wall and wants to loop around the exterior of the building to the main entrance and then move to the goal.

Any thoughts on what I should be sniffing around to try to figure out what is causing the robot not to see it has approached and indeed run over the goal would be wonderful. I might try a U-turn goal to see if it just plows forwards or turns around and heads toward the goal before overshooting it.

2015-12-16 22:35:10 -0500 marked best answer rgbdslam main process segv from roslaunch openni+rgbdslam.launch

Hi, I have a kinect attached to an Intel J1900 based machine and the OpenNI examples run fine including the hand tracking example. Using OpenNI and SensorKinect. ( https://github.com/OpenNI/OpenNI.git and https://github.com/avin2/SensorKinect... both on unstable branch). This is an Ubuntu 14.04.1 installation with ROS indigo.

I have rgbdslam installed via catkin as the web page suggests. After some compile and linking glitches I got a binary. However, trying to run:

$ roslaunch rgbdslam openni+rgbdslam.launch

results in the rgbdslam-23 process segving and thus the launch as a whole entering the fail state.

process[rgbdslam-23]: started with pid [8189]
================================================================================REQUIRED process [rgbdslam-23] has died!
process has died [pid 8189, exit code -11, cmd /home/monkeyiq/catkin_ws/devel/lib/rgbdslam/rgbdslam __name:=rgbdslam __log:=/home/monkeyiq/.ros/log/7f7c8758-3a90-11e4-8b1b-d050992ba7ab/rgbdslam-23.log].                                                                                                                    
log file: /home/monkeyiq/.ros/log/7f7c8758-3a90-11e4-8b1b-d050992ba7ab/rgbdslam-23*.log

Initiating shutdown!

Unfortunately the Logs do not seem to shine light on any specific cause.

I'm not sure if its a good idea to try to gdb the rgbdslam executable directly, but this is what I get when that segvs:

~/catkin_ws/src/rgbdslam_v2/launch$ gdb /home/monkeyiq/catkin_ws/devel/lib/rgbdslam/rgbdslam
...
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7582a8c in boost::math::lanczos::lanczos_initializer<boost::math::lanczos::lanczos17m64, long double>::init::init() ()
   from /usr/lib/libpcl_io.so.1.7
(gdb) bt
#0  0x00007ffff7582a8c in boost::math::lanczos::lanczos_initializer<boost::math::lanczos::lanczos17m64, long double>::init::init() ()
   from /usr/lib/libpcl_io.so.1.7
#1  0x00007ffff750d186 in ?? () from /usr/lib/libpcl_io.so.1.7
#2  0x00007ffff7dea13a in call_init (l=<optimised out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe138, env=env@entry=0x7fffffffe148) at dl-init.c:78
#3  0x00007ffff7dea223 in call_init (env=<optimised out>, argv=<optimised out>, argc=<optimised out>, l=<optimised out>) at dl-init.c:36
#4  _dl_init (main_map=0x7ffff7ffe1c8, argc=1, argv=0x7fffffffe138, env=0x7fffffffe148) at dl-init.c:126
#5  0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000000000001 in ?? ()
#7  0x00007fffffffe3d5 in ?? ()
#8  0x0000000000000000 in ?? ()
(gdb) q

Any thoughts or recommendations are greatly appreciated.

2015-01-02 20:14:11 -0500 received badge  Enthusiast
2014-11-20 03:07:24 -0500 received badge  Nice Answer (source)
2014-11-14 20:58:20 -0500 received badge  Famous Question (source)
2014-10-06 01:08:13 -0500 received badge  Notable Question (source)
2014-09-24 03:49:50 -0500 received badge  Popular Question (source)
2014-09-18 08:39:49 -0500 received badge  Teacher (source)
2014-09-18 08:39:49 -0500 received badge  Self-Learner (source)
2014-09-18 07:41:26 -0500 commented answer rgbdslam hydro no display

I fixed that by updating the openni launch file and adding a prefix. Then I got images in the rgbdslam GUI!

2014-09-18 07:06:24 -0500 commented answer rgbdslam hydro no display

This is on 14.04.1 LTS using ROS Indigo.

2014-09-18 07:05:30 -0500 commented answer rgbdslam hydro no display

Full single message block:

Invalid argument "/camera_rgb_optical_frame" passed to lookupTransform argument target_frame in tf2 frame_ids cannot start with a '/' like:

2014-09-18 07:05:01 -0500 commented answer rgbdslam hydro no display

I still only get an empy window as shown in the picture at the top of this thread... pressing enter to start doesn't change things.

In the terminal that runs $roslaunch openni_launch openni.launch

I see a lot of messages TF2 exception Invalid argument "/camera_rgb_optical_frame" passed ...

2014-09-18 06:48:31 -0500 answered a question rgbdslam main process segv from roslaunch openni+rgbdslam.launch

removing the -std=c++0x from the catkin_ws/src/rgbdslam_v2/CMakeLists.txt got the GUI to appear. Hope this helps somebody else sometime.

2014-09-14 07:57:31 -0500 commented question rgbdslam main process segv from roslaunch openni+rgbdslam.launch

This appears to be a clash with boost and your selected c++ standard during various compiles. Removing the -std=c++0x from catkin_ws/src/rgbdslam_v2/CMakeLists.txt no longer crashes in the same way. Shortly I will verify that the DSLAM as a whole is doing something productive now.