Computer Setup

Since the previously configured virtual environment is based on python3.9, we need to uninstall the current virtual environment first, and then reconfigure the virtual environment after updating python to version 3.10 in the physical machine. (Unable to upgrade python directly to 3.10 in a python3.9-based virtual environment)

Since I am using a macbook with arm64 architecture using M1 pro chip, there is a situation where pyqt5 cannot be installed during the configuration process.
So I changed to install pyqt6 and modified the corresponding dependencies in the _init_.py file.

Simulation

The simulator simulates a car equipped with an IMU sensor and a TOF sensor in a set map, which can move forward and backward and rotate around its axis.
In addition, the simulator provides a Plotter to draw points and lines in an external window, and a Controller to control the car using commands below:

So we can either manually control the car through the keyboard, or write a program to make the car run automatically while also plotting its trajectory at the same time.

I designed a simple loop, in the loop, the car executes two commands in turn:
1. Move forward for 1s at a linear velocity of 1 m/s
2. Rotate left for 1s at an angular velocity of π/2 rad/s (Totally 90°)
In the meantime, plot the ground truth and odometry of the car.

From the trajectory of ground truth (green line), we can see that the car is relatively accurately performing a square circular motion. Compared with the actual operation, it can be seen that the trajectory of ground truth is consistent with the actual motion of the car.
However, due to the excessive noise and inaccuracy, the trajectory of odometry calculated by the IMU data is very inconsistent with the actual situation.

In the above loop, the duration of a velocity command is 1s. In fact, the duration of the command is related to the linear velocity of the car. Due to the limited size of the map, the faster the speed, the shorter the runtime.

The car is not moving exactly on the exact same path, which means that it doesn't always execute the exact same shape.
This is because the commands executed by the car are discrete, which means tiny errors in operation will cause slight deviations due to reasons like rounding.

In this loop:
1. The car moves forward at a linear speed of 1 m/s when the distance from the obstacle is greater than 0.3m
2. When the car is less than 0.3m away from the obstacle, it rotates (left or right) at an angular velocity of π rad/s while continuously getting the ToF readings installed on the front of the car
3. During the rotation, when the reading of ToF is greater than 0.5m (meaning there is enough distance in front of the car to move), the car continues to go straight at a speed of 1 m/s

When encountering an obstacle, the rotation angle or time of the car depends on the ToF readings. Only when the ToF reading is large enough (meaning there is enough space in front of the car), the car can continue to move forward.

In order to prevent the car colliding with obstacles, the linear speed of the car is limited by the stopping distance. Faster speeds require larger stopping distances (meaning earlier stops)

In theory, if the car can be regarded as a particle, it can approach the obstacle infinitely. However, considering the physical model of the car, it needs a certain amount of space in the process of turning, which limits how close it can get to obstacles. After actual testing, I think 0.3m is a relatively suitable distance.

In the loop control I showed above, the car never got stuck between obstacles, which means my obstacle avoidance code always work.