Reducing waypoints to be downloaded
Hi,
I decided to use function compute_cartersian_path despite the results from comparing the duration of trajectories between this function and using the go function. Although, the go function generated shorter trajectory duration and removed the need of planning, both functions applied in the physical system produced similar results and was not capable of compensating with the the initial delay of the robot's motion.
From testing time events from the previous posts, I figured that the robot averaged 1242ms from the the time that the puck is moving towards the robot and the time the robot gets to the predicted position. However, as I was using the go function, the average length of the trajectory points is 12 which the robot has to move to before reaching the prediction position.
I figured that the current ROS drivers for the robot is to download all trajectory point-by-point before starting the robot's motion. Therefore, I explored ways to reduce the number of trajectory points being downloaded and force the robot to move to the final position as soon as possible.
compute_cartersian_path allowed to specify the resolution that the robot moves. Previously testing this function, I set the resolution to 1cm which would produce 13 trajectory points to move to a position 12cm away. The extra trajectory point considers the current robot position and is set to the start of the trajectory.
I set the resolution to 50cm which reduced the initial delay of the robot's motion as only two trajectory points needs to be downloaded. The robot gets to the final position a lot faster!
Below are two videos comparing the difference of resolutions of 1cm and 50cm.
Video showcasing the robot moving to several positions at a resolution of 1cm
Video showcasing the robot moving to several positions at a resolution of 50cm
I decided to use function compute_cartersian_path despite the results from comparing the duration of trajectories between this function and using the go function. Although, the go function generated shorter trajectory duration and removed the need of planning, both functions applied in the physical system produced similar results and was not capable of compensating with the the initial delay of the robot's motion.
From testing time events from the previous posts, I figured that the robot averaged 1242ms from the the time that the puck is moving towards the robot and the time the robot gets to the predicted position. However, as I was using the go function, the average length of the trajectory points is 12 which the robot has to move to before reaching the prediction position.
I figured that the current ROS drivers for the robot is to download all trajectory point-by-point before starting the robot's motion. Therefore, I explored ways to reduce the number of trajectory points being downloaded and force the robot to move to the final position as soon as possible.
compute_cartersian_path allowed to specify the resolution that the robot moves. Previously testing this function, I set the resolution to 1cm which would produce 13 trajectory points to move to a position 12cm away. The extra trajectory point considers the current robot position and is set to the start of the trajectory.
I set the resolution to 50cm which reduced the initial delay of the robot's motion as only two trajectory points needs to be downloaded. The robot gets to the final position a lot faster!
Below are two videos comparing the difference of resolutions of 1cm and 50cm.
Video showcasing the robot moving to several positions at a resolution of 1cm
Video showcasing the robot moving to several positions at a resolution of 50cm
I manually set positions for the robot to move to. The robot moves to several positions before moving to the final position. This increases the time for the robot to get to the specified position and makes the motion look jittery. Whereas, the second video only moves to one position which reduces travel time.
Immanuel
Comments
Post a Comment