CE3004 - MDP.

CE3004 - MDP is a group-based module where teams are required to program and build a robot to participate in 2 tasks. Teams would then compete with each other for a place on the leaderboard depending on factors such as task completion time and the correctness of identification captured images.

Task 1: Autonomous Movement & Image Recognition

The robot is required to traverse a square grid and correctly identify the images on obstacles of known locations and orientations. Incorrect identification of images result in penalty points.

Task 2: Fastest Robot Movement

The robot starts at a parking lot, and moves forward towards the first obstacle. Depending on the orientation of the arrow on the smaller first obstacle, the robot either turns left or right. A larger second obstacle is present behind the first obstacle. Depending on the orientation of the arrow on the second obstacle, the robot moves left or right. It then needs to go around behind the second obstacle and finds its way back into the parking lot. Hitting obstacles and the parking lot incurs in a penalty.

Deviating from typical hardware orientation and decision making processes.

The usual practice for Task 1 is to have a forward facing camera to capture image and a Cartesian coordinate system to traverse the grid.

The intuitive practice for Task 2 is to identify the arrow's orientation when the robot is right in front of the obstacle block 1 and 2.

Issue 1: Forward facing camera

The issue with implementing a forward facing camera is that the robot is required reverse out of the stopping point after image capture, and the time required to reverse out of this stopping point is unnecessary and adds on to the task completion time.

Issue 2: Cartesian coordinate system

The issue with the Cartesian coordinate system is that the robot is forced to move in right angles along fixed points of the grid, thereby increasing the distance traveled and adding on to the task completion time.

Issue 3: Best location to identify arrow orientation???

But is it really necessary for the robot to be directly in front of the image to identify the arrow's orientation?

We made changes to the typical orientation of the robot hardware, the robots decision making process and the shortest path algorithm to reduce the completion time for both tasks. Also we named our robot, Betty (it's an MDP tradition to name your bot).

Solution 1: Sideways facing camera

A sideways facing camera would eliminate the need to reverse out of the stop after image capture. Betty would just have to continue along its path, saving time.

This would also reduce the distance travelled, thereby reducing the error in distance and angle accumulated over time.

Solution 2: Polar Coordinate System

By following the Polar coordinate system, there is more flexibility in where the car can traverse along the grid. So, the shortest path between 2 obstacles can almost always be traversed by the robot, saving time.

This also reduces the error in distance and angle accumulated over time.

Solution 3: Identify arrow orientation when stationary

We identify the orientation of arrow of block 1 from the parking lot and identify the orientation of arrow of block 2 when robot has completed the 'Z' turn after turning in accordance to the orientation of arrow on block 1.

We could only do this because our image recognition tech was amazing. (Thanks Kang Ming and Sumi!! 🥰)

Sadly, we don't live in a perfect world. That means our solution implementations didn't go exactly to plan.

Issues with the Robot turning

Issues from Solution 2 arose from the fact that Betty does not turn in a circular path. It rather turns in an elliptical path, which makes hardware calibration and algorithmic calculations extremely hard.

We decided that it would be easier to fix this turning issue through hardware calibration.

So, we used the theoretical chord length values to find the closest practical servomotor value for each turning angle in increments 5 degrees to ensure that Betty "turned" in a circular path.

Issues with the Distance calibration

After calibrating Betty to move for 10cm, you would expect it to move fairly accurate for other distances, however this is not the case. As we increase the distance Betty moved, the deviation from actual distance increased too.

So, we found the average practical distance values in increments upto 150cm and used the above formula to calculate the distance values.

Unfortunately, Betty decided not to follow the gameplan on the days of the task due to hardware issues that we could not have forseen 😭.

Task 1 Assessment

During our setup phase for the task, the cable from the STM32 powering on our RaspberryPi burned out. With not enough time to troubleshoot this issue, we were forced to back out from this task.

However, here is Betty attempting the Task 1.

Task 2 Assessment

We ran into bluetooth issues between our Raspberry Pi and our image recognition laptop after the setup phase for task, and we had to back out of this task as well.

Here is a little video showcasing everyone's contribution and the ideas that went into the building of this project.

It was unfortunate that Betty was uncooperative 😭, but I had an amazing time working on this project with my team 😃.

Will I ever pick up hardware engineering in the future? Probably never!

Was I expecting to implement math concepts that I learnt years ago for this project? Also no! This project forced me to think outside the box and thats an essential part of problem solving.

No matter how bleak our situation seemed, I'm grateful that our team - Group 4: MealDiscoveryProgramme - never gave up, and it shows (when Betty decides to work 😅). I will be forever grateful for the time we spent together getting Betty battle-ready at the SCSE lounge.