Sunday, 29 June 2014

In this post I'll show the new circuit from the addition of the ultrasonic sensor, the code I uploaded to the Arduino to drive it, and a video to demonstrate its functioning.

Here is the circuit.

Nothing much going on here, the HC-SR04 needs 5V, so it is connected to the 5V pin, and obviously to ground. The Trig and Echo pins of the sensor are connected directly to two of the digital pins of the Arduino, D11 and D12.

An ultrasonic sensor works like this:

1 - You send a short pulse to trigger the vibration of the transducer. Like ringing a bell.

2 - The sound waves produced by the transducer travel, hit something and are reflected, travelling back to the sensor, and making the transducer vibrate again. For this sensor there are two separate transducers, one for production, one for reception.

3 - The transducer, because of the vibration, produces a current, which is a function of the distance travelled by the sound waves.

4 - Read out that current and, knowing the function f(current)=distance, you have your distance!

The sensor I'm using is quite smart, and instead of returning a continuous current to be read out and processed - the function f(current) = distance is easily nonlinear - it returns a digital signal, where the duration of the high value is linearly proportional to the distance of the sensed obstacle. Which makes things much easier.

And here's the code I used, adapted from the basic example of the New Ping library.

The code is pretty straightforward, there isn't much to explain I guess. The 1.6 value I used to adjust the amount of vibration of the motor was obtained experimentally, by trial and error. It is high enough so that the motor still vibrates when the distance is at the maximum. If a lower value were to be used, then the motor wouldn't receive enough current to start vibrating at distances near the limit.

I'm starting to think that maybe having a vibration motor is not that great an idea. Its expressive range is very limited, as you can listen from the video, the vibration doesn't seem to change much from the nearest distance to the farthest. Also, it consumes a great deal power, which I could use to add more sensors to the glasses.

To explore other options, I bought two piezoelectric transducers, which should need very very little power, and much more control over their vibration is possible.

For the next post, I'll experiment with the piezoelectric tranducers. I think it won't be a circuit post, as a piezoelectric transducer only needs a resistor, and nothing more, as far as I understand. Instead, given that there's more things you can do with a piezoelectric transducer, like controlling amplitude and frequency of vibration, more attention will be given to the code.

Thursday, 26 June 2014

First things first, I have to tell you that I've made a huge mistake in the circuit I showed you last time.

I have something in common with Gob today

Today, as I added the ultrasonic sensor, I decided to measure the entire circuit consumption. It was around 160 mA. Now that just wasn't right, given that I knew the consumption for the motor branch and I knew that the ultrasonic sensor only needs more or less 15mA of current. So I ended up measuring the current from the data pin, noticed that something was very wrong, and spotted my mistake.

This is the way I connected the D3 data pin resistance last time.

This is the way I should have.

In the first image, the resistance is useless, as the bread board pins are connected in rows. The circuit is shorted, and the resistance does practically nothing. Remember that that resistance is needed to avoid burning the data pin, which can handle 40mA current tops. The situation is fixed in the second picture, as the resistance connects two different rows.

I risked burning that data pin.

Now, why didn't I notice that before? Because last time I didn't measure the current in the whole circuit, including the Arduino, but only from the 5V pin to the ground pin. So I was only measuring the current in the motor branch, and I had no information on what was happening in the rest of the circuit.

I decided not to edit the last post and to write a new one instead, as one of the reasons I keep this blog is to document what I learn out of my side projects. Making mistakes is part of learning, and hopefully writing this post will help me avoid doing the same mistake again.

Anyway, as I already told you, I added the ultrasonic sensor to the circuit. I'll soon upload my experiments with it and the code I used to run them.

Monday, 23 June 2014

In the last post I showed the circuit diagram for the vibration motor, and most importantly I tried to actually spell out how and why the circuit is the way it is. Here I will be doing some good ol' fashioned science, and test if the circuit works as I theorized in the last post. I need to do this because I'm not entirely sure that I've got everything right about the circuit.

For example, more than one friend expressed doubts on my statement that the transistor can't draw more current than that's available from the 5V paired with the resistances. The resistances would be the 33Ohm resistance + the resistance opposed by the motor.

The code driving the Arduino while I do the measurements is very simple:

Measurements

First, let's measure the voltage drops across the key nodes in the circuit. I want information on:

The relationship between the Voltage from the 33Ohm resistor and the motor, so that I can figure out what's the motor's resistance.

What's happening to the transistor's voltage.

What happens when I change the duty cycle of the PWM.

So, I am going to measure voltage across the 33Ohm resistor, the motor, and the transistor (and the whole circuit for reference).

Voltage drop in volts, USB powered Arduino

PWM duty cycle

0%

50%

100%

Across 33Ohm resistor

0

1

1.8

Across motor

0

1.4

2.8

Across transistor (collector-emitter)

4.8

2.4

0.03

5V pin to GND (whole circuit)

4.8

4.77

4.7

It seems like the Arduino doesn't deliver the full 5V when attached to my laptop USB port. I was curious to see if that was because of the USB power or that was just the voltage that the Arduino could deliver independently from the power source. For this reason, I repeated the measurements powering the Arduino with a battery.

Voltage drop in volts, Arduino powered by four 1.5V batteries

PWM duty cycle

0%

50%

100%

Across 33Ohm resistor

0

1

1.9

Across motor

0

1.4

2.9

Across transistor (collector-emitter)

4.96

2.4

0.04

5V pin to GND (whole circuit)

4.96

4.94

4.91

So it seems like that when my Arduino is powered via USB, it doesn't deliver the full 5V from the 5V pin. It gets very close when it is powered by four 1.5V batteries.

Now, I want to know how much current is flowing through the circuit when I change the PWM duty cycle. This way I can test my hypotheses that:

the transistor can't deliver more current than the one which is available from the 5V branch

I can't use the full range of the PWM duty cycles, as if the transistor is multiplying by 100 its base current, then once reached a certain duty cycle, there will be not enough current from the 5V branch to satisfy the multiplication, and from that duty cycle on the current will just be the maximum current.

Here the results.

Current in milliampere (same for USB powered and battery).

PWM duty cycle

0%

50%

100%

Current in mA

0

28

56

Discussion of the measurements

First, let's discuss the voltage drops.

From the measurements it seems that the voltage drop across the motor is more or less 1/2 more than that across the 33Ohm resistance. That means that the motor resistance is more or less 50Ohm. Which is quite far from the 75Ohm terminal resistance stated in the datasheet. So, either the terminal resistance is not what I think it is, or other factors are in play in determining the resistance of the motor.

Another surprise from the measurements is that I didn't think about the resistance in the transistor when calculating the voltage drops in the circuit in the last post. What I discovered is that the transistor acts like a variable resistor.

Now for my hypotheses in the last post. Let's repeat them for clarity.

The transistor can't deliver more current than the one which is available from the 5V branch.

I can't use the full range of the PWM duty cycles, as if the transistor is multiplying by 100 its base current, then once reached a certain duty cycle, there will be not enough current from the 5V branch to satisfy the multiplication, and from that duty cycle on the current will just be the maximum current.

The 1st hypothesis is supported by observation, while the 2nd turns out to be false.
While it seems it is true that the transistor can't draw more current than what's available from the 5V branch, apparently the whole range of duty cycles can be used to modulate the current flowing through the Collector-Emitter. A 100% duty cycle lets more or less all the available current flow, whereas a 50% duty cycle lets half of it flow. I'm not sure why this is, I'll have to read more on transistors.
By the way, to collect more evidence on the fact that the transistor can't let more current than the one that's available from the 5V branch, I repeated the measurements without the motor, so that the only resistances in the 5V branch were the 33Ohm resistor and the transistor. As expected, with 100% duty cycle, the transistor just lets all the available current through (and not more).

In the next post, I'll plug the ultrasonic sensor in and I'll experiment a bit with it, showing you some code in the meantime.
I'll keep you posted!

Friday, 20 June 2014

In this post I'll walk you through the circuit I'll use for my ultrasonic navigation device introduced here.

The most important part of the circuit is that relative to the motor. In fact connecting the ultrasonic sensor to the Arduino is absolutely trivial, all connections are direct.

I am being heavily inspired by this page for the design of the circuit, given that I am completely new to electronics. But the article assumes that the reader has already a basic understanding of what's going on, so that many details are left out about the working of the circuit, and why certain choices are made.

A little warning: my knowledge of electronics entirely comes from my trying to reverse-engineer that circuit, and actually stops there. So there could be any number of errors and/or inaccuracies in this post. If you know your way around electronics, please correct me if I'm wrong. If you don't, take everything that follows with a grain of salt.

OK, let's begin.

Delivering the right current and voltage to the motor

We want to drive the vibration motor. We want not only to make it vibrate, but also to control its vibration. We need to deliver to the motor a maximum of 75 mA. The Arduino 5V pin can deliver current in that range no problem, but we would have no control on its modulation via programming. The motor would just vibrate continuously as long as the Arduino was connected to a battery. We do have control on the data pins, but they can only deliver a maximum of 40 mA, meaning that getting around that value you actually start damaging your board. It is much wiser not to let this pin directly deliver the needed current to the motor. So, how to deliver the current and still retain control over the motor's vibration?
The answer is: with a transistor.

The way I think about the transistor is a pipe with a door in it, that can be opened or closed, and everything in between. You can vary the amount of current flowing through the pipe by controlling the door. To control the door it takes another source of current, but if you spend x current to open the door, the amount of current flowing through the pipe can be up to 50-100 times x (for the transistor I'll be using).
A transistor has three pins, called Collector, Emitter and Base. The pipe is the passage from the Emitter to the Collector pin, and the door is controlled by the Base pin.
Our data pin can really make good use of a transistor. In fact, the data pin can drive with very little current the door in the transistor, and so control with it a great amount of current (up to 50-100 times) flowing through the Collector-Emitter pipe. This current will come from the 5V pin paired with an appropriate resistor, whereas the door-driving current will come from a data pin and its resistor. Remember that you need a voltage and a resistance to make a current.

Now with some easy mathematics we can figure out the resistors we need for the 5V pin and the data pin so that the motor gets the right amount of controllable current. Also, as the motor needs a voltage of maximum 3.8V, we have to choose our resistor at the 5V pin accordingly. In fact, when resistors are in series, a voltage drop happens across each resistor depending on the contribution of each resistor to the overall resistance. The motor is a 75Ohm resistor. In the tutorial I linked at the beginning of the post, a 33Ohm resistor is used at the 5V pin. Doing the calculations, a 33Ohm resistor would drop the Voltage to more or less 3.5V, which is in the motor range, and together with the motor resistance would cause a current of 5V/(33+108)Ohm = 46mA more or less. Which is below the rated current for the motor. Neat.

Now for the data pin. I am going to use a 5000Ohm resistor here, and I'll explain the reason in a moment.
We will be using Pulse Width Modulation at the data pin. I won't give you the details, but thanks to the PWM we can simulate an analog signal, and we can modulate the voltage from the pin by manipulating the PWM duty cycle. So for example, with a duty cycle of 10%, we would have a voltage of 5V*10%= 0.5V, which divided by the data pin resistance would give a 0.1 mA of current to the Base pin of the transistor. It's clear that by changing the duty cycle percentages we can modify the amount of current going to the Base pin of the transistor, and thus the amount of current flowing through the Collector-Emitter pins in the transistor, and thus the amount of current flowing through the motor. In case of a 100% duty cycle, we would have observed more or less 1 mA*100= 100mA of current to the motor, if that current was available. In reality, as we calculated before, there are only 46mA available from the 5V pin branch. This means that that's the maximum current we can deliver. It also means that our range of usable duty cycles will be from 0% to 46%, as going further than that we are just going to deliver 46mA top, whatever duty cycle we choose.

Making sure that the motor doesn't destroy our Arduino
Thanks to the back-electromotive force, or back-emf, the motor would be able to fry our Arduino every time a sufficiently sudden decrease in current to the motor happened. Like every time we ceased feeding current to it to stop its vibration. But we can prevent that using a diode. A reverse biased diode in parallel doesn't conduct current when the current is flowing in the correct direction. Normally, it is like it's not even there. But if the motor produces an inverse voltage and sends current back, the diode will short-circuit it so that the current doesn't reach the Arduino from the wrong way.
Also, the motor can produce high frequency electrical noise that can affect the functioning of other electronics component. To prevent that we can use a small capacitor, which filters out the high frequency noise. That's the reason for the 0.1 microFarads capacitor.

Conclusion

Once we have the motor circuit, figuring out the rest is easy. In the complete circuit for this project, the motor circuit is doubled as we have two motors, and the connections to the ultrasonic sensors are to be added. One motor circuit draws more or less 50mA, 5V/(33+75)Ohm, and one ultrasonic sensor needs 15mA. Summing up, the Arduino will have to deliver 50*2 + 15*2 = 130mA, which is well below the limit of 400-500 mA that the Arduino can deliver.

In the next post I will actually implement the circuit, and program the Arduino.
I'll keep you posted!

Sunday, 8 June 2014

Ok, this will be the first project I'll document on this blog. It will involve some electronics and an Arduino. As I am not familiar with electronics nor Arduino, I'm starting simple.

The plan is basically to have a couple of ultrasound sensors and a couple of vibration motors attached to the right and the left side of some glasses, so that when an ultrasound sensor perceives an object closer than a certain distance, the relative vibration motor start vibrating to alert the user of the incoming obstacle. If the left ultrasound sensor perceives an obstacle, the left motor vibrates and vice-versa. The nearer the obstacle, the stronger the vibration. So, yeah, I'm trying to implement some kind of very rudimentary echolocation, with a blind user in mind.

Maybe it will work well enough to actually be useful for navigation when sight is not an option, but most probably it will just be a nice toy to tinker with. Either way I will be pleased.

In the picture you can see some of the components that will be part of the object I want to build:

- an Arduino Nano

- two HC-SR04 ultrasonic sensors

- two ROB-08449vibration motors from Sparkfun

I decided to use the Arduino Nano as it is as powerful as a full-fledged Arduino, but... smaller.

As space here is an issue, I could have gone smaller by using other microcontrollers, doing without the usb port for example, or most of the pins. But for the moment I just prefer the ease of use and flexibility of the Nano. Maybe I'll consider using something else for the final version.

The HC-SR04 sensors have a fair range (from 2 cm to 4 meters) and good-enough precision. Also, they are really cheap. Another option could be that of using optical sensors as they don't have some of the downsides of ultrasonic ones. Ultrasonic sensors for example do not deal very well with sound-absorbing materials. On the other hand, optical sensors can fail to detect glass and dark coloured surfaces. Orientation matters as well, in both cases. So a good idea for later could be that of integrating the two modalities. But for the moment I'll just stick with the ultrasonic sensors.

The ROB-08449 vibration motors are cheap and small, and that's pretty much all I need them to be. I just hope their vibration won't be too strong, as they will be positioned near the head, and it could easily get annoying.

In the next post, I'll either show some code or the circuit I'll use, so stay in touch if you want to know more.

Friday, 6 June 2014

This blog is the place where I'll dump my thoughts and progresses relative to the side projects I'll start.

I decided to open it for three main reasons.

First of all I hope it will help me FINISH the side projects I'll start. I tend to get sidetracked quite a lot, as I get interested in random stuff very easily. I don't follow up that easily though, and I want to change that.

Second, I am quite sloppy sometimes when I work on my projects, as I want to have something working as soon as possible, and for this reason I often don't put much effort into understanding the details of what I'm doing. This happens a lot when I'm coding, for example. And I often end up with ugly code that I won't be able to reuse. Or understand two weeks later. Or explain to someone else. In this blog I'll write having in mind a curious and inquisitive friend that wants to grok fully what I'm doing. I think that will make me want to understand the details myself, as I certainly don't want to bullshit an imaginary but still very dear friend.

Third, I owe you, the internet, big time for most of my informal education, so I'll try and give back something. Not saying it will be great stuff but, hey, I'll do my best.

I'll keep you posted!

*This persimmon is keeping me company today while I wait for the results of a long simulation I'm running. I spent some time playing with it in Photoshop, as I liked its colors. I guess it is a good enough symbol of my getting sidetracked - plus, it is really tasty.