nsprague's profile - activity

overview network karma followed questions activity

2019-07-31 04:41:51 -0600	received badge	● Favorite Question (source)
2015-08-11 14:35:00 -0600	received badge	● Enthusiast
2015-08-04 11:40:06 -0600	answered a question	roslaunch multiple turtlebots In my experience it is difficult (impossible?) to create launch files to run multiple Turtlebots within one ROS instance. I suggest that you check out rocon: http://wiki.ros.org/turtlebot_concert... I haven't used it, but it is intended to solve this problem.
2014-01-28 17:27:51 -0600	marked best answer	Information about Turtlebot2 I'll be teaching a robotics course this spring using ROS and Turtlebots as the platform. I currently have several of the original Turtlebots and intend to order several more in the near future. I noticed today that the Turtlebot2 is now available for purchase. I'm trying to determine which version I should buy, and I'm having trouble finding very much information about the new release. I'm hoping that someone in the know can help me answer a few questions, or point me in the right direction. -Is there currently support for the new Turtlebot in Fuerte? -To what degree will code for the new Turtlebot be backward compatible with the old Turtlebot. Will the existing Turtlebot node still work with the new base? Or will there be a new stack? -It looks like the new Turtlebot is designed to provide power to a laptop. What laptop(s) will be supported? I've been looking at the Acer Aspire One AO756-4854. -Is the low-level interface to the Kobuki base compatible with the interface to the Create? Is there a published specification for the Kobuki interface?
2014-01-26 23:54:40 -0600	received badge	● Famous Question (source)
2014-01-21 03:57:06 -0600	received badge	● Notable Question (source)
2014-01-16 01:19:39 -0600	received badge	● Popular Question (source)
2014-01-09 00:29:18 -0600	received badge	● Commentator (source)
2014-01-09 00:29:18 -0600	commented question	3dsensor.launch doesn't work on hydro The issue is discussed here: http://answers.ros.org/question/112391/nothing-published-to-scan-under-hydro/ . I've submitted an issue to the github repository here: https://github.com/turtlebot/turtlebot/issues/123
2014-01-08 07:11:02 -0600	asked a question	Turtlebot gmapping demo crashes with low-end CPUs Update: It turns out that the problem has something to do with the instruction set available on the CPU. The exact same setup (booting from the same iso) works fine on a Core i7-3820, but dies on a Celeron 847. I suspect that the issue is similar to the Fuerte bug described here: https://github.com/ros-perception/perception_pcl/issues/10 . If anyone can suggest a workaround (that doesn't involve recompiling PCL across an entire teaching lab worth of machines), I would appreciate it. Running the move_base node in gdb gives: `Program received signal SIGILL, Illegal instruction. 0x00007ffff35c9d3f in std::vector<double, std::allocator<double> >::_M_insert_aux(__gnu_cxx::__normal_iterator<double, std::vector<double, std::allocator<double> > >, double const&) () from /usr/lib/libpcl_common.so.1.7` And valgrind shows the following: vex amd64->IR: unhandled instruction bytes: 0xC5 0xFB 0x10 0x2 0xC5 0xFB 0x11 0x0 ==16678== valgrind: Unrecognised instruction at address 0x944fd3f. ==16678== at 0x944FD3F: std::vector<double, std::allocator<double> >::_M_insert_aux(__gnu_cxx::__normal_iterator<double, std::vector<double, std::allocator<double> > >, double const&) (in /usr/lib/libpcl_common.so.1.7.0) ==16678== by 0x1927C2AD: std::vector<double, std::allocator<double> >::push_back(double const&) (in /opt/ros/hydro/lib/libtrajectory_planner_ros.so) ==16678== by 0x1928B2B2: base_local_planner::TrajectoryPlannerROS::loadYVels(ros::NodeHandle) (in /opt/ros/hydro/lib/libtrajectory_planner_ros.so) ==16678== by 0x19289D89: base_local_planner::TrajectoryPlannerROS::initialize(std::string, tf::TransformListener, costmap_2d::Costmap2DROS) (in /opt/ros/hydro/lib/libtrajectory_planner_ros.so) ==16678== by 0x4F567DA: move_base::MoveBase::MoveBase(tf::TransformListener&) (in /opt/ros/hydro/lib/libmove_base.so) ==16678== by 0x40780B: main (in /opt/ros/hydro/lib/move_base/move_base) ==16678== Your program just tried to execute an instruction that Valgrind ==16678== did not recognise. There are two possible reasons for this. ==16678== 1. Your program has a bug and erroneously jumped to a non-code ==16678== location. If you are running Memcheck and you just saw a ==16678== warning about a bad jump, it's probably your program's fault. ==16678== 2. The instruction is legitimate but Valgrind doesn't handle it, ==16678== i.e. it's Valgrind's fault. If you think this is the case or ==16678== you are not sure, please let us know and we'll try to fix it. ==16678== Either way, Valgrind will now raise a SIGILL signal which will ==16678== probably kill your program. ==16678== ==16678== Process terminating with default action of signal 4 (SIGILL) ==16678== Illegal opcode at address 0x944FD3F ==16678== at 0x944FD3F: std::vector<double, std::allocator<double> >::_M_insert_aux(__gnu_cxx::__normal_iterator<double, std::vector<double, std::allocator<double> > >, double const&) (in /usr/lib/libpcl_common.so.1.7.0) ==16678== by 0x1927C2AD: std::vector<double, std::allocator<double> >::push_back(double const&) (in /opt/ros/hydro/lib/libtrajectory_planner_ros.so) ==16678== by 0x1928B2B2: base_local_planner::TrajectoryPlannerROS::loadYVels(ros::NodeHandle) (in /opt/ros/hydro/lib/libtrajectory_planner_ros.so) ==16678== by 0x19289D89: base_local_planner::TrajectoryPlannerROS::initialize(std::string, tf::TransformListener, costmap_2d::Costmap2DROS*) (in /opt/ros/hydro/lib/libtrajectory_planner_ros.so) ==16678== by 0x4F567DA: move_base::MoveBase::MoveBase(tf::TransformListener&) (in /opt/ros/hydro/lib/libmove_base.so) ==16678== by 0x40780B: main (in /opt/ros ... (more)
2014-01-06 05:50:00 -0600	answered a question	turtlebot calibration no IR scan using Hydro I would guess it's the same issue discussed here: http://answers.ros.org/question/112391/nothing-published-to-scan-under-hydro/ Nothing is published to /scan (which is required for calibration) unless `depth_registration` is set to false. You might try: `roslaunch turtlebot_calibration calibrate.launch depth_registration:=false` I can't test it directly because I'm using Kobuki-based turtlebots.
2014-01-03 02:49:27 -0600	commented answer	Nothing published to /scan under Hydro https://github.com/turtlebot/turtlebot/issues/123
2014-01-03 02:35:23 -0600	received badge	● Famous Question (source)
2014-01-02 09:22:45 -0600	commented answer	Nothing published to /scan under Hydro Good to know. I think this should be considered a bug in 3dsensor.launch. It will be confusing for users if different topics are "broken" based on a configuration setting. It's also inconsistent with the behavior in Groovy.
2013-12-30 03:29:10 -0600	commented answer	Nothing published to /scan under Hydro Thanks! That solves the problem. Is there any reason this defaults to true? According to the documentation for openni_launch: "If true, use OpenNI's factory-calibrated depth->RGB registration", but it defaults to false for openni_launch. What is the practical impact of leaving it off?
2013-12-22 18:51:02 -0600	received badge	● Notable Question (source)
2013-12-22 11:26:45 -0600	received badge	● Popular Question (source)
2013-12-20 12:30:12 -0600	commented answer	Nothing published to /scan under Hydro No, that's not what's happening. The /scan topic is definitely created by the launch file. I don't have the machine in front of me, so I can't show you the output of 'rostopic info /scan', but I have looked at it. The topic appears, but no data is ever published to it.
2013-12-20 08:20:45 -0600	commented answer	Nothing published to /scan under Hydro The /scan topic appears in the list of topics.
2013-12-20 07:00:30 -0600	asked a question	Nothing published to /scan under Hydro After updating to Hydro, executing: `roslaunch turtlebot_bringup 3dsensor.launch` no longer seems to work correctly. The expected topics appear, and it is possible to get some data off the Kinect: images and pointcloud data can be visualized in rviz. However, nothing is being published to the \scan topic. Everything seems to work fine if I grab a copy of the Groovy version of 3dsensor.launch and launch that. The issue is the same whether I use a Kinect or Asus Xtion. Has anyone else had luck with 3dsensor.launch under Hydro?
2013-11-19 04:11:35 -0600	commented answer	Phantomx Pincher MoveIt! Thanks Wolfe, I'll try it out when I get a chance.
2013-11-19 02:09:51 -0600	commented answer	Phantomx Pincher MoveIt! Any chance that you will be bringing the turtlebot_arm package up to date? I have several of these pincher arms that I would love to be able to use on a turtlebot with Hyrdo.
2013-03-20 05:37:51 -0600	commented question	Kobuki "malformed subpayload" I never found a workaround. I purchased new netbooks: Asus X201e's. These don't have the kobuki issue described above, but they have their own issues. Neither wired nor wireless Ethernet are well-supported under Ubuntu.
2013-02-20 23:31:38 -0600	received badge	● Taxonomist
2013-02-12 22:13:26 -0600	received badge	● Teacher (source)
2013-02-12 14:07:48 -0600	received badge	● Famous Question (source)
2013-02-11 02:53:03 -0600	commented question	Kobuki "malformed subpayload" This definitely wasn't an issue with the battery. It seems to be specific to the netbook model. It turns out that this Acer has all three external USB ports on the same USB bus. I've been told that there are issues with putting the Kinect and the Kobuki on the same bus.
2013-02-11 02:49:31 -0600	answered a question	Turtlebot Create Issues on Groovy There is currently no support for the original Turltlebot in Groovy. For now, Groovy only supports the new Kobuki-based Turtlebot. There are plans to add support for the original Turtlebot in the not-too-distant future, but for now your best bet is probably Fuerte. You can follow some of the discussion at the Turtlebot SIG: https://groups.google.com/forum/#!forum/ros-sig-turtlebot Groovy also doesn't yet have support for the Turtlebot simulator.
2013-01-23 05:41:25 -0600	received badge	● Notable Question (source)
2013-01-23 05:41:16 -0600	received badge	● Popular Question (source)
2013-01-15 10:41:13 -0600	received badge	● Nice Question (source)
2013-01-14 06:05:17 -0600	received badge	● Editor (source)
2013-01-14 06:05:17 -0600	edited question	Kobuki "malformed subpayload" I'm working with Turtlebot2 (with the Kobuki base) and running ROS Groovy. I'm intermittently seeing error messages like the ones below. Once these error messages start to appear, the robot becomes unresponsive. Relaunching the Turtlebot by running: roslaunch turtlebot_bringup minimal.launch doesn't help. Nor does power-cycling the robot. The only thing that seems to help is rebooting the notebook and re-launching. This works for a few minutes until the error messages reappear. I haven't been able to reliably reproduce the conditions that cause the error. I'm running version 1.1.3 of the Kobuki firmware. Any advice would be much appreciated. [ERROR] [1358185944.885286960]: Kobuki : malformed sub-payload detected. [116][255] [74 FF 77 00 D6 FF 7B FF 10 10 01 00 D9 0F DA 0F D3 0F DB 0F EF 0F 00 00 00 00 62 AA 55 4D 01 0F 60 D8 00 00 00 69 5D FA 5B 00 00 00 00 9E 00 03 03 00 00 00 04 07 A9 FB F9 FF 00 00 00 05 06 2B 06 50 07 99 06 06 02 00 00 0D 0E 13 06 7D 00 DD FF 83 FF 75 00 E0 FF 8E FF 10 10 01 00 D9 0F DD 0F D6 0F D7 0F F1 0F ] [ERROR] [1358185986.942876038]: Kobuki : Timed out while waiting for serial data stream [/mobile_base]. [ERROR] [1358185987.905898133]: Kobuki : malformed subpayload detected. [ERROR] [1358185997.916354409]: Kobuki : malformed sub-payload detected. [177][255] [B1 FF 6A 00 DF FF A6 FF 10 10 01 00 D7 0F DE 0F D4 0F D8 0F EE 0F 00 00 00 00 ] [ERROR] [1358186002.942891211]: Kobuki : Timed out while waiting for serial data stream [/mobile_base]. [ERROR] [1358186018.942877693]: Kobuki : Timed out while waiting for serial data stream [/mobile_base]. [ERROR] [1358186025.965638646]: Kobuki : malformed sub-payload detected. [15][219] [0F DB 0F D3 0F D8 0F EF 0F 00 00 00 00 B9 AA 55 4D 01 0F 68 15 00 00 00 69 5D FA 5B 00 00 00 00 9E 00 03 03 00 00 00 04 07 A9 FB F9 FF 00 00 00 05 06 2C 06 53 07 99 06 06 02 00 00 0D 0E DB 06 51 00 DC FF 8C FF 55 00 DD FF 92 FF 10 10 01 00 D7 0F DA 0F DC 0F D5 0F F1 0F 00 00 ] [ERROR] [1358186047.963542755]: Kobuki : malformed sub-payload detected. [152][255] [98 FF 10 10 01 00 DB 0F D7 0F D4 0F DE 0F F0 0F 00 00 00 00 ] EDIT: After the error messages above, the ftdi device associated with the Kobuki no longer shows up after an lsusb. Here is some additional output from dmesg in case it means anything to anyone: [ 1798.755034] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity [ 1799.766442] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate [ 1800.777800] usb 2-1: clear tt 1 (00c0) error -110 [ 1809.784380] ftdi_sio ttyUSB0: urb failed ... (more)