As I already pointed out, the robot has some issues to recognize the 2d bar-codes while it is moving, so I had the idea to associate a coloured object (a green paper) to every bar-code and added all the necessary processes to the computer application to be able to recognize the green colour. To make a long story short, when the robot wants to find the blue zone, it is looking for the “B” bar-code, as soon as it finds it, it follows the green coloured object that is just next to it.
By doing that, the robot won’t have to recognize a bar-code properly on every image because the bar-code would only be used once for identification purpose. And because after the identification the robot is following a coloured object, it is way more efficient (it was demonstrated before that the colour recognition is very stable and efficient even on blurry images).
The problem is that even this method was not stable enough to be very reliable, indeed, it happened that the robot still did not recognize the bar-code in the first place and so did not tried to follow the green object neither.
So I decided to change a key element of the problem which is the bar-code recognition and to remove completely the bar-codes from the equation and replacing them by pieces of paper of different colours.
Indeed, if my colour recognition algorithm can differentiate perfectly the red and the blue, it should also be able to differentiate the green, yellow and violet colours (the three colours with a hue different enough).
I spent a couples of hours replacing all the flag recognition by coloured zone recognition and adapting the UI to configure them properly. Now all the new set-up needs to be tested but I am very confident as I already tested it in out of the environment and it looks promising, but because I won’t be at uni tomorrow, the actual testing will probably wait until Wednesday.
Yet another clever solution to a nagging problem well done.
We discussed his poster design. I made a few suggestions.
A very annoying problem since I am working with the net2 package of JCSP on the Android phone was to stop the app completely; in fact, when I stopped the experiment by just closing the app it was not closing its process, so every values and processes accessed in a static way were kept in memory.
This very strange behaviour implemented by Android had for effect to make the application crash every two runs because when net2.Node tried to instantiate itself, it discovered that it was already instantiated and that the Wi-Fi sockets it was about to create already existed too!
So today, I decided that this recalcitrant piece of code could not continue to humiliate me like that, so I created a very simple Android application that is just be creating a JCSP.net2 server connection. I ran this application two times and as predicted, it crashed at the second run. I had my test case and won’t stop working on it until I find a solution or die of insomnia.
And after a couple of hours trying to modify net2’s source code, investigating on internet and reading the bug logs of the phone, EUREKA! The solution to this problem was found [here]. It is probably the problem on which I spent most time on during this project (I think I tried to find a solution to this problem more than 10 times) and it was solved in only one line to call when the program closes (by overriding the finalize method) which is:
The wording of the blog made me laugh out loud; thank you!!
It is sickening to discover that one line of code is all that is required!!
As planned in the project’s Gantt chart, this week was spent on writing the project report.
More importantly we discussed the Critical Evaluation that goes in the final chapter
This should cover things that were done that could have been done better eg QR and Data Matrix
Use of the Blog to generate reference lists which then enabled checking that stuff had been written so references could be cited.
POSTER prepare an outline poster we can discuss