Posts with «tracker» label

GPS Tracker Gets SMS Upgrade

In May of 2000, then-President Bill Clinton signed a directive that would improve the accuracy of GPS for anyone. Before this switch was flipped, this ability was only available to the military. What followed was an onslaught of GPS devices most noticeable in everyday navigation systems. The large amount of new devices on the market also drove the price down to the point where almost anyone can build their own GPS tracking device from scratch.

The GPS tracker that [Vadim] created makes use not just of GPS, but of the GSM network as well. He uses a Neoway M590 GSM module for access to the cellular network and a NEO-6 GPS module. The cell network is used to send SMS messages that detail the location of the unit itself. Everything is controlled with an ATmega328P, and a lithium-ion battery and some capacitors round out the fully integrated build.

[Vadim] goes into great detail about how all of the modules operate, and has step-by-step instructions on their use that go beyond what one would typically find in a mundane datasheet. The pairing of the GSM and GPS modules seems to go match up well together, much like we have seen GPS and APRS pair for a similar purpose: tracking weather balloons.


Filed under: gps hacks
Hack a Day 07 Jul 06:00
arduino  atmega328  atmega328p  cell  gps  gps hacks  gsm  sms  tracker  

Real-Time Planet Tracker With Laser-Point Accuracy

Space. The final frontier. Unfortunately, the vast majority of us are planet-locked until further notice. If you are dedicated hobbyist astronomer, you probably already have the rough positions of the planets memorized. But what if you want to know them exactly from the comfort of your room and educate yourself at the same time? [Shubham Paul] has gone the extra parsec to build a Real-Time Planet Tracker that calculates their locations using Kepler’s Laws with exacting precision.

An Arduino Mega provides the brains, while 3.5-turn-pan and 180-degree-tilt servos are the brawn. A potentiometer and switch allow for for planet and mode selection, while a GPS module and an optional MPU9250 gyroscope/magnetometer let it know where you are. Finally a laser pointer shows the planet’s location in a closed room. And then there’s code: a lot of code.

The hardware side of things — as [Shubham Paul] clarifies — looks a little unfinished because the focus of the project is the software with the intent to instruct. They have included all the code they wrote for the RTPT, providing a breakdown in each section for those who are looking to build their own.

There is an extra step to auto-align the RTPT to north, otherwise you’ll have to do so manually. But [Shubham Paul] has designed it so that even if you move the tracker about, the RTPT will readjust its calculations in real time. Each part of the project includes a wealth of related information beyond simple instructions to adequately equip any prospective builders.

This hack gets the job done. If it’s looks you’re after, an artistic expression of maker skills and astronomy can be seen in this planetary map that relies on persistence of vision.


Filed under: Arduino Hacks, software hacks

Dual Axis Solar Tracker with Online Energy Monitor

[Bruce Helsen] built this dual axis solar tracker as one of his final projects for school.

As can be experimentally verified in a very short timeframe, the sun moves across the sky. This is a particularly troublesome behavior for solar panels, which work best when the sun shines directly on them. Engineers soon realized that abstracting the sun away only works in physics class, and moved to the second best idea of tracking sun by moving the panel. Surprisingly, for larger installations the cost of adding tracking (and its maintenance) isn’t worth the gains, but for smaller, and especially urban, installations like [Bruce]’s it can still help.

[Bruce]’s build can be entirely sourced from eBay. The light direction is sensed via a very clever homemade directional light sensor. A 3D printer extruded cross profile sits inside an industrial lamp housing. The assembly divides the sky into four quadrants with a light-dependent resistor for each. By measuring the differences, the panel can point in the optimal direction.

The panel’s two axis are controlled with two cheap linear actuators. The brains are an Arduino glued to a large amount of solar support electronics and the online energy monitor component is covered by an ESP8266.

The construction works quite well. If you’d like to build one yourself the entire BOM, drawings, and code are provided on the instructables page.

 


Filed under: Arduino Hacks, solar hacks
Hack a Day 24 Jul 21:00

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);
    Serial.begin(115200);

    speed_sound=speed_sound_t(temp);
    half_speed_cm_microsec = speed_sound *0.5 * 100. * 1.e-6;
    Serial.print("Assuming temperature of ");
    Serial.print(temp);
    Serial.print(" gives speed of ");
    Serial.print(speed_sound);
    Serial.println("m/s");

    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);
    delayMicroseconds(10);
    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 c=Serial.read();
        switch(c)
        {  case 'b':
            send_Ping_data=1;
            send_Maxbotix_data=0;
            break;
           case 'm':
             send_Ping_data=0;
             send_Maxbotix_data=1;
             break;
           case 'e':
             send_Ping_data=0;
             send_Maxbotix_data=0;
             break;
        }
     }

     // 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
         Serial.print(when_measured-time_of_flight/2);
         Serial.print("\t");
         Serial.print(time_of_flight);
         Serial.print("\t");
         Serial.println(time_of_flight*half_speed_cm_microsec);
     }
     if (send_Maxbotix_data)
     {   unsigned long time_of_flight=read_maxbotix();
         unsigned long when_measured=micros();
         Serial.print(when_measured-time_of_flight/2);
         Serial.print("\t");
         Serial.print(time_of_flight);
         Serial.print("\t");
         Serial.println(time_of_flight*half_speed_cm_microsec);
     }

}


Tagged: AP physics, Arduino, high school, physics, rangefinder, Tracker, 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:

  1. Hook up the rangefinder to the Arduino and program the Arduino to keep taking measurements and reporting them to the serial line.
  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.)
  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