(@RobertLucian , )
I’m attempting to walk through the IntelligentObjectAvoider robot project code, and have two questions:
- Why is the angle recorded with each distance sample offset toward the vehicle heading?
When collecting samples, the obstacle_finder() function stuffs range samples longer than the distance_trigger (=25 guessing cm) into a sonar_samples list, with an “adjusted” angle value for each sample rotated 90 degrees to be relative to the vehicle heading.
The value saved is not the actual angle (relative to vehicle heading) from which the sample was obtained, but is “adjusted” to be offset by “step degrees” (=10) toward the vehicle heading.
servo.rotate_servo(current_servo_position)
sleep(servo_delay)
distance = distance_sensor.read()
current_servo_position += step
if distance > distance_trigger:
sonar_samples.append([distance, 90 - current_servo_position])
- How is angle_to_turn (150) chosen?
When no path is found within the searched sector (120 + 2 * one-half-FOVsensor degrees) centered on the vehicle heading, the vehicle is commanded to turn 150 degrees.
The new DI Distance Sensor based on the VL53L0X Infrared Time Of Flight chip has a stated field of view of 25 degrees, half of which would be 12.5 degrees, meaning the searched area was at best, about 145 degrees.
The name sonar_samples implies this code may have begun life with the ultrasonic distance sensor which has a much wider FOV (something like 60 degrees up close narrowing to 45 degrees around 150 cm). I’m guessing this wider FOV might have covered half the un-searched 60 degree sector in each directed sector scan.
For the new DI Distance Sensor, turning 150 degrees would seem to leave a small sector un-searched, perhaps 10 degrees?
Should the angle_to_turn be different when using the new DI Distance Sensor, like 135, 140, or 145 degrees? (Perhaps this is a “Who cares?” kind of difference. Mainly, I just want to understand what my bot it “thinking” when it is being an “Intelligent” Object Avoider.)