dpiet's profile - activity

Thanks. That's helpful and will try resolution. Increasing cost_scaling_factor and decreasing occdist_scale has helped as well.

I'm tuning our navigation stack for a smaller mobile platform in an office environment and we're having trouble adjusting the costmap so that the local planner can get through doors. Other than this issue we have a system that works well. Can anyone recommend parameters to investigate for tuning? We've looked at cost_scaling_factor, inflation_radius, and occdist_scale. I've uploaded a screenshot from rviz and circled three door openings. The global planner appears to plan the path ok, but the local planner gets to the door and will typically enter a recovery behavior and abort the goal.

I found gscam to be a pain with more than one camera. Best to go with one of the other webcam packages, and you can setup some udev rules to tie your devices to specific /dev addresses. I've used uvc_camera as well as usb_cam.

I recently wrote a python ROS node for Roboclaw that runs on Indigo. I'm cleaning it up for release but it didn't take too long to get a basic driver working with pyserial. My biggest issue has been read errors that sometimes need to trigger a reset of the port connection. You'll want to subscribe to a /cmd_vel topic with geometry_msgs/Twist message type to handle your linear and angular velocity commands, if that's suitable with your use case. I read encoder values and publish them on /odom for odometry.

Service calls would make sense if you want to change change PID parameters, voltage cutouts, etc.

I haven't done this myself but you could try to modify rosserial_arduino such that it communicates via the WiFi library instead of the UART. rosserial_arduino and rosserial_embeddedlinux are both customized versions of rosserial_client: http://wiki.ros.org/rosserial

You could continue debugging that package and make sure it's publishing to the ROS topic with dummy values. If that's working then you know it's a serial read issue.