Friday, June 30, 2006
Blog Info
To that handful that has wandered across this blog, it appears that when I tested moderation months ago, I didn't save the notification email. Well, I just found my backlog, cleaned out the ads, and published everything else. I've removed moderation for now and now have enabled image verification. We'll try this for a while. I think I need to setup some other notification to... wonder if there's an anonymous email form...
ITX
Now, some of you are familiar with the Via Mini and Nano ITX boards. Nice boards running the Via C3/C7 series processors, 500MHz to 1.5GHz. Mini boards are 6x6 inches square and use "standard" PC components. Nano boards cost nearly twice as much and use laptop components. RAM prices for your desktop DDR2 and laptop SO-DIMM memory is about the same. I'd run the OS off a 4GB CF card connected to the IDE busses that are on both systems. Video is integrated. USB and firewire do also exist depending on the hardware setup. Some 3rd party variants have an expansion bus that can have cards added to give additonal serial ports, LAN ports, even a cardbus CF and PC card dual slot.
To make these things connectable as the core of my MILES2020 design, handling any 802.11g communication, doing video processing from a local camera, providing voice communication, possibly driving a HUD or other video display (wrist mounted map screen?). I planned a lot of this for individual microcontrollers, but some of that processing duty can be offset into an ITX system. Nano boards have a mini-PCI slot, mini have a standard PCI, so cards are available for both.
How to mount it? I figure middle of the back, within a molded case. A LION battery pack would be below it, in a similar protective housing and connected via a cable. A USB microcontroller would provide a link to a CAN bus. The hardwired ethernet connection provides a high bandwidth link to a camera module (maybe the MILES gun main MCU?) if used.
Any other ideas?
Thoughts?
To make these things connectable as the core of my MILES2020 design, handling any 802.11g communication, doing video processing from a local camera, providing voice communication, possibly driving a HUD or other video display (wrist mounted map screen?). I planned a lot of this for individual microcontrollers, but some of that processing duty can be offset into an ITX system. Nano boards have a mini-PCI slot, mini have a standard PCI, so cards are available for both.
How to mount it? I figure middle of the back, within a molded case. A LION battery pack would be below it, in a similar protective housing and connected via a cable. A USB microcontroller would provide a link to a CAN bus. The hardwired ethernet connection provides a high bandwidth link to a camera module (maybe the MILES gun main MCU?) if used.
Any other ideas?
Thoughts?
Mobile Computing
Mobile computing is one of those sticky subjects. Modern mobile computing runs around as cell phones and PDAs. Then there's the crazy people working on a "wearable comping" system that keeps them partially in a computer generated world at all times.
I'm not THAT crazy. I look more for something resembling military computing. There when you need it, mostly hidden when not. One thing that popped up recently is a tech outline of a wearable PC. See link here:
http://www.eurotech.it/main/news.asp?2M=75
Now, I've run across enough hardware to consider how to build one. A base board system would distribute controls as needed. The main CPU would be a Gumstix, with video breakout and some extra IO. I'm hoping they have a lot of breakout of the video and input hardware. This could be hooked into a 2.2" touchscreen TFT screen ($50 from Mouser). The base board also has built in audio connectors. A 400MHz Gumstix running Linux may be powerful enough to run a voice recognition software package, providing hands free access. A subsystem microcontroller would control stuff like LEDs, IO, touchscreen, etc. I'd probably integrate a pseudo-IMU so that motion may be used to do some control, such as a mouse. I might also wire in a glove or something to allow controlled clicking, or move the IMU to the back of the hand there (now there's an idea...)
Depending on size, a LION battery set can be hidden either behind the board or elsewhere (depending on ergonomics and design). Now, final design is that the casing could be made to look rather professional with a vac-formed casing.
I'm not THAT crazy. I look more for something resembling military computing. There when you need it, mostly hidden when not. One thing that popped up recently is a tech outline of a wearable PC. See link here:
http://www.eurotech.it/main/news.asp?2M=75
Now, I've run across enough hardware to consider how to build one. A base board system would distribute controls as needed. The main CPU would be a Gumstix, with video breakout and some extra IO. I'm hoping they have a lot of breakout of the video and input hardware. This could be hooked into a 2.2" touchscreen TFT screen ($50 from Mouser). The base board also has built in audio connectors. A 400MHz Gumstix running Linux may be powerful enough to run a voice recognition software package, providing hands free access. A subsystem microcontroller would control stuff like LEDs, IO, touchscreen, etc. I'd probably integrate a pseudo-IMU so that motion may be used to do some control, such as a mouse. I might also wire in a glove or something to allow controlled clicking, or move the IMU to the back of the hand there (now there's an idea...)
Depending on size, a LION battery set can be hidden either behind the board or elsewhere (depending on ergonomics and design). Now, final design is that the casing could be made to look rather professional with a vac-formed casing.
Thursday, June 29, 2006
Optical Tracking Idea Update
Well, it's been a while. I was thinking again today about the optical tracking and how to reduce the need for speed. What did I come up with?
Take a CPLD and feed an IR filtered Kodak 580fps B&W camera into it. Use a microcontroller to clock the whole operation (I still think a dsPIC30/33 is a good choice). Within the CPLD, do a comparison on each IR pixel byte to a programed byte threshold fed in from the PIC. If matched or exceeded (whatever is easier), output to a latching port that feeds the dsPIC and trip an interrupt line. By feeding through the line and frame syncs, too, you can setup a signal delay match to the data line. Now, the big idea here is that the PIC keeps count on what pixel should be output (use a Timer module?) and records this and the value whenever the threshold is exceeded.
While a simpler system based around just passing a go/no go signal would work, I'd like to have the imaging data, too. This would allow some filters to be built that adjust the sensor threshold depending on brightness. Another technique could be used to determine if the data recieved is a false response due to reflection, etc. If you're using the ultimate output to just track a beacon like I'd do, you could use moving target filters to keep the area watched small.
The big advantage of this setup over a direct link is that you can significantly reduce the image processing requirements. Another one is that it's still fully possible to do full frame captures without any additional overhead or need to "switch off" a software comparison module.
A disadvantage of this method is that it tosses yet another IC onto a video board I am hoping to keep small.
Take a CPLD and feed an IR filtered Kodak 580fps B&W camera into it. Use a microcontroller to clock the whole operation (I still think a dsPIC30/33 is a good choice). Within the CPLD, do a comparison on each IR pixel byte to a programed byte threshold fed in from the PIC. If matched or exceeded (whatever is easier), output to a latching port that feeds the dsPIC and trip an interrupt line. By feeding through the line and frame syncs, too, you can setup a signal delay match to the data line. Now, the big idea here is that the PIC keeps count on what pixel should be output (use a Timer module?) and records this and the value whenever the threshold is exceeded.
While a simpler system based around just passing a go/no go signal would work, I'd like to have the imaging data, too. This would allow some filters to be built that adjust the sensor threshold depending on brightness. Another technique could be used to determine if the data recieved is a false response due to reflection, etc. If you're using the ultimate output to just track a beacon like I'd do, you could use moving target filters to keep the area watched small.
The big advantage of this setup over a direct link is that you can significantly reduce the image processing requirements. Another one is that it's still fully possible to do full frame captures without any additional overhead or need to "switch off" a software comparison module.
A disadvantage of this method is that it tosses yet another IC onto a video board I am hoping to keep small.
Subscribe to:
Posts (Atom)