Posts with «ultrasonic sensor» label

Prextron CHAIN BLOCKS - Arduino Nano controlled Ultrasonic sensor that switches a motor wirelessly using 433MHz RF modules and a relay board.



In this tutorial, I will be evaluating Prextron CHAIN blocks – a new system that allows you to connect your sensors and actuators to an Arduino NANO using clever 3D-printed prototyping boards that can be stacked sideways. This very modular system makes it easy to connect, disconnect and replace project components, and eliminate the “rats nest of wires” common to many advanced Arduino projects. CHAIN BLOCKS are open, which means that you can incorporate any of your sensors or actuators to these prototyping boards, and you can decide which specific pin on Arduino you plan to use. The CHAIN BLOCK connections prevent or reduce common connection mistakes, which make them ideal for class-room projects and learning activities.

I am going to set up a project to put these CHAIN BLOCKs to the test:
When I place my hand in-front of an Ultrasonic sensor, the Arduino will transmit a signal wirelessly to another Arduino, and consequently turn on a motor.


Parts Required:

You need the following Prextron Chain Blocks

Please note: You may need to solder the module wires to the CHAIN BLOCK protoboard.


Arduino Libraries and IDE

This project does not use any libraries. However, you will need to upload Arduino code to the Arduino. For this you will need the Arduino IDE which can be obtained from the official Arduino website:


ARDUINO CODE: RF Transmitter




Fritzing diagrams for Transmitter






Fritzing diagrams for Receiver





Concluding comments

The purpose of this project was to evaluate Prextron CHAIN BLOCKs and put them to the test. Here is what I thought of CHAIN BLOCKS at the time of evaluation. Some of my points mentioned below may no longer apply to the current product. It may have evolved / improved since then. So please take that into consideration


What I liked about Chain Blocks

  • The design is simple, the product is simple.
  • Once the Chain Blocks were all assembled, they were very easy to connect to each other.
  • I can really see the benefit of Chain Blocks in a teaching environment, because it simplifies the connection process, and reduces connection mixups.
  • It was good to see that the blocks come in different colours, which means that you can set up different colour schemes for different types of modules.
  • You can incorporate pretty much any sensor or Actuator into the Chain block which is very appealing.
  • You also have the flexibility of choosing which pins you plan to use on the Arduino.
  • Projects look a lot neater, because you no longer have the rats nest of wires.
  • The Blocks lock into each other which means that they are much easier to transport/carry.


What I did not like about Chain Blocks

  • In most cases, the Chain Block protoboard lanes were not numbered, which increased the chances of making mistakes when soldering
  • The need to solder modules to the protoboard, may be a discouragement for some people.
  • I would have liked a choice of different size Chain blocks. Some of the sensors did not fit nicely into the Square blocks.
  • Prextron really need to work on their website if they plan to get serious with this product: Webpage has incomplete functionality or irrelevant links etc etc.


Thank you very much to Prextron for providing the CHAIN BLOCKS used in this tutorial, and allowing me to try out their product. If you are interested in trying them yourself, then make sure to visit them at:

If you like this page, please do me a favour and show your appreciation :

Visit my ArduinoBasics Google + page.
Follow me on Twitter by looking for ScottC @ArduinoBasics.
I can also be found on Pinterest and Instagram.
Have a look at my videos on my YouTube channel.


Blackboard digitization for under $40

Digital White/Black Boards or “Smart Boards” are very useful in modern classrooms, but their high cost often makes it difficult to convince administrators from loosening their purse strings. Cooper Union’s 2nd annual HackCooper event in New York wanted students to design and build hardware and software projects that both solve real problems and spark the imagination. At the 24 hour hackathon, the team of [harrison], [david] and [caleb] decided to put together a low-cost and simple solution to digitizing classroom black board content.

A chalk-holder is attached to two strings, each connected over a pulley to a weight. The weights slide inside PVC pipes at the two sides of the black board. Ultrasonic sensors at the bottom of each tube measure the distance to the weights. The weights sit in static equilibrium, so they serve the purpose of keeping the string taut without negatively interfering with the writer.

With a couple of calibration points to measure the extent of displacement of each weight, board width can be determined, making it easy to adapt to different sizes of boards. Once calibrated, the system can determine position of the chalk over the board based on some trigonometrical calculations. Since they had just 24 hours to hack the system together, they had to use a hand operated radio with a couple of buttons to provide user control. Pressing the “Write” button starts transmitting chalk movements to the digital screen. A second button on the radio remote serves to “Erase” the digital screen. After receiving the chalk position data, they had to do a fair amount of processing to eliminate noise and smooth out the writing on the digital screen.

A server allows the whole class to receive the chalk board data in real time. After each “Erase” command, the chalk board state is saved and logged on the server, thus allowing previous content to be viewed or downloaded. If only text is written, optical character recognition can be used to further digitize the content.

What makes the project really useful is the low cost. The sensors cost a dollar. The other parts – PVC pipe, weights/pulleys, Arduino and the Radio key fob – were all bought for under 40 dollars. For some additional cost (and maybe more time in their case) they could have automated the detection of when the chalk was actually doing the writing. The team have made their code available on Github. For a Chalk board at the other end of the cost spectrum, check this one out. Video below.

Filed under: Arduino Hacks

Lamp Comes to Life with Ultrasonic Sensors

Fans of the bouncing lamp from the Pixar corporate logo will enjoy [Daniel]‘s latest project. It’s a motion controlled desk lamp that uses ultrasonic sensors to control its physical position.

The core of the project is an Arduino and the three ultrasonic sensors. The sensors act as range finders, and when they are all working together under the direction of the microcontroller they can tell which direction a hand was moving when it passed by. This information is used to drive two servos, one in the base and one on the lamp’s arm.

The project requires an articulating desk lamp of some sort (others besides the specific one [Daniel] used shouldn’t be much of a problem as long as they bend in the same way). Most hackers will have the rest of the parts on hand, with the possible exception of the rangefinder. The code is up on the project site for a look-see or in case you want to build your own.

The only problem that [Daniel] had when putting this all together was that the base was a little wobbly. He was able to fix that with some thumbtacks, and we think the next step for the project should be switching the light on and off over the internet.

Filed under: home hacks

A Virtual Touchscreen (3D Ultrasonic Radar)

Producing items onto a screen simply by touching the air is a marvelous thing. One way to accomplish this involves four HC-SR04 ultrasonic sensor units that transmit data through an Arduino into a Linux computer. The end result is a virtual touchscreen that can made at home.

The software of this device was developed by [Anatoly] who translated hand gestures into actionable commands. The sensors attached to the Arduino had a an approximate scanning range of 3m, and the ultrasonic units were modified to broadcast an analog signal at 40 kHz. There were a few limitations with the original hardware design as [Anatoly] stated in the post. For example, at first, only one unit was transmitting at a time, so there was no way the Arduino could identify two objects on the same sphere. However, [Anatoly] updated the blog with a 2nd post showing that sensing multiple items at once could be done. Occasionally, the range would be finicky when dealing small items like pens. But besides that, it seemed to work pretty well.

Additional technical specifications can be found on [Anatoly]‘s blog and videos of the system working can be seen after the break.


[Thanks for the tip João!]

Filed under: Tech Hacks

My FirstMonster (or FM for short)

Primary image

What does it do?

autonomouse navigation

I managed to finish my first robot on witch I spent a lot of time, mostly because a lot of stuff was new to me. It is not very complicated but it seems to do it's job well. I posted everything about the build on my blog and also the parts I used (and the ones I rejected).

It is a Tamiya tracked platform with dual gearbox. I used an Arduino UNO and a SeeedStudio motor shield to drive it from a 11.7 lipo battery I had from my RC heli. It uses a Ultrasonic sensor to look in front and also a DIY IR sensor for backing up. I also added a temperature sensor for the fun of it.

Cost to build


Embedded video

Finished project



Time to build

20 hours



URL to more information


300 grams

read more

Minecraft Creeper

Primary image

What does it do?

Obstacles avoidance via infrared sensor


Greetings from Hong Kong.

This is my first Arduino project. I have worked with the handyboard and NXT few years ago. The Arduino seems popular and easy to get into for people from non-electronic background like me, so I decided to build something simple to get myself familiarize with the Arduino board and interfaces. For the look I decided to make it the Minecraft Creeper, for the non-gamers, it's a iconic mob that appears in the 8-bit inspired 3D game Minecraft. If you havent try it before, grab a copy now! 

Cost to build


Embedded video

Finished project


Time to build



URL to more information


1500 grams

read more

Physics Lab 3

The Physics Lab 2 post and Physics class progress described some experiments we were going to do this week with the ultrasonic range finder(s).

What we actually did, after spending a fair amount of time discussing the schedule for the year and expectations (one of the students has not started yet, because of the amount of time he was putting into his Stanford essays—I hope he gets in after all the effort he has expended, was to drop balls and try measuring the drop with both the Maxbotix sensor and a video camera.

We tried both a ping-pong ball and a slightly larger plastic ball.  With both of them the Maxbotix sensor only detected them intermittently, and we go no useful data from the rangefinder.

The HD video from the camera was more usable, but I was not aware that Tracker could use MTS (AVCHD format) files, since it greyed them out. I wasted a lot of time converting the movies to .mov format using iMovie, a piece of software that I have come to hate for its slowness, inefficient use of disk, rigid insistence on a specific directory structure, and generally unfriendly and unintuitive user interface. I’ve gone so far as to buy Premiere Elements, with the hope that it is not so awful (but I’ve not tried to use it yet, so it might be just as bad).

It turned out that my son had not installed the Tracker software on the desktop machine, so we had to get out my laptop and try analyzing the frames there.  I remembered how to calibrate and get the autotracking set up, but I forgot how to specify the beginning and ending frame (I eventually figured it out, but only after some false starts).  The data was pretty clean, though autotracking did lose the ball at one point because of some really stupid projections about where it ought to be.  Redoing the autotracking fixed that problem.  The errors in the tracking due to motion blur were not noticeable in the position plot, made small wiggles in the velocity plot, and made huge wiggles in the acceleration plot.  We did get a chance to talk about how a ±1mm error in position results in a ±3 cm/sec error in velocity and a ±90 cm/sec2 error in acceleration, when using 30 frames per second.

I tried redoing the autotracking using the AVCHD format directly from the camera, but it turns out that AVCHD uses interlaced images, so one gets two pictures of the ball in each frame. When the ball is motionless, this makes a nice circle, but when the ball is moving fast, you get two striped circles that may overlap. Tracker has trouble handling the interlacing, though a really clever algorithm could take advantage of it to get effectively double the frame rate when tracking large objects moving with reasonably constant acceleration.

Bottom line was that neither the ultrasonic rangefinder nor Tracker resulted in fast, painless measurement. We’ll have to try again next week, perhaps with bigger targets for the rangefinder. I initially thought that brighter light for the video would reduce motion blur by reducing shutter time, but it seems that the motion blur is due to interlacing, not to a slow shutter, so changing the lighting won’t help. Algorithmic changes to Tracker would be needed.

What to do in next week’s lab

  1. Analyze the balldrop clips (in .mov format). For calibration, the distance we measured between the top and bottom stile of the file cabinet was 112cm. Since the ball was a few cm in front of the file cabinet, there may be some perspective error in using that measurement to calibrate the drop. Get Tracker to give you position, velocity, and acceleration plots. Use the fluctuation in the acceleration estimates to estimate the errors in the velocity and position measurements.
  2. Write a Vpython program that simulates the motion of the falling ball including the initial pause before dropping, but not including the bounces.

Other homework

  • Read Chapter 3.
  • Work problems 3.P.36, 3.P.40, 3.P.43, 3.P.46, 3.P.52, 3.P.65, 3.P.72.
  • Do computational problem 3.P.76. Note that the computational problems for Chapter 3 are not independent of each other, and you should read all the preceding problems to get hints for this problem.

Tagged: AP physics, Arduino, high school, physics, rangefinder, Tracker, ultrasonic sensor, VPython

Physics class progress

The physics class that I’m doing with my son and another home schooler is going a bit slowly.  The other student couldn’t make it again this week (Stanford early admission deadlines, and he needed the time to polish his application essays).

My son and I compared answers to the Chapter 2 problems I’d assigned (see Physics Lab 2).  We’d each made some careless errors (in one, I’d neglected to take a square root, though I’d written the right formula, in another, I’d forgotten to add the sideways movement during acceleration, in a third, my son had forgotten to divide by 2 at one point).  In short, neither of us were doing “A” work—we knew what we were doing, but were being inexcusably sloppy in the computations (me more so than my son). I’ll have to do better on Chapter 3.

I think that I won’t assign any exercises in Chapter 3 this week, to give the other student a chance to catch up.  Instead, I’ll ask my son to finish the data-acquisition code for the ultrasonic rangefinder.  I wrote some simple code running on the Arduino for gathering the data, and he was going to write a Python program (using PySerial) to record the data and output it in a format suitable for plotting with gnuplot.

Our goal is to finish at least the Newtonian mechanics (Chapters 1–13 of Matter and Interactions) before the AP Physics C exam (afternoon of 14 May 2011), which gives us time for a little over 2 weeks per chapter.  That seems like a fairly leisurely pace right now, but perhaps the chapters get harder.  If we finish earlier, it might be worthwhile to do some timed practice with released tests, which are available at AP Central – The AP Physics C: Mechanics Exam. The Mechanics part of the exam is only 90 minutes (it is followed by the other half of Physics C, which we probably will not get to, unless we double our pace). I think that I’ll take the exam along with the two students, risking the embarrassment of them doing better than me.

Assignment for this week:

  • Finish the assignments from the previous posts (the text about how ultrasonic rangefinders work, the problems and program from Chapter 1, the problems and program from Chapter 2).
  • For my son only: get the data acquisition program working, so that we can do a lab recording something actually moving.  (We might try video recording it at the same time and comparing Tracker with the ultrasonic rangefinder as a data source.)
  • Read Chapter 3.

Arduino code for recording from rangefinders:

// Kevin Karplus
// 30 Sept 2011
//  Using the Ping))) or maxbotix ultrasonic rangefinder
//  to acquire (time_stamp, time_of_flight) pairs and send them over a
//  serial line to a laptop.

// From the documentation:
//   Bidirectional TTL pulse interface on a single I/O pin
//    can communicate with 5 V TTL or 3.3 V CMOS microcontrollers
//   Input trigger: positive TTL pulse, 2 μs min, 5 μs typ.
//   Echo pulse: positive TTL pulse, 115 μs minimum to 18.5 ms maximum.

// As a kluge, the Ping))) is plugged into pins GND,13,12.
// The output pin 13 can provide 40mA of current to the Ping))),
// which only requires about 35mA.

const uint8_t Ping_pin=12;
const uint8_t Vdd_pin=13;

const uint8_t Maxbotix_pin=2;

// speed of sound in air in m/s, as a function of temperature
// in degrees Celsius.
// BUG: currently humidity is ignored, but the speed of sound
//      is higher in more humid air.
inline float speed_sound_t(float temp_C, float relative_humidity=0.0)
  // return 331.3 + 0.606 *temp_C; // linear approx
    return 20.0457 * sqrt(temp_C+273.15);

float temp=20.0;  // temperature in degrees Celsius
float speed_sound;  // estimated speed of sound in meters/sec
float half_speed_cm_microsec;  // half the speed of sound in cm/microsecond

void setup()
{   pinMode(Vdd_pin, OUTPUT);
    digitalWrite(Vdd_pin, HIGH);
    pinMode(Ping_pin, OUTPUT);
    digitalWrite(Ping_pin, LOW);

    pinMode(Maxbotix_pin, INPUT);

    half_speed_cm_microsec = speed_sound *0.5 * 100. * 1.e-6;
    Serial.print("Assuming temperature of ");
    Serial.print(" gives speed of ");

    Serial.println("Arduino Ready");


// read_ping returns the time in microseconds for one echo pulse
// There seems to need to be a 1 msec delay needed between read_ping()
// calls (200 microseconds does not seem to be enough).
// Reads are very unreliable if the target is close than about 8cm.
unsigned long read_ping(void)
{   // request a reading
    digitalWrite(Ping_pin, HIGH);
    digitalWrite(Ping_pin, LOW);
    // Now there is a 750 microsecond hold off
    pinMode(Ping_pin, INPUT);

    unsigned long tof= pulseIn(Ping_pin, HIGH);
    pinMode(Ping_pin, OUTPUT);
    digitalWrite(Ping_pin, LOW);
    return tof;

// read_maxbotix returns the time in microseconds for one echo pulse
// Reads are very unreliable if the target is close than about 16cm,
// but seem more consistent than the Ping))) for longer distances.b

unsigned long read_maxbotix(void)
    return pulseIn(Maxbotix_pin, HIGH);

bool send_Ping_data=0;
bool send_Maxbotix_data=0;
void loop()
     if (Serial.available())
     {  char;
        {  case 'b':
           case 'm':
           case 'e':

     // For both sensors, report when the measurement was made,
     // the time of flight for the pulse to go and return,
     // and the computed distance for
     // Both are reported in milliseconds.
     // The time of measurement is corrected by half the time of flight,
     // so that it approximates the time at which the pulse bounced off the object.
     if (send_Ping_data)
     {   unsigned long time_of_flight=read_ping();
         unsigned long when_measured=micros();
         delay(1);   // wait a millisecond to let sensor recover
     if (send_Maxbotix_data)
     {   unsigned long time_of_flight=read_maxbotix();
         unsigned long when_measured=micros();



Physics Lab 2

The Physics Lab 1 post described a first experiment using ultrasonic rangefinders.  The students have not really done the Wikipedia-style writeup of how an ultrasonic rangefinder works that I wanted.  I’m not sure whether to push for that or to let it slide—it is important to develop technical reading and writing skills, but they have not yet gotten to the point in the physics course where they could actually derive the speed of sound equation.  The speed of sound in a gas is only vaguely referred to in Chapter 12 of Matter and Interactions, though there is quite a bit on the speed of sound in a solid.

I ended up buying two different ultrasonic rangefinders:

Both of these rangefinders provide a pulse-width output that can be measured with the Arduino pulseIn function call.  The measurement is provided in microseconds, but seems to have a slightly coarser resolution, with measurements spaced about 5 microseconds apart.  To convert round-trip time into round-trip distance, we have to multiply the time in seconds by the speed of sound in meters/second.

There is an online calculator for the speed of sound as a function of temperature, pressure, and humidity, which gives a citation for the calculation (from the Journal of the Acoustical Society of America), but does not give a clear statement of calculation actually used.  The same calculator (at least citing the same source) is also available from UK’s National Physical Lab.  I used a simpler approximation (without humidity or pressure corrections) from Wikipedia’s Speed of Sound article:

On Friday, we did the lab itself:

  1. Hook up the rangefinder to the Arduino and program the Arduino to keep taking measurements and reporting them to the serial line. (I wrote the Arduino program myself, but my son is working on a Python program to record a series of measurements from the Arduino, which will be needed for the next lab.)

    The setup for Lab 1. The Ping sensor is plugged directly into the Arduino, which sits on top of a copy of the OED, to get it far enough from the floor that we don't detect the floor rather than the wall.

  2. Calibrate the sensor by placing it at carefully measured distances from a hard wall and recording the readings.  Repeat at several different distances.  (Record temperature, humidity, and barometric pressure, if possible.)  Here are the measurements made by the students, taking just the midpoint of the range observed:

# MaxBotix LV-MaxSonar-EZ Calibration
# Distance (centimeters)    Delay Time (microseconds)
10                818
20                1075
30                1515
40                2299
50                2887
60                3470
70                4060
80                4645
90                5231
100               5815

# Parallax Ping))) Sensor Calibration
# Distance (centimeters)    Delay Time (microseconds)
10                735
20                1215
30                1800
40                2405
50                3015

They had a lot of trouble getting consistent readings for the Ping))) sensor.  I think that this may have been due to trying to take the measurements without pausing enough between them, so I added an extra millisecond delay after each Ping))) measurement, and my son and I collected new data today.  We modified the setup slightly, so that instead of using a tape measure on the floor, we measured from the wall to the front of the Ping))) sensor with a steel tape measure.  Here are the measurements we made:

# Ping))) calibration data
# 1 October 2011
# Arduino report several (usually 6) measurements for each distance
# We recorded the actual distance, the minimum and maximum reported time of flight,
# and the minimum and maximum distance reported by the Arduino.
# The reported distance assumed 343.21m/sec speed of sound, and that the time of flight
# was twice the distance.
#distance(cm)  min_tof(usec) max_tof(usec) min_cm max_cm
10    616    624    10.57    10.71
20    1225    1230    21.02    21.11
30    1786    1818    30.65    31.20
40    2385    2391    40.93    41.03
50    2939    2962    50.44    50.83
60    3540    3542    60.75    60.78
70    4065    4089    69.76    70.17
80    4610    4729    79.11    81.15
90    5240    5265    89.92    90.35
100    5833    5858    100.10    100.53
110    6444    6446    110.58    110.62
120    7018    7050    120.43    120.98
130    7575    7582    129.99    130.11

These measurements were fairly consistent (though the variation is larger than I’d like).  I did notice that the Ping))) sensor could get fooled rather badly when an object disappeared from its field of view.  For example, when pointing the sensor at the ceiling from my benchtop, the distance is reported as a fairly consistent 177±0.5cm.  Waving an object in front of the sensor got reasonable readings, but removing the object caused the sensor to get stuck reporting 50.5±1cm, though there was nothing at that distance.  Sometimes the sensor returned to the 177cm reading, sometimes to the 50cm reading, and I’ve not been able to figure out what causes the difference.  The MaxBotix sensor has different dropout problems, sometimes missing the echo and reporting a very long distance, but generally seems to be a little more stable.


What to do before next week’s lab

  1. Plot the sensor readings vs. the actual distance.
  2. Do linear regression to get a predictor of actual distance given sensor reading.  (Caveat: need to plot distance vs. readings rather than readings vs. distance to get best fit for calibration.)  What is the relationship between the speed of sound and the slope of the line?
  3. What is the accuracy and precision of the measurements?  What range of distances can be measured? Is the accuracy better expressed in terms of absolute error (±5mm, for example) or relative error (±1%, for example)?
  4. Fix the Arduino program to get better estimates of the distances from the sensors, if possible.
  5. Get a recording program working to record a series of measurements of a moving object.

What to do in next week’s lab

  1. Redo the Maxbotix calibration the same way we redid the Ping))) calibration, collecting min and max time of flight and using better distance measurements.
  2.  Use either the Ping))) or the Maxbotix sensor to record the movement of a simple object away from the sensor and plot the motion.
  3. Write a Vpython program that simulates the motion, using only a few constants, not a table of positions or velocities (that is, approximate the motion as constant velocity or constant acceleration).  The simple object could be a small vehicle made from Lego (motorized or not), a mousetrap car, a rolling ball, a falling ball, or whatever else is easy to measure.

Other homework

  • Read Chapter 2.
  • Work problems 2P38, 2P40, 2P62, 2P63, 2P66, and 2P69.
  • Do computational problem 2P72.

Tagged: Arduino, engineering education, Matter and Interactions, physics, rangefinder, science education, ultrasonic sensor

Physics Lab 1: ultrasonic rangefinders

We had the first official meeting of the home-school physics class today.  It was just my son and me. Originally we were going to have a second student, but he was busy with college application essays, and asked if he could start next week instead.  My son compared his and my solutions to problems 1P89, 1P97, 1P98, and 1P117 (all the non-computational problems from Chapter 1 of Matter and Interactions).  We got all the same results, but I had left out the units on one of the intermediate steps on one problem—a bad habit that I will try to break, as I agree with John Burk that one should tell the full story of the number, throughout a computation.

In Physics Lab 1, I outlined the first experiment for my home-school physics students and me to do, using an ultrasonic rangefinder.

Here is what I proposed:

  3. Plot the sensor readings vs. the actual distance.
  4. Do linear regression to get predictor of actual distance given sensor reading.  (Caveat: need to plot distance vs. readings rather than readings vs. distance to get best fit for calibration.)
  5. Modify Arduino code to use the calibration parameters to provide better distance measurements.
  6. Re-calibrate using new code.  What is the accuracy and precision of the measurements?  What range of distances can be measured? Is the accuracy better expressed in terms of absolute error (±1cm, for example) or relative error (±5%, for example)?
  7. Open-ended: Experiment with detecting different targets (maybe flat targets from wall size down to the size of a quarter, maybe targets of different materials, maybe spherical targets).  What effect does target size, shape, material,  … have on range and accuracy of the measurement?

What we actually did:

My son and I each picked one of the rangefinders (I bought a Maxbotix LV-MaxSonar-EZ2 and a Ping))) sensor), and separately wrote Arduino code to read them. He chose to use the Maxbotix in the pulse-width mode, which is uncalibrated, but which has the greatest resolution.  I used the Ping))) sensor, which has a similar pulse-width mode.  The biggest difference is that the Ping))) needs to be triggered, while the Maxbotix repeats the measurement several times a second.  He had to solder a header onto the Maxbotix in order to connect it up, while I could cheat a little and plug the Ping directly into the Arduino board.  We could probably arrange to have both sensors on the Arduino at once, but have not tried that.

Both of us failed to get busy-wait loops with digitalRead() to work, but we both managed to get pulseIn() to work.  He just reported time in microseconds (then he had to go off to his improv class).  I spent a little more time adding a computed speed of sound (with temperature correction, but not humidity correction), to report distances in cm.  The repeatability of the Ping))) seems pretty good: about ±1mm, but I’ve not tried to calibrate the accuracy yet.  I don’t know whether the limit on the resolution is the coarseness of the pulseIn() measurement of time or variation in the pulse width output by the sensor.

For next week:

My son still needs to do more work on the prelab writeup about how an ultrasonic rangefinder works, so I hope that both students will have drafts of that for next week.  Also assigned for next week is a Vpython programming assignment (Exercise 1p123).

In lab next week we’ll compare our programs for 1p123, then do some calibration experiments with the rangefinder, or try using it to record a series of time and distance measurements for a moving object, or try learning to use Tracker to do video analysis.

Tagged: Arduino, engineering education, Matter and Interactions, physics, rangefinder, science education, Tracker, ultrasonic sensor