Spring Cleaning

I've never liked blogging, probably because I wanted a more free form state, and my mind bounces around a lot. So, I will be doing a bit more. I've recently wandered across some radar stuff, so I expect to do some wiki and blogging about this.

  http://technicalchemy.wikidot.com/

 So, this.... MIT Radar construction PDF

 Lead to those who were making integrated units (still too much for my costs right now). Then we wandered over to look at radar modules, such as this:

  A sample HB100 module (there's hundreds of suppliers) However, they're all single IF output doppler modules. However, the good people of the Ham radio group brings us this information:
 
  Using an HB100 as a radio transciever

 So, we get 3KHz per mV on the input for tuning. Across 1V that's 3MHz of bandwidth. Compared to the 2.4GHz bandwidth of 80MHz, based on the FMCW bandwidth numbers and the 20ms rate, I'd need to run a rate of 1.3 KHZ, 0.75ms to match. so, I'm thinking of making an interface shield/boosterpack/whatever to tie this to a microcontroller board. I need to look into the math more and see what my bit depth and sampling rate need to be, or if I can revert to a computer audio input. At least it won't break the bank.

 Back to work.  I need to update my profile.  Switched jobs three years ago.  Different industry, same projects.

Still around

Well, I have my bamboo hardware for my custom Makerbot sitting in the basement at home. I'm hoping to get to it sometime soon, but I'm in the middle of some major house renovation right now. Patience... Anyway, more to come soon. If the Makerbot bamboo works well, I'll put it up on my Ponoko store for sale. Should clock in under $200 I think.

A simpler rangefinder?

So, ages ago, the Seattle robotics people used an analog video camera and some timing with a peak detector to "read" a laser line's distance. People do this with webcams these days. But their system was one of the first and also low power. So, how could we duplicate this?

Modern digital cameraphone cameras are cheap (see Sparkfun). But they're color. You get 1/4 red, 1/4 blue, and 1/2 green pixels in your image. The color filter is definitely not user serviceable. You can get monochrome imagers, but finding the optics and keeping the cost down is difficult.

Step 1: optimize for your design choices! I'd start with a red line generator from my laser level as a test. However, green line generators (doubling your bandwidth requirements) are available now for $40.

http://www.z-bolt.com/green-laser-line-generator.html

Step 2: design your logic. The idea here is that we'd only clock in the sensor data we're interested in (be it red or green). We'd use a threshold function to trigger if this is "the line". For each trip, we'd want to capture the line number, pixel position in that line at the very least. For more accuracy, we'd want to capture the value that tripped the threshold. This would let us process the average in a program and determine if we're seeing a reflection.

This can be done either in separate programmable logic or in a PSOC3/5. Ideally you'd only have 1 or 2 pixels per line, but reality may change this. For a 1300x1040line camera, for instance, reading a 1 pixel tall line would take (2 bytes for line + 2 bytes for position + 1 byte for threshold) x 1040 = 5200 bytes of RAM, updated at 15Hz. Throughput therefore would be 78KBytes/s or 624kbit/s. I would not be surprised if it was 3-4x more, but synchronous averaging by the cpu should knock the data back down to a reasonable size. Depending on how the averaging works out, most data could be converted to a 5-8 byte per line data calculation (16-32 bit range, 2 byte line indicator, 1-2 byte time indicator), and real time streaming to a host processor via SPI, CAN, or another moderately fast bus is completely possible.

We'd want a 2 line state machine. It would control the timing of the logic depending on which scan line we're in (RG or GB). So this would take in the camera's logic. We'd use the VSYNC to reset all counters. HSYNC would toggle the state machine and increment a line counter. A second pixel counter would be run with the system. We'd need an 8x8 threshold variable.

Return to the Laser Rangefinder: PSoC to the rescue?

Of note, I have done my first soldering on the RepRap electronics. I plan to continue on it tomorrow.

Anyway, I was looking at doing a laser rangefinder again, to see if it's more feasible. I think it is. I found some hardware that can do the signal mixing and generate a 1MHz wave and a 0.98MHz wave to allow for a 2KHz signal sensor. Now, to duplicate the low end (still $2400) laser scanners that have a 1024 point scan over 360 degrees at 10hz. So, if I crank up to 10MHz and 9.98MHz I get a 20khz signal. I can digitze that at about 40MHz, so my smallest theoretical step size is 7.5mm. To do better I either need to mix to a lower frequency and sacrifice update rate, or get a faster counter. I could switch processors to 80MHz instead. That would get me 3.75mm steps.

Now, I was hoping to make this whole thing programmable, so I could test different signals (say from 0.1 to 10MHz). This would require either expensive hardware or a lot of digital potentiometer. I looked at the PSoC originally, and it is what got me looking at how feasible this project is again. The example they had was only mixing a 10KHz and a 9KHz signal in a special way, far below my target frequency. It also took half the analog blocks to do one mix, and I'd need to do two. The CPU was also just not fast enough to replace the fast MCUs I've been looking at.

Then Cypress announced the new PSOC5 series. 80MHz ARM Cortex M8 core. 4 analog blocks that can make a 14MHz bandwidth downmixer with ONE block. 4 matched comparators. 24 digital blocks. CAN. Even USB. Integrated GNU C compiler. I think I might be able to make this work without extensive external parts. A laser driver output, a PIN photodiode and amplifier, and maybe a secondary clock source for assistance mixing. I think I might be able to fit everything else inside. We'll see when I get there.

There's several digital motor control blocks, too. I might be able to combine this chip with a low cost DC motor and encoder and a mirror and mirror the capabilities of that $2400 laser model at a fraction of the cost. And only need one chip for everything.

Reprap electronics order arrives

My order of the Gen3 Reprap electronics arrived. Now I'll have to find the time to build the electronics, but I have to organize and reassemble my work area in the basement first...

Note: Cat not included

The UAVs are coming!

So, I was poking around and ran across DIY drones again. When I first saw the site a year ago, I wasn't too impressed. My opinions have changed drastically. About $200 gets you an add-on autopilot for most small R/C aircraft (Ardupilot). Others have a direct cosine matrix that fuses IMU and GPS signals into a very stable position and attitude estimation of an airframe. More expensive hardware, of course ($400?). I keep seeing daughterboards for these, and this makes me wonder. While it's not ideal, what would happen if you used an IDG 2 axis gyro (x,y) and a more traditional gyro (z) to make a "flat" board? This would greatly reduce any mechanical misalignment or damage, and cut down on the board profile, too.

They're looking for suggestions for an Ardupilot PRO. They want to run dual Arduino CPUs on this. One CPU should be running a fail-safe program, and also an XBEE signal. The second can be running the current Ardupilot software. This would let the user create an XBEE based radio and completely ditch the need for an external standard receiver. I personally would figure out how to put TWO Xbee sockets onboard. One would be running 900MHz (40kbps) and carry critical data and the controller information, while the other would be a 2.4GHz data uplink (250kbps) for anything the Ardupilot or other add-on cards needed to send to a PC. This would allow either a dedicated 900Mhz signal for longer ranged manual control and emergency signalling, or a double failsafe for manual control with extra bandwidth to ride on for the standard 2.4GHz modules. Duplicate this down at the radio and you'd be set.

Technically, using something like Ardupilot shields, you could have one shield providing IMU, GPS, and servo support, and another shield providing transmitter buttons, analog sticks, a display, and an FTDI or other chip based USB uplink to the computer.


IO Type______Aircraft_______Transceiver
Analog_______Gryo/Accel_____Sticks
Digital______Servos (PWM)___Buttons
SPI__________Gyro/Accel_____Display
UART_________GPS____________FTDI USB