The objectives of the MDP Algorithms:
- Autonomously explore the unknown area for obstacles without colliding with any of them.
- Find the fastest path from the start position to the goal position and avoiding the obstacles.
The Algorithm GUI simulator was created before implementing the algorithm. So that, it provides a better visualisation of the Robot and Map instances. The Simulator was built using JavaFX, which provide libraries for basic GUI; such as text field, button and layout container.
Simulator Class Design
Observer Pattern
The design of the simulator used observer pattern to ensure that there is less coupling between the MapGUI and multiple different classes that make changes to the Map and Robot entity. Other designs such as singleton and factory pattern are also utilised to ensure that there is only one instance of robot, map, and algorithm that is running at any given time.
Strategy Pattern: Flexibility & Maintainability
 |
 |
Strategy pattern is adopted in the design of the simulator. It allows easy changing between different implementations of exploration algorithm, fastest path algorithm for the different placement of the sensor on the robot. With this, the robot can be easily enhanced in the future for performance tuning. The class diagram above shows the strategy pattern used in the simulator.
The ExplorationFactory class creates the different instances of the algorithm based on the selected algorithm from the drop-down list during runtime.
GUI design
Interface to RPi (Socket)
Communication between RPi and Android uses socket programming through Port & IP address. RPI act as a server, continuously listening for an incoming connection. The Simulator has the option to connect to the RPI. When the connection initiated, a new thread will run and take care of any incoming and outgoing message.
Sensor Information Calculation (Phantom block avoidance/Accurate Map update)
| Hardware is not always accurate and the short-range sensors are only reliable when it is near. Any distance further than 30cm will be inaccurate. Thus, reading of obstacle location may be unreliable when computing on the algorithm side. To avoid the issue of an inaccurate block, the confident level is implemented for the different range of obstacles detected.
We use a counter in each grid; each grid starts from zero. Whenever an obstacle is detected in that grid, the counter of the grid increment. If there are no obstacles, the count is decreased. If a block is detected 30 cm away, we increase the counter by 1, else -1. Let’s say the robot move closer (now 20 cm away) to the grid and detects no blocks (i.e., phantom block), the counter will -10. Which means, the value of that grid is now -9. When a block is detected within the 1st 10 cm, we can conclude that there must be obstacles there. Thus we increase the counter by 1000, else -1000. Therefore, if the grid’s counter is positive, the simulator will take that there is an obstacle at that grid. |
 |
Alignment Calibration Command
Alignment is essential in ensuring that the robot is in the correct position. The robot can align itself without the Algorithm component. However, the robot doesn’t know if there is a wall in the direction where there is no sensor (i.e. right side of the robot). Thus, when a threshold has been made (every 30cm moved) and there exists a wall which the robot couldn’t sense, Algorithm will command it to rotate to that location and do the alignment with the wall.