I am trying to create a service server that rotates the robot until it faces the wall that it closest to it using LaserScan and Twist(). My initial thought was:
msg = Twist()
self.laser_list = 0 to 719 rays of laser
if self.laser_front != min(self.laser_list):
msg.angular.z = 0.4
self.publisher.publish(msg)
while self.laser_front != min(self.laser_list):
pass
msg.angular.z = 0.0
self.publisher.publish(msg)
Note that i have already used multithread executor and reentrant callback groups, unfortunately, because laserscan is very slow, laser_front can not be updated fast enough to meet the == min(self.laser_list) criteria. i have also tried using odom to calculate the degree of rotation required but it seems too complicated. Is there any fix?
If I remember correctly, the /scan provides LaserScan messages at about 20Hzand the /odom provides Odometry messages at about 30Hz. So there will not be any “delays” or “lags” in those messages.
It is usually the program that has the fault.
Check the following in your code:
Is your QoS Profile for your Subscribers defined in the correct way?
How much is your Qos Profile message depth? 1, 10, 100 ? Too much or too less can produce lag.
How much is the num_threads in your MultiThreadedExecutor declaration? Is it more than 2? num_threads >= num_subscribers + 1 and num_threads <= 8 (or max cpu logical cores).
You would not need /odom for positioning the robot. Just use the laser scan range instead.
I have never faced a lag or delay in LaserScan or Odometry messages.
Just recheck your code. Everything should be fine.
1 and 2: They are directly copied from course notebook for the same topic (laserscan). QoSProfile(depth=10, reliability=ReliabilityPolicy.BEST_EFFORT)
I only have 1 subscriber and 3 reentrant callback groups (1 for server, 1 for publisher, 1 for laserscan). I have tried with both 2 and 3 threads but neither was effective.
As can be seen from the photo there is a lag between while loop and laser update (expected but laser callback definately not at the expected 20Hz). What should I do?
Try not to have any printouts in a sensor callback. So, get rid of that self.get_logger().info(...) inside laser_callback. This will cause major delays in sensor callbacks. Print function takes up lot of resources.
So while that print function is going on, your laser_callback is actually getting blocked (without you knowing it).
You can print the laser scan readings in the main callback, which is the custom_service_callback() in your case.
Regarding your service callback, get some tips from my following posts:
Just adding an option here, do you have the latest rosject version?
You can find out if the instructions for the ros1_bridge use the parameter_bridge.
If you are using the dynamic_bridge instead, this could influence the speed of the laserscan if there are too many topics trying to cross the bridge at once.
