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!!
While I was testing the robot in its environment, the Bluetooth connection between the phone and the robot stopped working for a reason I still can’t figure. To solve that, I decided to go find on internet any person who worked with LeJOS NXJ from an Android phone over Bluetooth, and I found the perfect solution on a forum : NXTCommAndroid [source]. This developer actually ported completely all the comm package from the PC LeJOS API to Android. I implemented it and it worked perfectly on the first try! I also figured out that he posted it on the 9th January so less than 1 month ago.
Even further, this portage may allow me in the future to control completely the robot from the phone and avoid having any code other than the Bluetooth receiver on the robot…
In order to create the environment in which the robot will work, we needed to know how high the robot could see based on its distance from a wall.
To do so, I did 5 measurements from 5 different distances of a wall and concluded the related linear equation.
Note: because I didn’t have a ruler at the time of the experiment (nor any of my flatmate!), I worked with objects with standard dimensions (a credit card and A4 sheets).
|Distance from the wall (cm)
||Visible height on the wall (cm)
So the approximate equation is : y = 0.3014x + 7.155 where y is the height on the wall and x the distance between the robot and the wall
Cloth to cover base board and card for edges was obtained, which together with corner supports made an environment for the robot to operated within. The environment was white so as to aid the detection of the coloured balls.
For the robot to recognize the drop zone (the place where it will drop the balls at), I thought about putting little flags 0n them with a black and white shape (to avoid any interference with the colored balls recognition).
My first idea was to work with 2D bar codes : a widely used open-source Java library called ZXing [source]. It can decode these two 2D bar code formats:
So I tried to encode the letter B and the letter R (for blue and red) in each of these formats.
QR code :
So these are the most simple 2D code I could generate and I am not really happy of the size and complexity of those. Even the most simple of them (the data matrix) is generating an image of a complexity of 10×10.
So I am still trying to find a simpler 2D decodable symbol.
Demonstrated that the QR matrix is probably the best solution because there are Java classes that detect it!
Arnaud was worried about size of flag relative to space balls working in. I suggested a space of no more than 1.5m square, which will be feasible. This will require quite large flags, a vertical phone perhaps lower down on the robot.
We also discussed his process architecture for ball recognition and robot control. It has an implicit deadlock due to its network BUT he can argue that it will not deadlock by presenting the appropriate case and the order in which inputs to the processes happen.
As usual he is making really good progress; very well done
The task for next week is to see how well the system can detect QR codes, at what distance and size and orientation of flag.