Simple Robot using Arduino for RM100

I was recently re-introduced into the world of microcontrollers (MCU) such as the Arduinos and to get up to speed with this fascinating new piece of kit, I decided to build a simple robot and to fit it with as many sensors I could. However, this robot will have to be under RM100.

Hardware

I ordered the Maker Uno Bluetooth Robot Kit from Cytron as my base configuration and then added sensors as I saw fit. I added the following sensors:

  1. HC-SR04 Ultrasonic Sensor
  2. Light Sensor Module
  3. Temperature Sensor (Celsius)

The Cytron Robot Kit came with their Maker Uno which is essentially an Arduino Uno but with a board optimised for learning. The robot kit also comes with interested modules such as the Bluetooth transceiver module HC-05 which would allow Bluetooth connections including Serial over Bluetooth. This will allow us to read data from the Robot and instruct the Robot to move around. The L298N Dual H Bridge Motor/Stepper Driver was included to drive 2 motors, one on the left and one on the right side which makes 4 directions of motion possible (Forward, Backward, Rotate Right, Rotate Left).

The additional sensors I ordered were not just to decorate the Robot, the Light sensors and Temperature sensor are meant to record interesting environmental data. The Ultrasonic sensor or also known as a depth sensor will be placed at the front, allowing some kind of collision avoidance. The photos below shows the setup I built.

 

Software

I forked Cytron Technologies’ Git repository on Git Hub and got started programming the Maker Uno. I used Arduino IDE, it includes various useful tools to develop programmes that go on to an MCU such as a Serial Port monitor. Then, I proceeded to make tweaks to the original code and add code to support the new sensors I have included. Follow the link below to view my Git repository.

GitHub: https://github.com/zim96/KIT-RBT-BT

I have documented the additions and changes I made in the README.md of that Git repository.

Building a Foraging Reflex Multi-Agent System

This blog post is an adapted version of my paper submitted as coursework during the 2017/2018 school session for my BSc degree. This blog post is also an extension of the blog post linked below:

https://abdulhazim.wordpress.com/2018/09/30/foraging-reflex-agent-with-pseudo-deliberation-using-utility-functions/

Here, I was expected to build a Multi-Agent system that is based on the Single-Agent system built before. The core objective was to understand coordination in Multi-Agent systems.

This post will start off with a description of the task environment which is then followed by the design of the agent and the design of the fleet. The fleet is the collection of all agents working in the task environment, it also includes the coordination method design. It will then end with the discussion on the performance of the agent.

The Task Environment

The task environment can be abstractly defined as a simulation on a 2D plane populated by Cells and there are 4 types of Cells which are Empty, Station, Well and Fuel Pump. The 2D plane is inherently populated by Empty Cells with a random distribution of Stations, Wells and Fuel Pumps and the Tanks are the active entities and it is to be controlled by a Software Agent. Each Tank is controlled a copy of the Software Agent so every Tank behaves independently which is why Coordination methods are required to produce an efficient Multi-Agent system.

Additionally, there is a Fuel Pump always available at the origin (0,0) of the 2D plane. Also, the Tank can move in 8 directions on this plane which are North, South, East, West, North-East, North-West, South-East and South-West.

The task in this environment are controlled by Stations, they produce waste periodically that the Tank is meant to pick up and dispose at a Well. The Tank can only hold a maximum of 1000 waste and each movement consumes 1 fuel. The Fuel Pumps are refuelling points and movement actions can fail with a small probability of 0.0015. The Tank also can only see the environment in a square radius of 20 Cells.

The performance measure of an agent in this task environment is defined by the amount of waste a Tank can collect within a set duration of 10000 timesteps. The efficiency of the system is measured by dividing the sum of the performance measures by the number of agents.

Design of Agent

The design of the Agent is exactly the same as the one described in the previous blog post, the link of which can be found below:

https://abdulhazim.wordpress.com/2018/09/30/foraging-reflex-agent-with-pseudo-deliberation-using-utility-functions/

Design of Fleet

Besides coordination methods, the number of agents in the fleet and exploration policies are also variables that could be tinkered with to obtain an optimal multi-agent system. Those variables will also be touched upon in this article.

Firstly, a controlled fleet needs to be established. So, the simulation is ran using 4 agents in the fleet without any changes to the exploration policy and no coordination methods implemented. The paths of the agent are plotted in Diagram 1 below.

ActivePassiveCoordinationDiagram1

[Diagram 1: The path of agents when a fleet of 4 agents were used with no changes to exploration policy. Additionally, there was no coordination method implemented]

Exploration Policy

Next, the exploration policy was altered. An exploration policy named Incremental Exploration was developed. For instance, let the sequence of exploration directions be {0, 1, 2, 3, 4, 5, 6, 7}. To find the actual direction in the task environment, refer Diagram 2 below.

AcvtivePassiveCoordinationDiagram2

[Diagram 2: The map of directions and their corresponding indexes]

Incremental Exploration policy rotates the starting exploration direction with every new agent introduced into the simulation. For example, the first agent would explore direction 0, the second agent would explore direction 1 and the third agent would explore direction 2. Incremental Exploration policy brought new fleet behaviour in terms of path taken and it can be seen in Diagram 3.

AcvtivePassiveCoordinationDiagram3

[Diagram 3: The path of agents when a fleet of 4 agents were used with Incremental Exploration policy. However, there was no coordination method implemented]

If we try to distinguish the territories of agents by using the path taken by them, it can be observed that there are 3 clusters or regions. The gold path is one cluster to the bottom left of coordinate (0, 0), the orange path is a cluster to the bottom right of the coordinate (0, 0) and finally blue and grey are sharing a region. The sharing of region is what should be avoided as it can contribute to competition. For a multi-agent foraging system to be efficient there needs to be minimal competition.

When a new trial is performed with only 3 agents instead of 4, new behaviour of the fleet is spotted. The path taken by agents can be seen in Diagram 4. Here, it can be seen that there is better separation of regions which reduces potential competition. Therefore, a fleet of 3 agents will be built.

ActivePassiveCoordinationDiagram4

[Diagram 4: The path of agents when a fleet of 3 agents was used with Incremental Exploration policy. However. no coordination method was implemented]

Next, the sequence of exploration must be revised since there is a change in the number of agents in the fleet. An optimised sequence would be a sequence that ensures agents move away from each other at an equidistant angle. It will also need to be a sequence that ensures agents backtracks in direction perpendicular to the current direction. This ensures that the agent explores the area thoroughly instead of going too far away from the origin. Once again, we see a difference in the fleet’s behaviour and it is demonstrated in Diagram 5. The chosen direction sequence is {0, 6, 3, 4, 1, 5, 2, 7}.

AcvtivePassiveCoordinationDiagram5.png

[Diagram 5: The path of agents when a fleet of 3 agents was used with Incremental Exploration policy with tweaks to the exploration direction sequence. However, no coordination method was implemented]

Cooperation and Coordination

Two coordination methods are explored here which can be labelled as active coordination and passive coordination.

The active coordination takes a centralised approach such that whenever an agent is deciding to get waste from a station, it will query other agents of the utility function value they obtained. If another agent has a higher utility function value for that station, this agent would simply ignore the station. This approach is inspired by contract net and uses more computational resources but would ensure a more reliable and effective coordination method especially when there is a large fleet with a dense distribution of agents. This approach would also be easily verifiable.

The passive coordination method takes a decentralised approach such that whenever an agent calculates the utility function value of a station, it will scan the surrounding area of that station for other agents. If it sees another agent is moving towards the station, it would ignore that station to allow the other agent to carry on with the task. This method would use less computational resources but would not be as easily verifiable which also means that it may not be as reliable. This method would work best in small fleets with a sparse distribution of agents. Hypothetically, passive coordination would be a better choice in the fleet implemented here of 3 agents.

Results and Discussion

The agent program was evaluated by running it 50 times in random environments. The final score is noted down together with its coverage which is percentage of waste collected from the waste generated by the simulator. The table below shows the average scores and score ranges. Average score is the total waste collected by the fleet divided by the number of agents in the fleet which was 3. The score range is the difference between the maximum individual agent score and the minimum individual agent score.

Coordination Method Average Score Score Range
No Coordination 88618.28 81573
Active 87896.1 74046
Passive 85143.68 59088

The table below shows the coverage which is the ratio of collected waste to generated waste.

Coordination Method Average Coverage Coverage Range
No Coordination 0.78029 0.176092
Active 0.782282 0.173866
Passive 0.773074 0.240428

Based on the results, it cannot be concluded that one coordination method is better than the other. However, it was certainly interesting to see the range of the average score decrease when coordination methods were implemented.

Foraging Reflex Agent with Pseudo-deliberation using Utility Functions

This blog post is an adapted version of my paper submitted as coursework during the 2017/2018 school session for my BSc degree. Here I was expected to build a single agent system and measure its performance for the task environment defined by the module convenors.

This post will start off with a description of the task environment which is then followed by the design of the agent. It will then end with the discussion on the performance of the agent.

The Task Environment

The task environment can be abstractly defined as a simulation on a 2D plane populated by Cells and there are 4 types of Cells which are Empty, Station, Well and Fuel Pump. The 2D plane is inherently populated by Empty Cells with a random distribution of Stations, Wells and Fuel Pumps and the Tank is the active entity and it is to be controlled by a Software Agent. Additionally, there is a Fuel Pump always available at the origin (0,0) of the 2D plane. Also, the Tank can move in 8 directions on this plane which are North, South, East, West, North-East, North-West, South-East and South-West.

The task in this environment are controlled by Stations, they produce waste periodically that the Tank is meant to pick up and dispose at a Well. The Tank can only hold a maximum of 1000 waste and each movement consumes 1 fuel. The Fuel Pumps are refuelling points and movement actions can fail with a small probability of 0.0015. The Tank also can only see the environment in a square radius of 20 Cells.

The performance measure of an agent in this task environment is defined by the amount of waste a Tank can collect within a set duration of 10000 timesteps.

Design of Agent

Vision

The vision of the agent is represented in the form a square matrix of size 41. This is because the agent have vision around itself over a square radius of size 20 plus the Cell that the Tank is residing on. Relevant information can be gathered by iterating over the matrix in search of interesting Cells such as Stations, Wells and Fuel Pumps. This ‘iteration’ can be considered as a tree search problem and by iterating from the middle of the square matrix (the Tank), it would allow ranking of Cells according to distance in terms of timesteps. This would then allow the agent to perceive distances and make better informed decisions.

Reflexive Rule Matching

Reflexive Rule Matching refers to taking a reactive approach towards the behaviour of the agent as opposed to a deliberative approach. Here, the agent only considers its current state and never its potential states when making a decision. However, it also means some actions must be prioritised because rules tested must be in a certain order. The list of rules used is as defined in the ordered list below:

  1. Is there enough fuel to make it to the nearest Fuel Pump?
  2. Has the waste level reached the threshold and is there is a Well nearby?
  3. Are there nearby Stations with a task?

If none of the rules are matched, then the agent goes into Exploration mode which is explained in the following section.

Exploration

The exploration technique devised is inspired by clocks. Each indicator on the clock face represents the direction the agent can move in. For example, North, East, South, West, etc. The clock hand points towards the current exploration direction and each time the Tank refuels the clock hand moves and the Tank then explores in a different direction. The sequence of directions is predefined and can be tinkered with for optimisation purposes. The rationale behind this is to provide the agent a method of exploring without getting stuck in local minima.

Short-term Memory

Without any memory, the agent is forced to return to origin (0,0) if there are no Fuel Pumps in sight. The agent will also be forced to explore when it’s Waste tank is full and other tasks are readily available. Therefore, the agent remembers the last seen Fuel Pump and Well. However, this also means there must be some changes to the Rules defined above.

Long-term Memory

It would also be counter intuitive to continue exploring endlessly and it would be rational to re-visit explored areas to check the Stations for tasks. To do this, the Tank will need some sort of memory mechanism of previously visited areas. This is done by saving the Tank’s current position when the right conditions are met, this is called Pinning that is similar to Google Maps’ pinning . The conditions are:

  1. 4 or more Stations unique within the vision of the Tank.
  2. 1 or more Wells within the vision of the Tank.
  3. 1 or more Fuel Pumps within the vision of the Tank.

Utility Functions

To give the Tank the ability to select ‘Good’ areas to move towards to when searching for Stations and Wells, utility functions were introduced instead of just moving the nearest Station or Well. Fuel Pumps were not given the same treatment because it is in the best interest of the Tank to find the nearest Fuel Pump whenever Fuel levels are critical.

The utility functions consider multiple criteria such as Waste Potential and Survival Potential. Waste Potential denotes the possible amount of waste that could be disposed of from the area. The higher the Waste Potential, the better. survival Potential denotes the chances of survival while in the area, higher is better.

The utility function is the summation of Waste Potential and Survival Potential divided by the distance from the Tank to the Station or Well.

Results and Discussion

The agent was evaluated 10 times in random environments and the final score is noted. To provide a benchmark another agent is used named Simple Reflex Agent whilst the complete agent is named Utility-Reflex Agent. Simple Reflex Agent is the same agent without Short-term memory, Long-term memory nor Utility functions implemented.

 

Agent Architecture Avg. Score Score Range
Simple Reflex Agent 55538.6 94447
Utility-Reflex Agent 104258.9 27119

The table above shows that the Utility-Reflex Agent performed better on average and the smaller range in Score is also a positive outcome.

 

It would be an interesting addition to this little project to test this agent in other task environments such as a multi-agent system or an environment with obstacles such as mountains or rivers.

In conclusion, a Reactive agent architecture is an effective architecture to tackle foraging tasks. The addition of deliberation saw an increase in performance and it suggests that more deliberation in a simulated world would increase performance. However, it is not reasonable to suggest that this agent would perform similarly in more realistic task environment.

Status Update

Greetings,

Recently, I graduated from the University of Nottingham with a BSc (Hons) Computer Science with Artificial Intelligence in the First class. I am now pursuing my Masters in Computer Science (Applied Computing) at Universiti Malaya in Kuala Lumpur.

I wish I was more discplined to continuosly post my latest projects here during my first degree years. Nonetheless, I have made a plan to post the most interesting ones in the coming weeks in this order.

1) Foraging Reflex Agent with Utility Functions

2) Active vs Passive Coordination in Distributive Foraging Reflexive Multi-Agent Systems

3) Surrogate Models to accelerate Policy Optimisation

After this I hope to publish one blog post per week, it would either be about one of my projects, new advancement in the field of Artificial Intelligence or Data Science that I find interesting or it could even be about something I learnt recently.

Au Revoir,
ABDUL HAZIM

KTM Komuter – Timetable update

Hello everyone,

KTM Berhad has updated their Komuter train service schedule and it is with disappointment I report that they only provided the JPEG file of the train schedule. I can’t update the app I developed because of this. Besides, the image file provided was in poor quality. I have written to KTM Berhad asking for a PDF or Excel file that would allow me to update the app. With that, I apologise for any inconveniences caused.

However, I would also like to request for people to write to KTM Berhad about the PDF or Excel file request. They have a twitter and facebook. I will be putting up a warning on the HOME page of the app to avoid potential misinformation.

Cheers.

KTM Komuter KL (Android)

The initial concept behind this application is to provide users the capability of planning their journey when they are using the KTM Komuter service. The best way of doing so is to have an electronic schedule for the trains.

The ideal method of going about this is to have a software that can communicate with KTM’s trains in order to deliver the most accurate data possible to the users. This is partly because KTM’s Komuter train service isn’t reliable and can succumb to delays.

However, since I am not able to gain access KTM’s train data and the only data I have access to is the PDF train schedule provided by KTM. I developed a work flow that can take that PDF file and transform it into an electronic schedule as documented in Diagram 1.

KTMTrainWorkflow - Page 1.png
Diagram 1: Conversion of PDF to Database

The ultimate goal of this revised plan is to ensure the schedule is available quickly and easily. Therefore, an offline SQLITE database is chosen. The UI was also designed with a pragmatic mindset whilst minimising clutter on the screen. This gives the app a much more streamlined and friendly look.

Smartphone_Template1
Diagram 2: The “SEARCH” Page
Smartphone_Template2
Diagram 3: The “HOME” Page

Throughout the course of development, the UI has changed and this is the final version as of this post.

The main point was to make this app usable to the widest audience possible. Hence the the UI has to contain:

  • large text for better readability
  • easy gestures to manipulate the environment (swipes and taps)
  • large buttons for easy reach by users

The app also has to be available offline unlike most schedule apps available on the Google Play store at the time of development.

Get it on Google Play

First Post about Works in Progress.

Hello everybody,

I have decided to start a wordpress page to serve as my portfolio. However, I will only be including works that I have done starting from this post. This is to ease the whole process of documentation and also allows me to start fresh.

Just as a rough guide, I have experience in programming and app development (web, mobile, etc). Besides, I also have bee involved in video production and photography. I never shyed away from trying out new things which has brought me to have intereests in multiple fields. To put it simply, I can take care of the technical and artistic parts of software development.

Currently, I am working on a HTML 5 app and Convolutional Neural Networks. There are also plans to develop an android app but it is still speculation at the moment. I will be posting rough guides on those projects once they are done.