Monthly Archives: July 2012

Visual Navigator. Making it MOBILE !

via coolarduino

Obstacle avoiding vehicle, continue in “3D Laser Range Finder” series ( project 1, project 2). The basic idea is the same, measuring distance using red laser pointers, CCD analog camera and Arduino UNO.  Modification was made in geometry.  Two lasers were set for “far field” obstacle detection, few meters in front of vehicle on left or right side. Primary mission is to trigger left / right turn before a car get too close to the “continuous” but not necessarily “high”  object, for example, sidewalk stone. Of course, this distance depends on the vehicle speed, and “alert” should be dispatched in right time “window”, or there would be no space left to making a turn ( proportional speed adaptation is not implemented yet). Low height of such road infrastructure is making useless ultrasound based range finder.


Two additional lasers were set in “cross” configuration, in order to detect any object that comes dangerously close to the front of vehicle. “Near field” obstacle detection or “head on collision” avoidance. Theirs two beams form reflective “trip-wires” and able to detect as narrow object as leg of a chair or desk, open door frame, anything that at least 1 mm wide.  One laser, pointed to the left, is also works as sidewalk / wall follow navigation system, keeping this distance constant.

Now couple words on “autopilot” algorithm. Three main feature of the project:

  1. wall / sidewalk following;
  2. “far field” obstacle avoidance;
  3. “near field” head on collision avoidance.

were classified in 3 priority levels: 1 – warning, 2 – major, 3 – critical.

0 – clear level, corresponds to normal  R/C radio control, or by  ”man / operator”  navigation via  remote R/C module. Operator is also has “authority” to decline warning class navigator status. But it’s not the case when navigator’s “autopilot” subroutine performs class 2 or 3 maneuver, with status “major” and “critical”. When vehicle performs maneuver 2, “left / right” command from R/C remote module are ignored, the same with “forward / backward” command in status “3 – critical”, making algorithm completely “fool – proof”.

More video will be posted, Link to Arduino UNO sketch: Visual_Navigator.

 5 August 2012.

I’d like to publish more pictures from “inside”, which show interface between arduino and R/C receiver module in the car. Well, not quite arduino, I build a “clone” using pre-programmed AtMega328. As you can see, the receiver was left almost intact, what I did, is just identified two on-board H-bridges which supply power to steering control motor and main vehicles motor-driver. Than, remove 4 resistors in series with controls lines, and routed 8 wires to the arduino ( 4 inputs from R/C receiver and 4 outputs to H-bridges ). Here you are, now arduino could intercept any command coming from R/C transmitter, and based on data from the sensors, make a decision if it makes sense to follow them. Also, “autopilot” function could “directly” address two motors in order to execute “obstacle avoiding” maneuver not asking anyone’s permission!.  What more, arduino control a power delivered to motors via software PWM,  making 7! different speed level available like in real vehicle. Unfortunately, the model I “hack” doesn’t use proportional steering control, but still PWM power management helpful to save a battery energy, limiting unnecessary current delivered to motor.


MakerBot Mixtape Kit

via Thingiverse Blog

Rediscover a lost classic – MakerBot a Mixtape!

The MakerBot Mixtape Kit gives you the power to create the ultimate gift. We ship you the electronics, you print the STLs on this page in any of our terrific filament colors and snap the whole thing together!

This project is designed to work with the MakerBot Mixtape Kit, available on our store.

Don’t have a MakerBot yet? Get your hands on a fully assembled MakerBot Mixtape at the link below.

Designed by John Briscella and Matt Kroner

Locked Up

via Thingiverse Blog

Here at MakerBot we believe in the power of making over buying. Imagine a day when you MakerBot your own locks. That day is finally here. As ttsalo says this padlock is, ‘not a joke lock.’ Security disclaimer: while this lock is fully operational please keep in mind it’s made of plastic.

See how it works:

How Much to Invest?

via Nuts and Volts

I have a general rule when it comes to tools, electronics, and accessories: I buy the best that I can afford at the time. There’s nothing more frustrating than having to buy another widget because I didn’t spend the extra dollar to get a feature that I didn’t know I needed. This defensive purchasing sounds simple, but in practice, it’s a difficult rule to follow.

Audio VU meter (AC microVoltmeter) with Extra wide Dynamic Range 69 dB.

via coolarduino

O’K, after having some fun with stereo version of the VU meter I described in my previous blog-post, now it’s time to do a serious stuff. Studio grade VU meter !!! 24 steps, equally spaced every 3 dB, covering Extra wide Dynamic Range from -63  up to  +6 dB.  Single (mono) channel this time, no messing around, absolute precision at the stake. Plus, it keeps absolutely Top-Flat linear frequency response from 40 Hz up to 20 kHz(*).



I’m not going into details of RGB LEDs Display, which has no modification since “Tears of Rainbow” project, only plates installed in one line, form a single GIGANTIC bar-graph. There are some minor changes in mixing colors data tables, but they intuitively understandable.  The most important feature in this project is autoscaling. As you, probably know, Arduino has 10 bits ADC. Only it can’t process negative half-wave, and for this reason it has only 9 bits available for AC measurements.  According to DSP theory, maximum dynamic range is:

DR = 1.77 + 6.02 x B = 1.77 + 6.02 x 9 = 55.95 dB.

 As input audio waveform represents anything but perfect peak-to-peak 5V sine-wave, real dynamic range would be lower. How much? In first, there is a hardware limits.  OPA (NE5532), which is:

  • very low noise !!!
  •  high output-drive capability;
  •  high unity-gain and maximum-output-swing bandwidths;
  •  low distortion;
  •  high slew rate;
  •  input-protection diodes, and output short-circuit protection

 but, unfortunately,  isn’t rail-to-rail type. Test results show, that compression  become noticeable (~1 dB) when not scaled magnitude approaches level about 50 dB. That is in good agreement with observed on oscilloscope not distorted deviation peak-to-peak 2.5 V. Or only half of full range of 5V. And as theory says, half is one bit less, and real DR = 1.77 + 6.02 x 8 = 49.93  (~50 dB). In second, audio data is processed on “block” structure basis. It means, having average of the block 50 dB, doesn’t mean that there was no spikes in the sampling pull, that obviously would be clipped and introduce error in the measurements results.  This phenomenon is defined as Crest Factor. Different sources estimate crest factor of musical content between 10 – 20 dB.  So, taking direct approach, Arduino with OPA mentioned above as front-end could accurately cover only:              50 – 20 = 30 dB.  To get wider dynamic range, I have to scale input amplifier gain, and this is exactly what I did, building amplifier in two stages and selecting one cascade (by-passing second one) or two cascades using internal ADC multiplexer. As there is no switching IC in analog signal path involved, gain is defined with high stability, could be one time precisely measured – calibrated via coefficient stored in EEPROM (nice feature to add).

On the right side there are electrical drawings of “slightly” modified kit,  where stereo amplifier was converted into 2 stage mono version. First stage, with gain about  G1 = 1 + 10 k / 1 k = 11  is necessary to “bump-up” line-level signal, to create DC bias required for correct operation of the ADC, and also served as buffer to lower signal source impedance, as it seen by ADC input.  I set a gain of the second stage amplifier at 40 dB:  20 x Log_10 ( G2 ),     where    G2 = 1 + 100 k / 1 k = 101.

IMHO, setting gain limit for only 30 db per stage as it follows from paragraph above, is overkill, and would be justified for “real-time” radio broadcasting or audio processing for storage media, when high fidelity of audio program must be preserved. For visual display “clipping” of bursts in signal is not noticeable at all due high refresh rate of display, 78 Hz. Human just can’t see, if LED lights-up with such speed.  For steady AC amplitude measurements (micro Voltmeter mode) this is not a problem at all, and headroom as small as 3 dB would be sufficient, leaving wide 47 dB per stage.


  There are two thresholds are defined in program, where switching between one or two stage amplification is happening:

      if ( magn_new <=  44 ) sensitv = 1;

      if ( magn_new >= 47 ) sensitv = 0;

  44 and 47, with hysteresis 3 dB. First line defines switching to high sensitive mode (overall gain 1100), and second line, does exactly opposite. Look at the chart, hope it would save me a million words -);

 Couple words on using this device as precise AC micro-voltmeter. Having 1100 overall amplification as add-up to already quite sensitive Arduino ADC, driving overall sensitivity to enormously  5 / ( 1024 x 1100 ) = 4.439 uV Special care should be taken on grounding, shielding of amplifier PCB, probably, EMI suppressor ferrite chokes wouldn’t be an excess in power line and signal path.   In my project, w/o any modification to original kit’s board (except couple jumper wires to cascade two stage amplifier) of course, I was not expecting to get to such high sensitivity level. Moreover, in project arduino is driving LED display, “ADC noise reduction mode” is off, plus ADC is working on double speed – preselector set to 250 kHz!!!  And this is why constant 14 was subtracted in software from magn_new, just before it goes for BarGraph “mapping” procedure:

      magn_new  -= 14;

Basically 14 is a noise flour of my analog front-end.  Approximately 51 micro volts AC is turning on first LED bar. Look at the table, which reflect my current hardware set-up.

* Other things to keep in mind, there is a “gap” 78 Hz wide in frequency range at 10 kHz,  It introduces a small error, about  78 / 20.000 = 0.39% in white noise measurements result. For musical content, which has really low power density level at 10 kHz, magnitude of error would be much lower, probably, less than 0.05 %.

 Running FFT in code creates great opportunity to reject any interference in the audio band. For example, if there is a noticeable hum from electrical grid lines in the content, issue easily could be fixed NOT including bin[1] in final sum of magnitude calculation. Though to make it works more efficient, some adjustment in sampling period would be necessary, setting bin[1] frequency precisely at 50/60 Hz.

 One more advantage of having FFT based  filtering     (primary mission is HPF, look in stereo VU meter, how long kernel of the FIR filter has to be otherwise), is great opportunity to create “weighting” A, B, C or D curve for audio noise measurements. (:TO DO).

 Link to Download Arduino sketch:  Audio_VU_Meter_Mono_69dB