Video example -  
    http://www.youtube.com/watch?v=UpZ3yLnmCwQ
 
                       RELEASE NOTES
 
SRV-1 firmware build for Blackfin - 26 July 2009  
    http://code.google.com/p/surveyor-srv1-firmware/downloads/list
 
* created neuron[] output array for picoC's nntest() and nnmatchblob()  
  functions.  also, return value from nntest() and nnmatchblob() is an index  
  to the neuron[] entry with highest value (i.e. best match)
 
* added support for uBlox5 gps via I2C.  gps functions now autodetect
  Locosys gps (uart) and uBlox5 gps (i2c).
 
* added '$Mx' and '$m' optical flow test functions.  $Mx compares consecutive
  frames at full resolution, where x=1,2 or 3 represents +/-4, +/-8, +/-16
  search range for 16x16 blocks.  $m scales the image to 80x64 and compares  
  consecutive frames with 16x16 blocks over +/-16 pixel range.  still need
  to add a display function.
 
* added 'iMabc' i2c command to read multiple registers - ('abc' parameters  
  sent as 8-bit binary) a is device id, b is register, c is count, xx is  
  8-bit return values from register displayed as decimal value  
 
* removed 'G' command - now any 'g' command that doesn't match existing
  g commands (g0, g1, g2, g3, g4, g5), e.g. 'gx' will turn off all g functions.
  
* updated to picoC v0.92.  added picoC version # to SRV-1 ##Version string
 
* added new 'G' command to support HTTP GET requests with httpd() function.  
  delivers statically defined HTML content in httpd.c
 
* added autorun() function to picoC.  if "autorun" string is found at the  
  beginning of flash buffer #4 (user flash sector), firmware will launch
  picoC with program stored in flash sector #4.  autorun() provides an escape
  mechanism - it takes a parameter which tells how many seconds to wait for
  and ESC character.  e.g. autorun(5) will listen for 5 seconds to the  
  serial / wifi channel for an ESC character.  if no ESC is received, picoC
  will continue execution of stored picoC program, else it will return control
  to main() SRV-1 control loop.  note that to set up flash sector 4, use  
  'zw' command to write the contents of the flash buffer, 'zr' to read flash
  sector 4, and 'zc' to clear flash buffer contents
  
* changed vblob() to return -1 if too many blobs found
 
* changed svs_master() and svs_slave() functions to support 2-way data transfer.
  $X, $R, $1 and $2 test these functions.  using GPIO-H8 to synchronize capture
  and data transfer between left (master) and right (slave) Blackfins in SVS.  
  'g5' command to master enables stereo processing and displays stereo features.
  'gx' turns off stereo feature display.
 
* split SRV-1 and SVS firmare into separate builds, using Makefile.mono and
  Makefile.stereo, along with -DSTEREO compiler flag.  Firmware images are now
  srv1.ldr and srv1.ldr.stereo.  load0 script works for upload of srv1.ldr,  
  load1 + load2 scripts for srv1.ldr.stereo
 

Profuse apologies for anyone who had problems with the new firmware on the SVS - I forgot to note that the SVS needs a jumper installed for signaling between the two Blackfins.  The jumper connects GPIO-H8, which is pin 25 on the 32-pin header ...
 

 
Without the jumper, the right Blackfin can lock up waiting for a signal from the left.

It should, though not as efficiently as simple frame differencing.  It is really looking for a correlation between frame-to-frame pixel locations.  In any case, every time you use the function, it captures a new frame and saves that frame as a reference for the next iteration.  
 
The search is based on 16x16 blocks of Y pixels (no search at present using U and V).  It looks like I have the search hard-wired for +/-16 pixel range ($M3), so it may be ignoring the search range parameter in $M.  Also, I think the highest capture resolution currently supported is 320x240, but we could extend that, though higher res searches will be slow and will be able to track small changes.

Actually, I don't think there has previously been an explanation of optical flow posted here.
 
With optical flow, we are computing motion vectors between blocks of pixels on successive frames.  We are using 16x16 pixel blocks, and doing an exhaustive search by shifting each 16x16 block in the image against all pixels within a range (up/down/left/right) of +/- 4, 8 or 16 pixels.  So if there is no movement from frame to frame, pixels will line up from frame to frame, thus the horizontal and vertical motion vectors will be 0.
 
The vector size is 2x the amount of pixel offset between corresponding macroblocks.  With the $M1 command, the range will be +/-8 for pixel search range of +/-4.  With $M2, the vector range will be +/-16.  With $M3, it will be +/- 32.
 
$m processes Y, U and V, in an image that has been scaled to 80x64, so the offset range will be +/-96.  Divide the actual number by 6 and you'll have approximately how much the macroblock has moved from frame to frame.
 
In the following example, the first $m captured the reference frame, so there was no change.  $m is scaling the image to 80x64, so there are 5 16x16 macroblocks horizontally and 4 macroblocks vertically.  If I rotate the robot a bit to the left, and the X vector for most of the blocks shows a negative value, while the Y vector for each block is generally unchanged.  
 
$m
 0  0   0  0   0  0   0  0   0  0  
 0  0   0  0   0  0   0  0   0  0  
 0  0   0  0   0  0   0  0   0  0  
 0  0   0  0   0  0   0  0   0  0  
$m
60  6  -36  0  -36  0  -36  0  60  6  
-36  0  -36  0  -36  0  60 -4  -36  0  
-36  0  -36  0  60  6  -36  0  -36  0  
-36  0  50 -44  -36  0  -36  0  -36  0  
 
With $M3, it takes a lot longer to compute, as there are a lot more 16x16 macroblocks.  Note that the posted version of firmware is hardwired to M3.  To support $M1 and $M2, change lines 690-691 in srv.c from
    _motionvect((unsigned char *)FRAME_BUF4, (unsigned char *)FRAME_BUF3,  
       vvect, hvect, (int)imgWidth, (int)imgHeight, 3);
to
    _motionvect((unsigned char *)FRAME_BUF4, (unsigned char *)FRAME_BUF3,  
       vvect, hvect, (int)imgWidth, (int)imgHeight, srange);
 

We haven't yet posted the instructions for calibration table upload, but the default tables are configured for the 3.6mm lens.  This is on our "to-do" list.  In the mean time, you can find some background on the calibration procedure here -  
    http://code.google.com/p/sentience/wiki/SurveyorSVS
 
At the moment, the steering is manual, so direction indicator is only a recommendation, but we are working on an autonomous mode, along with better matching performance.

I am new to the SRV-1, but I received my first one earlier this week. It is the SVS stereo module, so I thought I might try out the stereo firmware functionalities, but I keep getting freezes.
 
Are there any instructions for how some simple stereo demo should work?
 
I should point out that all the mono features I've tried seem to work (mean YUV, thresholding, grabbing JPEG's, adjusting the image resolution).
 
Here is a screen dump of an example telnet session that shows the problem:
 
g5
##g5
I
##$X SPI Master - Ack = 0x0
Received bit not set
<gobbledygook binary data follows>
 
I
V
 
(at this point no responses from the SRV-1.)
 
I assume the problem has something to do with the "Received bit not set" error above. I've looked at the firmware source, and it appears that this would imply that the two boards are not communicating via SPI bus. (This may be confirmed by the fact that the second board yellow lights do not flash when I send these commands, they solid after the boot sequence finishes.)
 
Is there a command I should be sending to "initialize stereo communications" other than the "g5"?
 
Note that I've also tried hacking client-srv1.cpp SDL client (adding the 'g5' command) to check if it was something funky going on in the terminal, but same result (it sends over one image with the red and blue circles composited on top after the 'g5' is sent, then that image freezes and the program times out after a few seconds of not receiving any responses.)
 
Please let me know if there is something I should try or test.
 
Thanks!
--Xye
 

The board I recieved had the green jumper wire already installed for the GPIO-H8 connection.
 
I also tried upgrading the firmware since it was a slightly older version that came with the board, but this didn't fix the problem either.
 
What does seem to fix the problem is running the 'stereo.c' program to query a couple of frames from both eyes first, and then close it and issue the 'g5' command. I'm not sure why this would make a difference, but maybe the right eye needs to have a few commands sent to it to initialize some things before the left eye requests the disparity feature data.
 
At this point, I can issue the 'I' command as many times as I want and get the image (with the 3-D overlay information).
 
So, I will  just tinker with what commands to send to the right eye based on whetever commands the 'stereo.c' viewer seems to send and see if I can reproduce that from my own code.
 
Maybe problem solved?
 

In the new 081809 firmware, what is the radar like display I'm seeing for the SVS?  I'm guessing it's some type of map display. It only seems to display data between about 9 and 11 o'clock on the display.  Is there anything interesting we can do with this?  Also, the disparity blobs are far more visible in red than they were in green.
 
Thanks...Win