Using Parallax Laser Rangefinder as a camera.
Bean
Posts: 8,129
If I am reading the datasheet correctly the only image formats that can be obtained are:
160x128 8-bit grayscale
640x16 16-bit color (w/laser enabled)
I'm confused by the 640x16 color resolution.
Is there any way to get a high resolution (640x480) color image data from this ? Preferable with the laser disabled.
I would guess the camera can do it, but you need an NDA to get the datasheet.
Bean
160x128 8-bit grayscale
640x16 16-bit color (w/laser enabled)
I'm confused by the 640x16 color resolution.
Is there any way to get a high resolution (640x480) color image data from this ? Preferable with the laser disabled.
I would guess the camera can do it, but you need an NDA to get the datasheet.
Bean
Comments
-Phil
I don't know what the slowest clock speed is. But there are various propeller boards with additional SRAM on them that could be used.
Initially I would like to do experiments by processing the image data "on-the-fly" again if the camera clock speed can be slowed down enough.
Either way it would be a pretty good generic digital camera for any microcontroller if it just had the commands to get full-frame color data (even 160x128 8-bit color would be okay with me).
Bean
One should be able to look for color blobs without keeping the whole image in memory.
I'd also like to try using it with one of the many external memory options.
Having access to the color image would make this a more attractive product.
Duane
Edit: I have used it normally though!
CON OVM7690_Addr = %0100_0010 ' SCCB/I2C address: corresponds to write address $42 and read address $43 CamXVCLKFreq = 24_000_000 ' XVCLK frequency determines SCCB (Serial Camera Control Bus) speed, OVM7690 data sheet section 1.2.9 ' I/O pin connections to the Propeller ' Others defined in OVM7690_fg CamPWDN = 8 CamSDA = 9 CamSCL = 10 CamXVCLK = 14 ' Frame grab type GreySingle = 0 ' single greyscale frame ColorSingle = 1 ' single color frame ColorRange = 2 ' color frame grab specific for range finding: ' one with laser on, one with laser off, background subtraction for better detection of laser spot ' details of pixel subtraction: [URL]http://homepages.inf.ed.ac.uk/rbf/HIPR2/pixsub.htm[/URL] ' Results display type ResultASCII = 0 ResultBinary = 1I have a LRF on order, just need to wait for it to arrive. I can't wait to start experimenting. Waahhh, haaa haaa, haa haa.
Bean
The sensor is too fast to do any kind of processing on-the-fly. Pretty much you can just store the data.
So I guess the question is would you rather have high-resolution and low bits per pixel, or low-resolution and high bits per pixel ?
I'm thinking about trying 120x90 16-bits per pixel (5,6,5). That should be usable.
Bean
Do you have access to the high res color images?
Even if just one frame at a time that can be stored to external memory.
I'd like the option of having a high res color image that I could then look at (with a program on the Prop) and find color blobs etc.
Can you capture a 640 x 480 (I think16-bit color would be good enough) image?
The ability of access a high res color image is an important feature to me.
Thanks for the update.
Duane
The problem is that the camera supplies the pixel clock. The clock rate is 1MHz (I think, might be 500Khz), so it doesn't leave alot of time to do much processing.
I don't have a C3 or other board with SRAM, so I don't know how it compares to HUB access in speed.
There might be a way to slow down the pixel clock ? I don't know
From what I've seen, you CAN get a 640x480 color image (8 bit Y, 8 bit U, 8 bit V). But you need a storage media that is fast enough to store it.
Bean
My thought is to have data passed directly to some SRAM. This seems like the problem a solution of eight parallel SRAM chips has been waiting for.
The Prop could then leisurely look through the data for color blobs etc.
Do you think this would be possible? (I wont hold you to it.)
I'll likely buy one of these if you think this would work.
Thanks for all the information so far.
Duane
I'd say it is do-able. The code for the 640x16 frame grabber actually sets up the camera for 640x480, then skips the first 200+ lines to get to the middle 16 that it wants to store.
WRBYTE is pretty slow, so external SRAM may not be too much slower (if any).
Just to get familiar with the frame grabber code, I optimized it somewhat and perform the byte-swap "on the fly" so you don't need to do it at the end.
I wish Joe would have made a simple camera board with some SRAM. I think it would have sold very well.
Bean
It's very nice to know all this ahead of time. I think I'll probably order one of these.
Personally I thought it was priced a bit high. If you just want a rangefinder, I think a laser a Wii camera would likely do the job and be a lot less expensive.
Having access to the camera image makes the Parallax Laser Rangefinder a much more useful product.
Duane
I was wrong about the pixel rate, it is 2MHz.
I have made changes to the firmware to allow a color capture of 120x85 pixel frame in the same format as the 640x16 frame (16-bit YUV422y1,u,y2,v]) by sending the character "Y".
At the moment I don't have any way to seeing the image data.
If I post the code would have the ability to test it ?
Bean
Send it a "U" to setup the auto-baud.
Send it a "Y" to request a full color frame (120 x 85 pixels).
The pixels are send as pairs consisting of 4 bytes [y1,u,y2,v] so the same "u" and "v" values are used for both pixels y1 and y2 (which have the luma or grayscale value). All are 8-bits. "u" and "v" are signed.
So each line is 240 bytes.
A good starting point would be to display just the y1 and y2 as grayscale (ignoring "u" and "v").
Bean
Bean
I just looked through the code. It's amazingly well documented.
I agree with you, if I can find a way of storing the data, I should be able to save a high res image.
I was just looking at the schematic and the product photo. It looks like pins 16 - 23 aren't used and are brought out to solder pads (very nice). I think I'll use these pins for SRAM data lines and use the red and green LED pins for clock and chip select.
Color blobs and world conquest here I come. (I just need to ask my wife first.)
Duane
That is perfect, just ignore every second byte.
The YUV422 protocol uses one "U" and one "V" value for each pair of consecutive pixels because intensity ("Y") is more important than color ("u" and "v") to the human eye.
So four bytes represents two consecutive pixels
Bean
A small Acer Asprire netbook or equivalent can be had for about $200, which has a built-in camera will run RoboRealm. You could make your own laser rangefinder; mount a small laser pointer and track the laser spot with the camera and computing using the parallax effect. Now you have a camera, imaging, plenty of processing power & apps. Mount it on a small mobile platform and it would be like a mini ER-1 from Evolution Robotics.
I also made a viewer (black and white threshold) using VGA on the Demo board just to make sure it was working.
I cannot check the color bytes "U" and "V", so if someone with a color display could that would be great.
Bean
Bean
Thanks for sharing what you've found out. It really helped me to decide about purchasing the rangefinder or not. I ordered one today.
I plan to make an 8-bit SRAM module to store images from the camera.
I'd like to figure out how to display images (not necessarily high res) on Rayman's 4.3" displays. I think this is going to take several Propellers working together. I think I'll share the 8-bit SRAM bus with another Prop so it can read the images faster. I'll probably just have the LRF board store the image to SRAM and have a second Prop analyze and display the images.
Thanks again Bean.
Duane
Con _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 ack = $06 ' Acknowledge byte nak = $15 ' Invalid command byte Var Obj db : "pcfullduplexserial" Pub start| i,j,x,y db.init db.addport(0, 31, 30, -1, -1, 0, 0, 115200) 'debug port db.addport(1, 6, 7, -1, -1, 0, 0, 115200) 'camara db.addport(2, 4, 5, -1, -1, 0, 0, 115200) 'uoled db.start waitcnt(clkfreq*3+cnt) db.rxflush(1) db.tx(1,"U") repeat until db.rx(1) == ":" db.rxflush(2) db.tx (2, "U") waitack waitcnt(1600000+cnt) erase db.str(0, string("uOLED ready",13)) display repeat Pub waitack | temp repeat until db.rx(2) == ack Pub erase db.tx (2, "E") waitack Pub display | p, x, y db.tx(1, "G") repeat y from 0 to 127 repeat x from 0 to 159 if x < 128 p := db.rx(1) plot(x, y, p, p, p) else db.rx(1) Pub plot(x, y, r, g, b) ' X : 0 to 127 ' Y : 0 to 127 ' Red : 0 to 255 ' Green : 0 to 255 ' Blue : 0 to 255 r := r >> 3 << 11 | (g >> 2 << 5) | (b >> 3) db.tx(2, "P") db.tx(2, x) db.tx(2, y) db.tx(2, r.byte[1]) db.tx(2, r.byte[0]) waitackYour plot routine is sending 5 bytes to the oLED for every byte recieved from the LRF.
The input buffer from the LRF will surely overflow waiting for the oLED to send and ack each pixel.
Try making the LRF baud rate much slower (like 19200 or 9600).
Joe, if you are reading this...What is the chance of getting the windows viewer software to support 128x80 color frames ? Seems like there is a fair amount of interest in using the LRF as a camera.
Bean
Edit: I updated the baud speed for the LRF and fixed the x plot range of the uOLED.
Con _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 ack = $06 ' Acknowledge byte nak = $15 ' Invalid command byte Var byte buffer[20480] Obj db : "pcfullduplexserial" fd : "fullduplexserial" Pub start| i,j,x,y fd.start(6, 7, 0, 115200) ' db.init db.addport(0, 31, 30, -1, -1, 0, 0, 115200) 'debug port 'db.addport(1, 6, 7, -1, -1, 0, 0, 57600) 'camara db.addport(2, 4, 5, -1, -1, 0, 0, 115200) 'uoled db.start waitcnt(clkfreq*3+cnt) fd.rxflush fd.tx("U") repeat until fd.rx == ":" db.str(0, string("Camara online",13)) db.rxflush(2) db.tx (2, "U") waitack waitcnt(1600000+cnt) erase db.str(0, string("uOLED ready",13)) get display repeat Pub waitack | temp repeat until db.rx(2) == ack Pub erase db.tx (2, "E") waitack Pub get | p, x, y fd.tx("G") x := 0 y := 0 repeat y from 0 to 127 repeat x from 0 to 159 p := fd.rx buffer[(y*160)+x] := p Pub display | p, x, y repeat y from 0 to 127 repeat x from 0 to 159 if x < 128 p := buffer[(y*160)+x] plot(x,y,p,p,p) Pub plot(x, y, r, g, b) ' X : 0 to 127 ' Y : 0 to 127 ' Red : 0 to 255 ' Green : 0 to 255 ' Blue : 0 to 255 r := r >> 3 << 11 | (g >> 2 << 5) | (b >> 3) db.tx(2, "P") db.tx(2, x) db.tx(2, y) db.tx(2, r.byte[1]) db.tx(2, r.byte[0]) waitack