Status Report (4/27)

Group Update

  • Overall, we are working on reducing the error in the two major components (encoder and SLAM), so that move_base can successfully move the robot.
  • We will be spending the first half of the upcoming week on the final presentation and poster.
  • Our next goal is to test with tele-op, and then integrate move_base so that the robot is autonomous.

Amukta’s Update

  • I converted the visualization web app to a grid (from the scatterplot), and changed its endpoints to work with the map the ICP algorithm produced.
  • ICP now produces a higher resolution map and has empty hallway spaces. The focus for next week will be to reduce the “drift” or accumulated error in the scans.
  • For next week, I want to connect the physical robot to the visualization app, so that we can test with tele-op (rather than wired).

Kanupriyaa’s Update

Since ICP got completed last week, I focused on increasing the time response and the precision of the grid mapping this week. The software now updates very fast in real time and the map can be adjusted depending on how big the square area of the place is. For next week I will work on making the ICP better by adding empty corridors to the map.

Tiffany’s Update

Hardware

  • Made changes to CAD of robot to achieve a stabler robot base
  • Lasercut components out of final material instead of the cardboard used for prototyping, and assembled the final robot
  • Soldered and rewired robot so that it’s now fully wireless (except for when we need keyboard, mouse, and monitor to view Rviz)

Software

  • Fixed bug with ROS parameters not being set properly, which had caused the odometry to be incorrect.
  • Attempted to tune PID parameters again by plotting expected velocity and odometry-detected velocity, but discovered that motor speed PID control was not working as intended because encoder reading ROS node is missing some encoder ticks. This is because the encoder ticks are being counted serially with the encoder values being published to ROS, which causes a delay. This causes the odometry-detected velocity to be capped based on the publishing rate, so tuning the I or D values of the PID control would cause the motors to always gradually increase speed towards 100% duty cycle.
  • Attempted to fix above problem by implementing “multi-threading” in my original python script, but this didn’t help much since Python does not have true multi-threading.
  • Fixed above problem by rewriting encoder reading python script in cpp

Tiffany’s Summary:

SLAM and robot base can now be operated remotely using one ssh window from my laptop.

Leave a Reply

Your email address will not be published. Required fields are marked *