First Attempt at AMCL, Teleop Improvements, Eric’s Thesis

4 minute read

Configuration Files Set

On Thursday, I set up Abby’s configuration files in ROS

Push casters is set to true. This reverses x-velocity commands going to the cRIO
I created a new configuration option rl_swap, which reverses spin commands, and added this to the code that sends commands to the cRIO. I did this because it seems my left and right motors are swapped. I am not sure if this will confuse the EKF doing odometry. If so, I can manually swap the motor and encoder wires.
Added a definition of ROBOT, ROS_IP, and ROS_MASTER_URI to abby's .bashrc

Within the cRIO, the coordinate frame is compass-style (X forward, Y right, Z down, with positive rotation defined as clockwise looking down at the robot.)
Within ROS, the coordinate frame is engineering-style (X forward, Y left, Z up, with positive rotation defined as counter-clockwise looking down at the robot.)
The transformation between coordinate frames is performed in the ROS gateway node that communicates with the cRIO.

On Thursday night, I made my first attempt at localization with AMCL, driving the robot in teleoperated mode.

Robot doesn't seem to be localizing (pose is not updating), although the odometry is updating and appears to be correct.
Repeated warning-level errors about update rates in the map node that I didn't commit to memory.
Maps are very slow to appear in RVIZ (Eric says this is network latency, and not a robot issue)
Teleoperation works
- Set up Abby's configuration files, including TF for the LIDAR.
- Set push_casters in the configuration files for Abby

Perform the same tests using wired ethernet and/or VNC connection to the robot to separate network latency issues from the robot's performance.
Determine if rl_swap is confusing the odometry (although I'm fairly certain it isn't)

The flaky estop seems to be getting flakier (note that it fails safely)
Some scoping seems to indicate that the power to the xBEE modem in the receiver is momentarily cutting out. This might be fixable by a bypass capacitor close to the modem. It may also indicate that the LM317 voltage regulator is damaged or operating outside of spec
In the process of diagnosing the problem, I accidentally shorted the 12V rail to the 3.3V rail. This killed the xBEE modem (won't respond to X-CTU software). I borrowed the xBEE modem from Otto's e-stop remote and reconfigured it and the remote modem. Note that this did not fix cut-out issues, which rules out the receiver modem as the source of the problem.
Next steps
- test modem communication with a bench power supply and no other electronics connected
- Test with LM317 for power and no other electronics connected
- Build up to full receiver on a breadboard.
- If nothing more obvious is discovered, install bypass cap.
- If that doesn't fix the problem, replace LM317 with another (it's worth noting that there doesn't appear to be a power supply cutout at the pin of LM317, so it's more likely that a bypass cap will solve the problem.)
- In the next revision of the board, I may want to have a completely separate power rail for the xBEE than for all other electronics on the board.

Notes from

costmap_2d - A fixed-grid costmap
base_local_planner
- Performs local planning
- Uses "trajectory rollout" to foward-simulate robot motion and score against the costmap
- Doesn't handle tight spaces well
navfn
- Performs global path planning
- Uses Dijkstra's algorithm with a circular robot assumption (problematic for rectangular/oblong robots)

Provides interface to check robot bounding box against an octree cost map for collisions
Does forward simulation of robot position
Each voxel is the costmap stores probability of occupancy
Can store/check 1 cm resolution maps at > 20 Hz
Note: no longer compiles in ROS Fuerte because dependencies got moved around. Check out octomap_msgs, since that's where they seem to have moved to.

Eric mentioned that Willow Garage is developing a framework called MoveIt!, which seems to be doing more or less the same thing I'm doing (mobile manipulation planning). It's not complete and is targeted for release in ROS Groovy.
Chad's project for machine learning was an investigation into different types of EKFs for odometry, and might have some useful background information on the topic.
Farnsworth -- the hardware is Eric's, but he doesn't want it. He'll transfer access/ownership to whoever wants it. It's currently running Gentoo (apparently Eric is some kind of masochist.)
Gazebo is not and should not be so hard. Most of our problems are probably because of model complexity, and/or Miles's inexperience with the tool.
Check out talks from this year's ROSCon. They should be edifying.
It shouldn't be difficult to do all of the Kinect data processing on one machine (with everything else). Just throttle back the data coming in from the Kinect, and take advantage of nodelets, which are like nodes but will all share a process, allowing them to pass data to each other as shared pointers rather than through sockets, which cuts out ser/des overhead.