ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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
Self Collisions
Virtual Joints
Planning Groups Add Group Add Group Robot Poses
End Effectors Add Passive Joints
Configuration Files
|
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: results in the rgbdslam-23 process segving and thus the launch as a whole entering the fail state. 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: 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. |