Saturday, May 21, 2005
Thought Experiment: HUD
I happen to have some specially cut but scratched HUD glass sitting around here. Not to useful due to the scratches, but a good thought provoker. One common way to get a HUD working is to have a well backlit LCD or CRT at right angles to the glass. Problem? Size, you have to accomodate the entire LCD, which may be 2.7" or even 3.8" in common sizes. You can get color raster graphics then, but that's more distracting that I want. I'll just slide an LCD with focusing optics over my eye if I need that type of display. Professional units appear to use very VERY small monocrome LCDs with a high output backlight to provide such detail. Unfortunately, 320x240 or more preferrably VGA monitors of this size are expensive. A broken modern DV camcorder may be a better cheaper option off of Ebay for oneshot designs.
I happened upon the old Nintendo Virtual Boy a while ago. It cycled a 224 light LED bar in conjunction with a mirror. This provided vector graphics (in stereo) at 324 x 224? at 50Hz. It was disorienting to use, but I figure something similar providing "infinite depth of field" guide lines for highlighting and information providing would be better, especially since you can see out of the unit. Problem? I'd want 240 LED's. That's a LOT of space I'd have to fill in. Another issue is the complex circuitry. I'd need a high pinout FPGA to drive the LED's. I'd probably use a rotating octal mirror to provide scan lines instead of a vibrating mirror. This also gives the option of overlaying and syncing multiple color bars to provide RGB color graphics as cost permits.
I briefly considered a single LED with driven X-Y galvatrons (ala laser lightshow graphics) but those are highly limited in their flexibility and cost a bit. Also that would put vibration sensitive mechanisms on a mobile platform. I much prefer the spinning mirror of above since that only has to maintain speed and have an optical encoder onboard to provide timing characteristics.
Anyone else have any ideas? I'm looking for lightweight, low cost solutions. Camcorder eyepieces are a good option, but many of the older models I'd sacrifice use miniature CRT tubes. I do NOT want several kvolts on my head. Ebay Camcorder finding is very hit and miss, especially since I'd need two identical digital units to build each eye of the HMD.
Friday, May 20, 2005
CAN Module status update
Found a few nice things over at the Electronic Goldmine website. They reminded me that I have a 2.7" diagonal Sony LCD (240x160, 512 color) that would make a good forray into HMD/monocle design for very little, if I can design a good driver for it (I see dsPICs in my future). Other than a 9 bit interface, it'd be a bit hard to control without 38400x9bit memory... so I think driving this with dual port RAM and a CPLD front end might be the best bet for me. We will see.
They also have a 16 grayscale 320x240 touchscreen that would be a good match for a forearm mounted control system.
Monday, May 02, 2005
CANMOD - A CANbus module system
- Zigbee and digital I/O
- Generic I/O with breakouts for specific interfaces (parrallel, UART, SPI, R/C?, Analog input)
- Brushed motor and R/C servos
- Brushless motor
- Audio I/O
- Video Input/analysis
- Video output/LCD
- High computation module (if needed)
Now, serial bus connections will be available for the basics. Some will just be a single digital connection. Many will be on several inches of dongle bundle so they may be separated from the controllers.
- I/R input
- I/R output
- IRDA transciever (UART)
- Flash config module (I2C)
- Button/slider input
- Single event touch sensors
- Accelerometer 3 axis?
These should allow me to build anything from small to midsize robots to high performance R/C vehicles (still need more range for aircraft, though) to Laser Tag systems
Friday, March 25, 2005
TAG2020 Evolution
I've been considering the TAG2020 system.
We're looking at major reuseable software components of:
- IR TX
- IR RX
- LED muzzleflash
- LED hit signaling
- CANbus
- 802.15.4
Uses of the above:
- Hit tracking
- Weapons fire
- Intelligent weapon linking to user
- Remote intrusion sensors
- Squad Area Network
The 2020 weapon is being redefined. We're reconfiguring them into several major parts.
- IR LED Transmitter: CAN equipped microcontroller that's dedicated to IR transmission
- Gun controller: Most likely also the IR LED Transmitter, manages the CAN network, integrated 802.15.4 transciever for linking to the larger network. May have an LCD and buttons or headers for low cost triggers and readouts. May also have a hot-swappable "side ID" for games that use user removeable modules to allow changing of sides.
- Trigger module: Each trigger module is CAN networked to the Gun controller on a common bus. This allows multiple weapons to use one transmitter. Weapon types may be ordered by priority. The trigger module may be used as a weapon type controller to allow modular reconfiguration on the fly.
- Reload bay: CAN networked bay that controls ammo feed. Has optocoupled links to ammo clips as used.
2020 Hit Sensors will either have CAN or CAN and 802.15.4. They will use the same substrate, just varying in equipped parts to allow for mass production. Bus power may be provided to reduce battery numbers.
2020 intrusion sensors will share a standard 802.15.4 interface. This may be merged with the Hit Sensor board and have specific sensors (acceleration, tripwire, etc) added on via daughterboard connection. CAN may be provided as an alternate long range option (at 20kbps 1km range)
2020 Base packs will be made to communicate with 2020 LCD/UI units. The LCD/UI units will be mostly dumb, acting as a detached wired/wireless link to the Base pack. Standard Base pack options:
- Player ID
- Statistics tracking
- 802.15.4 controller master
- Hit sensor location tracking (for "realistic damage" games)
- Automatic configuration
- Basic hit detection (extra sensors not needed to play)
- Expansion slots/headers (bussed?)
Basic game setup will be:
- 1 gun (1x IR Transmitter, 1x Gun Module, 1x Trigger, 1x reload bay)
- 1 Base pack (backpack, rear hit detection)
- 1 LCD/UI module
- 2 hit sensors (front torso hit detection), CAN interface.
Optional future Base pack modules:
- DSP voice command
- compressed digital voice communication
- GPS/IMU position tracking
- 900MHz long range datalink
- Camera tracking and targetting (shoulder mounted)
Saturday, March 19, 2005
Modular Parts
In the little time that I actually code and test the RC core, I've come up with a list of modules that it's running.
- A to D conversion with reading to output transform
- R/C servo control
- 2.4GHZ transciever
- Brushed Motor Control
- CAN network
Now, as I look at the MilesTAG2020 system, I have these modules:
- A to D conversion
- IR encoding
- IR decoding
- 2.4GHz Zigbee transciever
- CAN Network
- Brushed motor control (feedback, cyclic operation)
- R/C servo control (turrets, drive motors)
- Human Interface design (LCD menus)
Although not initially intended to be used together, the RC core will become a stepping stone for the MILES2020 system. I suspect I might make a few target drones and recon UGV's eventually, maybe even put a turret on a UAV.
Now, I need a name that isn't TM the MilesTAG guys, but relates to being compatible...
Friday, March 11, 2005
Yet more projects?
http://www.lasertagparts.com/mtdesign.htm
I'm thinking of breadboarding their basic circuits for a little fun, then going for a high tech Zigbee upgrade. Every player would have a gun, a backpack, a helmet/hat, and a few other sensors. Many sensors would just be a Zigbee unit, LED's, an IR sensor, and a PIC for logic control. The gun would be similar to the designs above. The backpack would be used for radios and some high tech gadgets. The helmet may have a comm headset, but would otherwise be there for protection/team identification.
I'm considering giving it a larger LCD (2x16?) and using capacitive switches for user interface, keeping the box sealed and possibly a bit more watertight.
For another trick, a serial bidirectional optocoupled box would be used for a magazine. A simple pulse request for one round of ammo would be flashed to the box, it would respond with a pulse if it has one. I'd either put a battery inside with a switch to restart it, or use a very low speed loop wireless system to reset (like 125KHz). There would be microswitches to turn on/off the interface. If field reloads are possible, timing lockouts and a reload field back at base would be used. This would keep people from sitting in the reload area with infinite ammo. The interface itself would be small and universal, the changes in the box would be different for different weapons.
Hmmm... more later....