Bat Navigator prototype

Hi everyone, it's me, Sirio.

From the last post, I added a third ultrasonic sensor to the project.
The purpose of this sensor is to detect obstacles like tables or chairs, that are too low to be detected by the other two sensors. If an obstacle is detected, then the pitch of the two piezo transducers goes down. At the moment I implemented it as an all-or-none detection, so the user doesn't actually know how high the obstacle is, just that it is there.

I want to change it later so that the new central sensor has its own beeping using the two piezos, so I won't post the code here, as it is just a temporary fix. The reason why I went with a temporary fix is that I actually couldn't wait to build and test the glasses, see if they actually worked, and see how well they worked.

Today I built the glasses.

So, here I present you the Bat Navigator version 0.1!

And here some close-ups of the glasses!

A nice mess

Frontal view, note the Epoxy sustaining the central sensor apparatus

I made some custom connectors using Epoxy and ferrules (i.e. stuff I've found at the local electronics store)

Notice the flexible tube which permits the regulation of the central sensor angle, idea from Valerio Biscione. Flexible tube scavenged from an innocent reading light.

Nice, right?
Me and my friend Valerio tested them out today.

Our testing procedure consisted of the following steps:
- One of us wears the glasses, and closes his eyes.
- The other one spins him around a few times.
- The one who wears the glasses tries to walk around the building without hurting himself.
- The other one makes sure that he succeeds in not dying falling down some stairs
- A third person plays pranks on the one with the eyes closed (essential part of testing)

The Bat Navigator actually works much better than I expected, I was able to navigate the building, even if at a really slow pace. I got the hang of it almost immediately, recognizing walls and their orientation, corridors, and tables. I'm pretty confident that if I keep working on it, it could actually become a feasible way to navigate indoor environments without using eyesight.

It will be a while before I update the blog again, as the next steps will either involve adding another couple of sensors to the side and figure out a way to convey that information without producing information overload for the user, or building a second prototype where everything is mounted on the glasses (so something that can actually be used normally). Both of the options require a good amount of work, and I won't have that kind of time in the near future.
Maybe I will continue working on this from the second half of August, but, until then, I'll have to focus on my central projects :)

In the mean time, I want to thank Ricardo for giving me precious advice on how to go about building this prototype, and Valerio for his many tips, ideas and help in testing the Bat Navigator.

Bye bye now,
I'll keep you posted! (In a while)

Sirio

Let's dance to the sound of piezos

Hi everyone, it's me, Sirio.

As I wrote in the last post, I found out that vibration motors do not have much "expressive power", not as much as I thought anyway. For this reason, I am switching to piezoelectric transducers, which offer a greater range of expression, are easy to control and wire up, and consume almost nothing.

At first, I wanted the piezos to produce a fixed pitch, and vary the volume of the sound as a function of the distance of the obstacles detected by the ultrasound sensors. Turns out, it is not that easy to do so with a piezoelectric transducer, as it would be with a buzzer.

Then I tried to vary the pitch of the produced sounds as a function of the distance of the obstacles, but I didn't like the result. I thought it would be quite annoying to listen to this continuous change of pitch while using the glasses for some time. The good thing is that it worked quite well as a theremin!

(Sorry about the noise, but piezo transducers produce very low sounds)

In the end, I decided to keep volume and pitch fixed, and vary the beeping rhythm, like in parking sensors:

The circuit here is quite simple - the mess you can see in the video is actually just because I was too lazy to tidy everything up. Each ultrasonic sensor is connected to Ground, to the 5V pin, and to a single digital pin (one for each sensor). In fact, with the NewPing library, you can use a single pin to ping the sensor, and to receive the reading.
The piezo transducers were just connected each to a digital pin and to ground. I think I will add some resistance to adjust the volume later on, and maybe a linear potentiometer to control the volume manually.

Now I can guide you through the code I've used here.
I'll explain the key functions and then show the complete code, I'm assuming you already know the basics for C coding.
This is the function which is called continuously as the Arduino is turned on. What it does is:
- Ping the US sensors.
- Average out the last READINGS readings, where READING is a number defined before.
- Shift the distance down of MIN_DISTANCE. This is used so that the piezos can already beep at the highest speed when an obstacle is presented at MIN_DISTANCE.
- Make the piezos beep.
The first and last actions in this list are actually carried out by two functions which are external to the loop. Let's have a look at the function which pings the sensors.


This function pings the sensors one at a time, retrieving the distance for each one. To do that, it makes sure that enough time has passed since the last ping (PING_INTERVAL).
Also, it both the US have been pinged, it updates the reading_n variable. That variable is used in the loop function to populate the reading arrays.

Now for the function that makes the piezos beep.
This function makes the piezo beep more or less frequently depending on the distance of the left and right obstacles.
When the right time interval has passed, the function starts a beep. A beep here is a square wave sent to a piezo for a certain PULSE_DURATION time.

The pitch of the beep sound is controlled by the R and L_BEEP_LOW_RATIO. Given that this function is called by the loop every 1 ms, if for example L_BEEP_LOW_RATIO = 2, then a series of HIGH - LOW - LOW is sent, where each signal lasts a millisecond.
The frequency of the resulting square wave is 1/3 of 1000 Hz (again, because the function is called every millisecond, 1000 times a second).

Finally the complete code, hopefully it should be easy enough now to read through.

OK, that's it for this post, hope you enjoyed it! For the next post, I will probably implement a third sensor to sense low-frontal objects (but I want to use only two piezo transducers).

I'll keep you posted!

Adding the ultrasonic sensor

Hi everyone, it's me, Sirio.

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.

To make things even easier, there's a nice ready-to-use ultrasonic sensor library for Arduino which supports the HC-SR04. Cool!

Here's a video demonstration of the project at this point.

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.

I'll keep you posted!

Nearly burned a pin

Hi everyone, it's me, Sirio.

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.

I'll keep you posted!

Building and testing the motor circuit

Hi everyone, it's me, Sirio.

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.

Here's the implemented circuit:

Top view

Some details

EDIT: there's a mistake in this circuit, see here.

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:

1. The relationship between the Voltage from the 33Ohm resistor and the motor, so that I can figure out what's the motor's resistance.
2. What's happening to the transistor's voltage.
3. 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:

1. the transistor can't deliver more current than the one which is available from the 5V branch
2. 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.

1. The transistor can't deliver more current than the one which is available from the 5V branch.
2. 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!

Enter the circuit

Hi everybody, it's me, Sirio.

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.

Image taken from learning about electronics

In this post, I try to make some of that explicit.

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!

Splat like a bat

Hi everybody, it's me, Sirio.

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-08449 vibration 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.

I'll keep you posted!