Jack Crossfire's blog View Details
Archive for August, 2015

# Fast running & fast driving

Posted by Jack Crossfire | Aug 25, 2015 @ 01:37 AM | 4,066 Views
 Running at 10mph (11 min 49 sec)

6 * 200m downhill intervals at 10mph
2 * 400m uphill intervals at 8.5mph
1 * 400m uphill interval at 8mph
Had to slow down due to nausea.

Steering gets real hard at 10mph. That's almost twice the cruising speed. Lately gave more thought to horizon detection & using only that for optical flow.

# Convnet fails

Posted by Jack Crossfire | Aug 22, 2015 @ 06:51 PM | 4,282 Views
The problem with convnets is they only work as classifiers, not position detectors. There are examples of another algorithm being used to find feature positions, then the convnet being used to identify the features. Even then, there was an example of road sign detection which was a lot worse than least squared differences.

The driving algorithm does pretty well finding the car's position in time, but falls over when looking for the path offset in the frame. Even 2 drives at the same time of day can't be aligned because the shadows changed slightly.

There was an idea of using a convnet as an expensive replacement for the least squared difference calculator. Use it to classify an image offset at multiple points. Pick the position which gives the best match. Convnets are supposed to be position independent, so they wouldn't work in this test.

Another idea is using a convnet to classify a material as path or not path. This might be more feasible. For every frame on a drive, a new set of weights for the kernel is calculated. The kernel could be passed over an unknown image, creating an output mask based on the material. The resolution might be too poor. The camera resolution isn't high enough to give much difference between materials.

Materials classification leads to the idea of horizon detection. The horizon is more invariant than the nearby path, so using just that or masking everything below it might give better optical flow. A variance calculation of each line might yield the horizon or it might be discernable for a convnet.

# Convolutional neural networks

Posted by Jack Crossfire | Aug 19, 2015 @ 12:51 AM | 4,762 Views
 Making Robots (1 hr 3 min 58 sec)

Good coverage of current topics in robotics. Most interesting was the lack of any work being done on flying machines. 5 years ago, Vicon guided quad copters were the only topic. Now, they're all gone.

The speed & strength of modern actuators compared to years ago. The gas driven hydrolic actuators driving Boston Dynamics creations are a lot faster than construction equipment. The electrically driven hydrolic actuators were amazingly strong for their speed. Much has been done to get powerful hydrolic pumps & valves from brushless motors. We're not far from lifelike human motion, but the problem of safety is going to keep any robot as strong & fast as a human from going near any human.

A way to make a robot aware of when it could break something must be found before it can interact with a human. There was some promise in robotic ability to sense resistance, but it has to know which way a joint can bend.

The mane find was a blurb about convolutional neural networks. They became prominent only after 2012. In 2008, I became disillusioned with neural networks because to truly become learning machines rather than expensive lookup tables, they needed to be recurrent. There was no easy way to train a recurrent network or model a pilot in a neural network. Lookup tables would do a better job.

Convolutional neural networks seem to be purely used in image recognition. The fundamental unit of the convnet is the convolutional kernel, a fixed matrix which is multiplied by every region of an image to produce blurring, edge detection, & sharpening.

Now, they apply several kernels with different parameters on the entire area of the same image. The different parameters of each kernel are trained using backpropagation. The output of an image which has been processed with these kernels can be fed into another set of kernels to process higher level features. Fortunately, there are already libraries which implement all this.

# More machine vision tests

Posted by Jack Crossfire | Aug 13, 2015 @ 11:13 PM | 4,357 Views
The quest for machine vision moved to optimization, because it most likely will have to run on the 900Mhz Raspberry in a 1st test.

A quick test at 160x120 showed complete loss of synchronization at the lower resolution, with different lighting. There was definitely an advantage to 640x480 & above, with the bare minimum at 320x240. Using color for matching was hopeless, whether the color was 160x120 or 320x240. Color was required for decent motion searching. The optimum source image was 640x480, with downsampling to 320x240 for all processing, & further downsampling to 160x120 for the 1st pass of motion searching.

Synchronization of any kind between 2 videos during the shady time of day was impossible. The shadows changed position too much. Synchronization between a shady video & a full daylight video was still quite good, though optical flow was hopeless. Since the full daylight video had some compatibility with all the other videos, all the reference videos should be in full daylight. FLANN pair matching was identical but much slower than brute force matching.

Another drive slightly after full daylight but not sunset was pretty awful at optical flow, though it nailed keypoint matching. Reduced the reference frame window to 10 & reduced the reference frame rate to 1 frame every second. This didn't affect the keypoint matching.

Made a logarithmic motion search use a 2x downsampled image, which gave better results than either...Continue Reading

# Clockcycles to burn

Posted by Jack Crossfire | Aug 09, 2015 @ 12:59 PM | 4,780 Views
The rumors that computer vision takes enormous amounts of clockcyles have proven true. Last week's theory that matching homography of keypoints would yield the most similar frames was absolutely wrong. The best match was revealed by the frames with simply the highest number of matched keypoints.

Next came detecting the optical flow of the matched frames. There was computing the average position change of the matched keypoints. This was terribly rough. The keypoints were terribly mismatched.

Better results came by old fashioned macroblock searches. It might be faster to apply the Lucas Kanade method to the keypoints, but the brute force method proved the feasibility.

Not sure Lucas Kanade would handle the large differences in position between the 2 frames. The objects don't move incrementally, but occupy totally different parts of the image & don't match well enough for feature matching to produce any points to track.

The optical flow got better when the search for best macroblock was exhaustive instead of logarithmic. Narrow objects like poles got missed in a logarithmic search. It got even better when the motion search used full color instead of greyscale. But using full color instead of greyscale for the keypoint matching actually made it worse.

 Synchronizing video using SURF (4 min 59 sec)

A nifty video of the current & reference videos being synchronized by feature point matching but not optical flow emerged.

Drove another 6 miles, recording several drives of the same section of test track in smokey conditions. The battery can't go any farther. An SD card glitch caused the recording to stop. The web server was still running, but showed a 404 error, a sign the filesystem was gone. The lighting change did make a few more frames glitch, but it was still pretty good for no color correction. Color correction will add still more clockcycles.

The video had to be downscaled to 320x240 to get any reasonable processing speed. This didn't seem to degrade the results.

# 90mV per mA on the uCurrent

Posted by Jack Crossfire | Aug 06, 2015 @ 11:10 PM | 4,911 Views
The day job had no useful resistors for measuring current, so tried to add a 10mV/mA range by doing this.

Trimmed it to nearly 0.1R, but the result was a very noisy waveform which spilled noise into the other ranges. The wire was an antenna. The day job had a 1R 5%, so whacked that in. It was still noisy. Left the 10k tacked on the end of it & it acted like another antenna. Removed the 10k completely, which gave a useful but still noisy signal. The 0805 10R wasn't a perfect fit for the 10k position. Fortunately, the day job has many 0402 10R's.

The result was 1mV/1uA, 90mV/1mA, or 0.99mV/1mA, very useful ranges for measuring the coveted 2ma-10mA range. The full range was 0mA-20mA. The oscilloscope seemed to have been doing better with 90mV than 9mV & it skewed the other ranges less. Could finally see how much an interrupt handler was using.

Also, the switches started interrupting the circuit with more usage, so had to go into SHORT mode to change ranges. There was now little point in dual contact switches with all the problems of requiring parallel resistors & not being able to have more ranges. It's something Dave probably couldn't foresee. Fortunately the OFF mode still passes current while not powering the LED, so you needn't drain the battery to keep the DUT going.

After much testing, the mane advantages are changing ranges without interrupting the circuit & plotting transients. The mane limitations are lack of ranges...Continue Reading

# uCurrent mods

Posted by Jack Crossfire | Aug 06, 2015 @ 01:36 AM | 4,630 Views
Reviewing the schematic for the uCurrent, the key to its ability to change settings without interrupting the circuit is switches with 2 contact points. The resistor network is always in the circuit path. Only the SHORT option gives the current a shorter path, so avoiding accidentally switching to nA requires being in SHORT mode.

The sacrifice in using dual contact switches is 2 resistors always have to be in parallel. Working around that requires the ranges to be powers of 1000. The resistances have to be in ascending order & all 3 resistors have to be populated. The output of each resistor is always amplified by 100x using the same amplifier chain.

It really is a bit of slight of hand that lets the uCurrent work the way it does. It was one of those unique inventions born from a once in a lifetime observation developed over a lifetime of experience.

The easiest way to get the coveted 2mA-10mA range is replacing the 10R with 0.1R & replacing the 10k with the 10R. This would create a new 10mA range with 9.9mV per mA. The mA range would then give 0.9mV per mA & the uA range would still give 1mV per uA. It might be good enough, but hard to read in the 10mA range.

Unfortunately, the 0.01R resistor can't be trimmed to get 1mV per mA again. It's a special resistor with sense terminals on the substrate.

# The amazing uCurrent

Posted by Jack Crossfire | Aug 05, 2015 @ 01:02 AM | 4,912 Views

A nice bit of kit arrived at the day job. Modern gadgets live & die by their power management firmware. It's not like the old days when a power switch was the final word in whether the batteries drained or lived. Now, the typical gadget has a full power mode, low power mode, off mode, charging mode, all controlled by software with no direct user control. If the software doesn't work, the gadget bricks with no way out for the user.

Many a gadget has been instantly wiped off the face of the Earth because it didn't turn off properly, killing its batteries, or didn't turn on. History is littered with Gopro's draining their batteries in standby mode, iPad's going dark & never turning on again, Lipo's drained past their self destruct point or overcharged.

Keeping the day job gadget from becoming a statistic consumed a lot of testing. The mane problem was measuring current through the gadget's full range of hundreds of mA to tens of uA. The traditional "mowti"meter couldn't do it without shutting down to change ranges & faking the battery voltage with a bench supply set 2V higher than the battery voltage. Burden voltage was a big issue. There was no way to test transitions into charging mode with the bench supply.

As simple as it is, the uCurrent was the easiest way to do the job. It was a lot more reasonable than picking out the right resistors, op-amps, & switches, building up a circuit to test current ourselves. The...Continue Reading

# 6.35 mile RC truck drive

Posted by Jack Crossfire | Aug 02, 2015 @ 11:13 PM | 5,123 Views

Swapped all the steering buttons after 1 had been seriously degraded for a while & they were all quite corroded. Looks like swapping buttons is going to be a standard routine in a sweaty environment. Moved the low speed steering closer together to aid in tactile movement. The corroded ones were 25 years old. Surprisingly little progress in tact buttons was made in the last 25 years, compared to the progress made after 1960.

# 6.5 mile RC car drive

Posted by Jack Crossfire | Aug 02, 2015 @ 06:06 PM | 4,889 Views
A test of SURF image matching with different focal lengths & lighting was a complete failure.

So did 4 x 8 minute miles on the same section of track, gathering 2 runs in both directions, in equivalent lighting & focal length, high quality JPEG. Wanted to do more repeats, but sunburning became an issue for the human.

The old raspberry pi was still putting out 10fps. Gave up trying to configure it over wifi. The USB port has enough power for a webcam & wifi.

The picture quality was still awful. Stepping up the saturation revealed it was probably using an analog NTSC signal in 1 stage. The proprietary Logitec chip still takes in a digital signal.