Jason -
Could you post your Myro/Conx code ? I'd like to give it try.
The "vs" command is basically a "floor matching scheme" - it needs a color sample that's taken from an open area in front of the robot, and then searches each pixel column in the captured image to look for the first mismatching pixel. So if "vs" returns 0C for a given column, that indicates that the first 12 pixels in that column match the target color, so which indicates an open area. The value returned from "vs" for each column is roughly proportional to the distance of an obstruction from the front of the robot (depending on camera angle, the closest ground measurement might be 10-12 inches out).
In the C and BASIC code, I divide the visual field into 3 overlapping regions of 40 columns, so left is 0-39, middle is 20-59, right is 40-79.
vscan(ix);
for (ix=0; ix<3; ix++) { // in groups of 40 columns, compute max, mean and # of zeros
tmax[ix] = tmean[ix] = tzeros[ix] = 0;
for (jx=0; jx<40; jx++) {
itmp = tvect[(ix*20) + jx];
if (tmax[ix] < itmp)
tmax[ix] = itmp;
tmean[ix] += itmp;
if (itmp == 0)
tzeros[ix]++;
}
if (tzeros[ix] < 15)
tmean[ix] /= 40;
else
tmean[ix] = 0;
That's just one way to do approach the problem of reducing the dimensionality of the "vs", "vf" or "vn" input data.
By the way, I have temporarily paused the effort to move neural network functions to firmware - we're going to learn a lot by building these models in Myro/Conx, and once we have a clearer idea of what kinds of sensor mappings work best, we can move this functionality onboard, while sharing common data structures so that we can move models back and forth between host and firmware. Until then, it seems counterproductive to pursue two different approaches to modeling these networks, especially considering the richness of Myro/Conx and their ability to access the robot's vision and IR functions.
As regards the combination of IR and color tracking - there's no easy way to predict how that is going to work - you just have to build the network, feed it data, and provide a mechanism for error feedback so that the network can learn. I know of 3 ways to approach this:
1. build a set of training data that simulates different inputs and matches those with desired outputs - this is how you originally trained your network with the IR sensors
2. simulate the robot's world, and evolve the robot's network with genetic algorithms, along with a fitness function to evaluate performance
3. operate the robot in the real world, with a "supervisor" telling the robot when it has made good or bad decisions, and feed that "error signal" back into the neural net training.
You already have a pretty good idea of how to do #1. The issue is that there is no learning - the model is based on static data.
#2 involves the addition of a bunch of tools. Webots is actually ideally suited for this type of modeling, as is the evorobot software -
http://laral.istc.cnr.it/evorobot/simulator.html . There's a new version of evorobot coming out soon, and the developers are already working with the SRV-1, so I look forward to seeing the new software. The developers of Webots have likewise shown a lot of interest in this type of project, but there just hasn't be time to pursue it.
#3 is interesting, and we really should focus some effort there. We can start with a network that is trained offline using #1 techniques, and then create a real-time feedback mechanism to evolve the network. We should try a simple case first, just using IR or just using color. In the color case, we should add size/count to x1, x2, y1, y2 in order to evolve behaviors that make the robot back off if it gets too close to the object.
How's that sound ?
Pages: 1 2
Myro and ffnet (Read 18374 times)
