TimboInSpace's profile - activity

For any reading this: Yeah I got Openni working but NOT Openni2 Would highly recommend using a different depth camera, n

Not sure about MarkyMark2012, but I used mine with gmapping on a fairly coarse map. Worked decently in the end. Good luc

Hi MarkyMark,

I have had success with this setup. I made a small differential-drive bot that mapped using sonar, wheel odometry, and inertial sensors. Some of the key parts that made it work: - Stagger your sonar sensor's phase, especially if the sensors are looking in the same direction (or opposite by 180degrees). Use time division on the sampling. This greatly reduces noise. - BUFFER YOUR SONAR DATA. This is extremely important! My implementation used two sonar sensors that swept side to side. To get it to work, I had to buffer it for ~0.5s (thus creating a "laserscan" of about 25 data points) - it will not work very well if you publish single- or two-point "laserscans" - Use a coarse occupancy gridmap. I had good results with only 2.5cm pixels and large. (Also, since I was doing this on an arduino, it was a great way to drop the floating point numbers and use raw bytes instead) - Your localization will suffer from the extra delay due to buffering the sonar. If your robot doesn't need to respond quickly, it's better to use a coordinate transform snapshotted during the middle of the buffering operation, not at the end.

So YES this was a success for my project. Slow localization wasn't an issue for the environment I was using the robot in. If you have an extra couple hundred dollars, I'd opt for a cheap laserscanner. The objective of my project was to do SLAM on as small a budget as possible.

I battled with the kinect and never gave up! I have a "working" implementation as a .img image and some code in https://github.com/TimboInSpace/Armin/ . It eventually outputs an 8 bit depthimage as a 16-bit mm-encoded ROS depthimage. The intention was kinect --> raspi --> laptop

As far as I can tell, it's one of the few working ROS projects using kinect with Rasperry Pi 1 Model B+ My implementation uses the librekinect driver, but has big limitations: 6fps frame rate 640x40 resolution Connection often drops for 1s periods

Try it out. I just bought a raspberry pi 2, which can probably handle OpenNI, so I'll be trying that next as my current implementation is sub-par

I can confirm it works. my setup does serial A <> computer A<> wifi <> computer B <> Serial B, using ser2net and socat Your debian ser2net conf is correct

60001:raw:0:/dev/ttyS0:9600 8DATABITS NONE 1STOPBIT

On ubuntu, install socat and run this:

sudo socat pty,link=/dev/ttyV0,echo=0,raw tcp:[debian hostname]:60001

Then on your ubuntu computer you can access your debian computer's /dev/ttyS0 through the local virtual serial port /dev/ttyV0

Try enabling hardware flow control. That should raise and lower the RTS pin for you from minicom. Let me know your results, I'm working on the same problem and have so far had no luck connecting to the roomba...

I'll verify later today, but there should be a conf file in net2ser/examples called ser2net. Try matching your conf to that example.

It seems to me like gmapping would still work. Just remap ~map_frame to some local map frame that you have defined, and also set a static transform between the robot base and this local frame.. After that, you'll have to manage the global map <--> odometry frame transform by some other means, but it should accomplish what you need.

RGBDSlam is the best choice if you have both the rgb and depth stream, but Depthimage_to_laserscan is better if you only have the depth data (my project is like this). Depthimage_to_laserscan requires two things, the depth image topic and the camera_info topic (see monocular camera calibration tutorials). You'll also need to set up a coordinate frame to reference the kinect to. For example, with my stationary kinect 360, I use these:

rosrun tf static_transform_publisher 0 0 0 0 0 0 map camera_depth_frame 20

rosrun depthimage_to_laserscan depthimage_to_laserscan image:=/kinect/mono16/image_raw camera_info:=/kinect/mono16/camera_info _scan_height:=20 _scan_time:=0.167 _range_min:=0.75 _range_max:=2.5

You'd probably want to use a larger scan height if possible, but my slow little raspberry pi cannot handle much more than 640x40 at 6fps, so im limited in height.

After that, you'll see a new /scan topic. Use that in place of a laser scanner as described in the navigation stack tutorials: http://wiki.ros.org/navigation/Tutori...

Im having an issue using Depthimage_to_laserscan. After I subscribe to the topic (uses lazy subscription), it throws an error:

Could not convert depth image to laserscan: scan_height ( 1 pixels) is too large for the image height.

This seems strange to me. Checking the headers of both the image topic and camera_info using rostopic echo, I find they are identically 640x40 pixels (not a typo), the expected size.

Any ideas what could be causing this?

It should be noted that I am running this off a raspberry pi, so I'm using some librekinect and opencv to create the images, with a camera_info_manager to hand out the camera_info. Only the interface to depthimage_to_laserscan causes issues: other uses of the image work fine. This post outlines a possible solution, but does not apply here as Im not using openni.

Thanks

You don't need to fake it. One option is: on the non-android device set up a camera info manager publishing on a different camera name than your current one. Then set up an mage_transport republisher on the same name as your new camera info manager. Hope it goes well

You need to run CameraCalibrator.py, obtain a calibration .yaml file from that script, then provide your image publisher the URL to your calibration yaml file as a parameter to the image publisher.

This page gives details on the calibration process.

What are you using to publish these images? Does it have a camera_info_url parameter, or anything like that?

To add to Thomas D's comment, another way to do this would be using message_filters::TimeSynchronizer, set up to subscribe to each camera

Were you able to get any other conversions to work? I'm trying the same thing with RGB8 > Mono16, with no luck: encoding specified as mono16, but image has incompatible type 8UC3

Edit: My stream was only coming in as RGB8. This was the default in opencv, changing that fixed it.

This looks like the same issue: http://answers.ros.org/question/9550/... Are you using OpenNI?

Now I said it's possible, but the disclaimer is that it will never be as good as a laser. The main gmapping tweaks: - Set resolution to match sensors. For my SRF-04s, I used 4cm - Increase particle count, to account for relatively low sample rate. - Buffer the ultrasonic, publish as sets of points!!

It's totally possible. I have a little robot that does some basic SLAM, just using two ultrasonic rangefinders. However, I found that gmapping took some heavy tweaking to get to work properly using such noisy & low spatial resolution sensors. The whole project took a couple XBees, some servos, an arduino, the rangefinders, and my laptop.

I had a (mostly) working XBee network going with ROS Hydro. But when I upgraded to Indigo last night, I got this error immediately. I haven't found any solution yet Edit: I just removed all the ros-indigo-rosserial-* packages, and copied my old rosserial from Hydro to Indigo. Now working fine.

You're right. I changed the Mapper node to publish its own OccupancyGrid, and this was a lot simpler. It's working quite well now.

Does anyone know a way to update the map that map_server uses? AFAIK, the map is set to the contents of an image file as soon as the node is launched, then remains static for the life of the node. My situation is as follows: I have two nodes this job mapper and map_server. Mapper records ultrasonic range measurements into a png file, and has a service for saving updated versions of the map. How can I push updates of the map to my map_server node?? Will I have to relaunch the map_server node every time? Thanks

Would you be able to post your homebrew solution somewhere? I'm attempting a very similar project and am about to go down the ultrasonic > laserscan conversion route. Also did you eventually have any success with this approach?

I've had issues with this in the past, if launching the serial node right after rviz. It was causing rviz to crash immediately, but works fine when the two are launched separately. Not sure why

I was having the exact same problem then I found this thread. My issue seems to have been caused by OS updates running across errors while updating the ROS packages.