Check description.md as well.
Spawning of the robot happens as simply as launching the two launch files provided. spawn_model within gazebo_ros pacakge, the node responsible to launch the robot has been included within the tortoisebotpromax_playground itself. With the robot spawned the lidar data published on the topic scan by gazebo can be visualized using rviz.
Visualization of /scan topic
To generate the map, gmapping package was utilized which only has two requirements, /scan topic and transform between /odom and base_link frame.
Apart from gmapping, slam toolbox and cartographer package were also taken into consideration for mapping, but gmapping was chosen for its simplicity.
Generated map by gmapping package
Document of detection of aruco markers
With Aruco markers detected and the pose of the robot stored in the form of waypoints the robot is now capable of autonomously capable of navigating in the environment.
Global Planner
Local planner
Still there are two human intervention points, i) Generation of waypoints and providing it to the Robot and ii) Generation of map, the current navigation stack uses preloaded map to traverse the env.
For controller next_goal_pose is published on topic move_base_simple/goal and subscribes to odom topic to check if the robot has reached the position or not.
This can be replace with Actiionib APIs
- Spawn at the origin of the environment
- Teleoperate the robot and map the environment.
- localization for SLAM.
- Statc Path plan using move_base
- Collision avoidance and control of the robot using move_base from Navigation stack.
- Scan the ArUco markers and store the robot’s closest possible pose with respect to the marker when scanning the ArUco marker.
- Autonomously navigate to each ArUco marker
- Controller node so robot reaches all the generated waypoints
- Convert quats to yaw
- Increase bot speed
- Change controller architecture from PubSub to actionlib
As the robot is teleoperated, a individual script will be running which detects the ArUco markers using openCV. After detection Ids will be assigned to each marker. The robot will keep on moving until the size of the maker sensed by the camera does reaches the mentioned threshold and the shape of the maker does not aligns to be square, inferring that the robot has aligned with the makers. At this position the pose of the robot will be stored in the form of waypoints.
One thing that actually concerns me is that does not this defies the concept of autonomous navigation. Since the waypoints are detected by the robot operated in teleoperation mode and the robot is made to traversal those waypoint, there is a human intervention involved.
What I feel should actually happen is that, there should a navigation stack such as the ROS Navigation Stack which should be responsible to map the environment, localize the robot and navigate the environment while avoiding any obstacle within the path. The robot will receive goal positions to reached indicated using AcUro markers. Initially with no makers the robot will traverse the environment trying to visit the unvisited area of the environment until any AuRco makers is detected.
First error encountered was the,
[ERROR] [1696795821.366083727]: material 'silver' is not unique.After launching tortoisebotpromax_playground.launch before the issue was resolved an attempt was made to solved the issue by changing the material.xacro file within the tortoisebotpromax_description package.
From,
<material name="silver">
<color rgba="0.700 0.700 0.700 1.000"/>
</material>To,
<material name="grey">
<color rgba="0.700 0.700 0.700 1.000"/>
</material>After resolving this robot was spawned successfully within the gazebo and the robot_description was able to visualize in rviz.
Secondly, while generating the map of the environment, it was noticed that out of two things required for the gmapping to generate the map, which are scan topic where the lidar data is published and transform between odom and base_link frame which is used to identify the position of the robot from initial point. The transform was missing.
Missing /odom frame in the tf_tree
Before the error was resolved, a idea was presented to create a node which will subscribe to the topic /odom (which did exist) and then publish the transform so that the requirements of gmapping can be satisfied.
It was also found that if any frame is found missing by the gmapping package it initiates to publish to the frame itself.
No link between odom and base_link frame as gmapping publishes the frame which it should.
Before a node can created the issue was resolved.
While perofrming navigation, the local map was not able to detect and avoid obstacles, this was because the lidar frame was wrongly provide to it.
Clone the repository into your src directory of ros workspace
cd ~/catkin_ws/src
git clone git@github.com:maker-ATOM/robonautica_mapping.gitBuild the workspace
cd ~/catkin_ws
catkin_make
Launch gazebo using,
roslaunch tortoisebotpromax_gazebo tortoisebotpromax_playground.launchLaunch rviz to visualize the map,
roslaunch tortoisebotpromax_description display.launchExecute Aruco marker detection and waypoint storage script in this gmapping launch file.
pip3 install opencv-contrib-python==4.4.0.46
Launch gmapping to generate the map of the environment,
roslaunch robonautica_mapping gmapping.launchTeloperate the robot using,
rosrun teleop_twist_keyboard teleop_twist_keyboard.pyAs the robot is being controller using teleop node, generated map can be visualized in rviz.
To save the generated map,
rosrun map_server map_saver -f mapcopy this folder to robonautica_slam package
Launch gazebo using,
roslaunch tortoisebotpromax_gazebo tortoisebotpromax_playground.launchLauch AMCL node for to visualise localization,
roslaunch robonautica_slam amcl.launchTeleop the robot to see the robot in action.
rosrun teleop_twist_keyboard teleop_twist_keyboard.pyroslaunch tortoisebotpromax_gazebo tortoisebotpromax_playground.launchLauch AMCL node for to visualise localization,
roslaunch robonautica_slam amcl.launchMake sure the robot place in the physical env and robot in simulation are at the same position. If not use inital_pose using Rviz
Lanch move_base node to perform navigation.
roslaunch robonautica_slam move_base.launchUpdate: amcl.launch and move_base.launch have been added intonavigation.launch so both launch files can be launnched using a single launch file file.
roslaunch tortoisebotpromax_gazebo tortoisebotpromax_playground.launchroslaunch robonautica_slam navigation.launchrosrun robonautica_waypoints controller.pyYellow Lane detection and Obstacle avoidance python programs
Gazebo
roslaunch tortoisebotpromax_gazebo tortoisebotpromax_traffic_iisc.launchThis file launches the simluation environment for this task
Launch
roslaunch robonautica_lane controller.pyThis launch file launches two nodes, one launches main algorithm for lane detection and obstacle avoidance and another which publishes data on obstacle be taking into consideration of lidar data from /scan topic.
Rviz
rviz -d ~/catkin_ws/src/Robonautica-AMR/robonautica_lane/rviz/lane.rviz Note: All the above ros command should be executed in different terminal.
Lane detection primarily ensured bot tracking by analyzing a single lane's slope, simplifying the process. The camera image was cropped to the lower left side, converted to HSL color space for better color representation, and then transformed into grayscale to emphasize the lane. To mitigate image noise, we applied Gaussian blur and subsequently utilized Canny edge detection. The Hough transform isolated lane features, providing x and y coordinates for the left lane edges. To represent the left lane as a single line, we averaged the lines and extrapolated the lane trajectory, using the lane slope as a marker to keep the bot on course
The contour mapping for wall following was implemented in this task when an obstacle was observed .We took the /scan topic from lidar and segmented the lidar scan data into front, left and right by slicing the range list.
Once the obstacle node notifies us about the presence of an obstacle in front of it we perform contour mapping which actually follows the surface of the wall until it finds the newest left lane. Inspired by bug 1 algorithm.