Hello all,
 
I bumped on the problem of having a proprioceptive sensor on the robot so that it can understand where it understand in which direction and how much it moves and give that data back to the blackfin in a way that can be measured.
 
In my books I saw lots of ways, like shaft encoder in the wheels, GPS, INS(inertial navigation system - VERY expensive ) e.t.c.
 
Admin though suggested something quite simpler which has even been tried before. Interfacing 2 optical mouse sensors in the SRV to measure how much it moves. So I made this thread so that it can be discussed with the community since I guess more people could be interested to this after being pointed out by admin.
 
Well the people who already tried it were kind enough to write some articles.
Here is a page with link to 3 other references about the same optical mouse hack. It was done by Mac. A. Cody. As you can see he gives directions to make a whole new sensor which does not even need to touch the ground.
 
Here you can see a detailed explanation with additional photos of the inner workings of that same mouse used in the above guide.
 
The problem is how to add such a thing in the SRV. Do you go so far as to make a whole new sensor from a mouse like the 1st link guy did? Or could it be done in a lot more simple way by opening a mouse, reducing it to the very minimum and addding it to the SRV. Where would you add it?  
 
To discuss questions like these with people who might be interested is the reason I made this thread.
 
For example I opened a USB optical Microsoft Mouse I had from 3 years ago resting in a shelf unused. It has many differences from the one detailed in the 2nd link but it is practically the same thing, but it uses a USB connection. Strange thing is that when you look at the usb cable you see all the 4 cables mentioned in the usb pinouts plus 1 more which is a lot thicker from the other 4. I don't know what it is.
 
So problem is how can you make the SRV understand these data? the D+ and D- (if you are using a USB mouse) and the DATA and CLK signals if it is a PS/2 mouse. Moreover where in the SRV could it be placed?  I was thinking front and back strapped with something (like a velcro) under the SRV.
 
So ... any ideas/input?

Hmm ... I see. Unfortunately I don't have any PICs lying around nor any programmers for PIC microcontrollers. On the contrary I have an AVR programmer and an Atmega8-16Pu.
 
Wonder if something can be done with that. Actually what you suggest looks like this which I just stumbled upon. I wonder ... is it really that much of a burder for the blackfin ti add another microcontroller?

BYU and others have used these sensors quite effectively for ground speed measurement with UAV's:
    www.ee.byu.edu/faculty/beard/papers/preprints/BarberGriffithsMcLainBeard05.pdf
    www.barnardmicrosystems.com/L4E_FMU_sensors_2.htm
 
I purchased some chips and crystals, as they are very cheap, but never got around to building a circuit.  So I am glad to see this discussion topic.  My personal preference for a coprocessor is ARM7 - an NXP LPC2103 costs around $3 (other versions with less memory are cheaper) and uses the GNU toolchain.  You could configure it as an I2C or SPI slave.

There used to be a C version of code posted with Cody's hack  - http://home.roadrunner.com/~maccody/robotics/croms-1/croms-1.html - though now he is using Forth.  It was set up for interfacing on a Linux system with parallel port.  I suspect it would not be difficult to modify the interface code to instead use one of the Blackfin GPIO pins.  I put a copy of the code on our website - here is the link  
    http://www.surveyor.com/blackfin/ADNS-2610.c

I've been looking into using an optical mouse sensor on my SRV too, and I found a "microsoft notebook optical mouse 2.0A" in a drawer... it uses a chip that looks like the adns2610 but I'm not sure it really is. It has the same "sun" pattern  and all, the only thing that differs is that it says "s2083 C0541C" (and not s2610 as I expected) on the top. I can't find any information from this, and I'm suspecting it's the same chip...
 
Does anybody own a adns2610 chip and could confim this please?

datasheet aquired, thanks a bunch!

Avago makes quite a range of optical mouse sensors, and I think the ADNS-2610 is a fairly old design, so it would not be surprising to find variations.  I actually bought a few optical mice in hopes of finding one with an ADNS-2610, but did not succeed, so you have more luck with this than I had.

Ok so I guess I should post it in this topic instead of the gcc inline assembly one since it is sensor communication source code related.
 
So here goes:
 
Remember this delay function from the gcc inline assembly topic:
Code:

void delay(u8 value)
{
	//for 250ns value should be around 28
	//should take in mind though all the other calculations
	//happening too, so we could wait for less
	int start= 0;
	int current = 0;
	start = *pTIMER4_COUNTER;
	//*pTIMER_ENABLE |= TIMEN4;
	if(*pTIMER4_COUNTER<start) //we had overflow and timer reset
			current = 4294967295/*2^32-1*/-start+*pTIMER4_COUNTER;
		else
			current = *pTIMER4_COUNTER;
	while((current-start) < value)
	{
		if(*pTIMER4_COUNTER<start) //we had overflow and timer reset
			current = 4294967295/*2^32-1*/-start+*pTIMER4_COUNTER;
		else
			current = *pTIMER4_COUNTER;
	}
	//we are done so disable the timer
	//*pTIMER_DISABLE |= TIMDIS4;
} 

 
Notice that I have commented out both timer enable and disable. Why? It seems to get the microprocessor stuck when I enable and disable the timer in the delay function so I am forced to leave it running all the time after an initTMR4(). If anyone knows why it would be a great help.
 
Now for the main part. Communicating with the sensor. I had managed to do it with an ATMega8 microcontroller. Now with the blackfin it does not seem to go all that well.
 
Here is how I raise and lower clock and data:
Code:

#define	raiseClock()		*pPORTHIO_SET |= 0x2000
#define lowerClock()		*pPORTHIO_CLEAR |= 0x2000
#define raiseData()			*pPORTHIO_SET |= 0x8000
#define lowerData()			*pPORTHIO_CLEAR |= 0x8000
 

 
Tried it with PORTHIO too but reading the manual I saw these registers as more friendly to use.
 
As for the write to the sensor operation:
Code:

void opticalWrite(u8 rAddr,u8 value)
{
	int i = 0 ;
	//we set the appropriate direction to the direction register
	*pPORTHIO_DIR |= 0xC000; //pins 14 and 15 as output
	
	//we make sure the address has '1' as its MSB
	rAddr |= 0x80;
	raiseClock();
	//we send the register's address
	for(i=8;i>=1;i--)
	{
		delay(28); 
		if(isSet(rAddr,i-1))
			raiseData();
		else
			lowerData();
		lowerClock();//SDA is changed on falling edges of the clock
		
		delay(28);
		raiseClock(); //and the sensor reads it on rising edges
		
		
	}
	
	//now follows the data
	for(i=8;i>=1;i--)
	{
		delay(28); 
		if(isSet(value,i-1))
			raiseData();
		else
			lowerData();
		
		lowerClock();//SDA is changed on falling edges of the clock
		
		delay(28);
		raiseClock();//and the sensor reads it on rising edges
		 
		
	}
	//the sensor's datasheet asks for 100us seconds delay between writes. Remember that
	 //when using the function

		
}
 

This should work? Right? Well it does not . Trying opticalWrite(0x00,0x01) which should force the sensor to awake mode(much more bright led) did nothing when with the ATmega8 with the same functions it worked.
 
I would like to ask for your input. Honestly I don't know how to proceed from here. I would also really appreciate tips for debugging embedded code. This summer is the first time I find myself working with such kind of code. It is very very interesting but debugging is hell.  
 
As for the physical hardware connections I checked them and they are correct. Sensor's CLK pin is connected to PH14 and Data pin to PH15.