Sensors

In order to provide the robot with a solid sense of awareness for its surroundings, I equipped it with 3 ultrasonic sensors. One sensor was placed at the front, whereas the other two were placed facing right and left. This allowed the robot to have a sense of whether there were objects directly ahead of it, as well as if there were any objects on its side. The sensors simply returned a number representing how long it took for the ultrasonic wave to bounce off the nearest object and return to the sensor. I then used this number along with a combination of the calculated speed of sound (according to the specified temperature) to calculate the distance to the nearest object.

Path Planning

The path planning for this robot was a simple control flow algorithm to determine the robots' actions dependant on its surroudings. The data received from each of the sensors was processed and operated on to determine the distance from the front of the vehicle to the nearest object, and then used to essentially stitch together a basic understanding of the robots' current surroundings. Dependant on the proximity of the nearest object at the front, or the nearest object at the left or right side, the robot would control its motors such that it moves away from any obstructions

Usage

Through feed.me's simple and easy to use user mobile app interface, users can snap a picture of their receipt on their phone, and then submit it. Once their picture is submitted, the backend logic takes care of using OCR to digitize the text and upload the ingredients to the server's database, where the ingredients are then used to return appropriate recipes to users right back on their phone

Server Side Logic

My role in this project was that of a backend developer. I took on the tasks of developing the backend server and implementing HTTP requestmethods for the front-end application to communicate with the server. I developed a flask web server to allow communication between the app and the database. Along with the server I developed a REST Api, implementing a variety of HTTP requests to fulfill actions for the application . My database of choice was MongoDB, as I love its flexibility and storage formats.

An early stage low level prototype for the home-page

Purpose

DigiCeipt was created as a method for individuals to be able to store their receipts digitally, rather than having to cope with the hassle of storing physical receipts. It began when I came home from university and saw my brothers storing some scattered physical receipts, which led me to decide that I wanted to create a digital storage solution to this problem.

Design

Problem Space

I began by understanding the problem space, potential users, and drafting a Situation Impact Statement to place some perspective on the problem I was tackling as well as the intended outcome. Then I moved forward to draft some personas using both primary information and secondary information.

Potential Solutions

Once I had a solid understanding of the problem space, I proceeded to break the problem into small functionalities that would be used to solve it. Once I'd identified these functionalities, I used a Morphological Chart to brainstorm a variety of potential solutions.

Solution Evaluation

Once my potential solutions were identified, I began to use a Quality Function Deployment (QFD) chart to undergo an in depth analysis and comparison of each of the options. By the end of the QFD, I had a certain solution scoring better than the other that I decided to proceed forward with.

Prototyping

With my solution now in mind, I started with a low-fidelity prototype of the solution. I didn't begin with a wireframe, but rather with a diagram showing the architecture of the application and the connections between each of the components. Once I had the functionality of the product planned out, I moved onto some UI low-level prototypes by just sketching out some interfaces. I'm currently in the medium-fidelity stage as my product isn't quite ready for production, but it is approaching a level of full functionality.

Iterate

This phase will continue forever!

Technical Details

Frontend

The dynamic client-side was developed using the Angular Framework and TypeScript. HTTP requests were sent to the server using the HTTP module and request results were subscribed to using Observables. Routing was incorporated to allow for multiple different views in a Single Page Application. Angular Material was used to contribute to a smooth and enjoyable user interface for users

Backend

A REST API was developed using an Express backend and Mongoose, implementing HTTP request methods to allow communication between the client-side and database. HTTP methods such as GET and PUT, and DELETE were defined at different endpoints in order to allow users to upload, edit, and delete receipts. API testing was completed using Postman, with the use of both manual and automated tests to ensure the endpoints were working according to expectations. MongoDB was used as the database of choice, the main reason being its scalability and ability to adapt to different storage formats as the need for/type of storage evolves.

An early stage prototype of the receipts view

Classes

These concepts ranged from a wide diversity, including classes to represent game components, such as a class for the player, as well as many more classes for different components such as zombies and accessories. Singleton classes were also incorporated to represent certain objects of which only one instance could exist, as well as static class implementations as well. Inheritance was also incorporated to allow child classes to acquire properties and methods from a base class.

Pointer Implementation

Pointers were implemented for memory maintenance and dynamic memory allocation. Memory was allocated when necessary for use and deleted when no longer necessary, ensuring optimal use of memory. I was able to learn about good memory allocation practices through this project and was also educated on dangling pointers, garbage collection, and programming to ensure that the memory heap is being used optimally.

Libraries

The SFML Library was used for the game's development and its many classes as well as class methods were used in the development process for a variety of areas, such as graphics, audio, and many more areas. This was an introduction for me to using libraries in C++ as I'd never used external C++ libraries before. It allowed me to gain comfort using libraries and their features, which has made me more comfortable as I continue to explore libraries such as STL and many more.