Marco's Corner

Just another Software Developer's Musings

IMG_20150705_151534 IMG_20150705_151644This post is way late:-( First I got stuck trying to find or build a Fritzing part for my TSL235R light sensor. I tried to build the part in FreeCAD but that died a couple of times on me, so I got frustrated:-( I constructed other things with FreeCAD and had no problems, but it did not like that little part:-( Then, I had some problems with my WordPress setup, the backup scripts did not want to work and all the sudden it’s five month later than when I wanted to write this post:-(

The colorimeter was actually the first sensor setup I wanted to build for tests. It was the one, I had the least experience with before. The original costs more than $100: Vernier Colorimeter

My colorimeter is basically four light sources, one RGB LED which I use as three distinct LEDs in one housing and one of the near-UV LEDs and the TSL235R light sensor, all driven by the Arduino. I did play with the light sensor for a different project before, so I had some code already;-)

The TSL235R light to frequency sensor costs about three dollars @ sparkfun. The LEDs are pretty cheap when you buy them in larger quantities;-) I usually have enough of those on hand;-) You want to keep outside light out of your device and you want to limit reflexions around your sample, I just built a Lego box and lined it with mat black construction paper. You want some clear cuvettes for your test solutions and maybe some pipettes. Usually those are only sold in packs of 100+:-( I built a little template out of scrap plywood to get the cuvettes in the same spot for each test.

The Arduino code is pretty straight forward. For each colour requested, it turns on the LED at a specified level (calibrated to the particular setup), waits a bit, counts interrupts from the sensor for one second, turns the LED off and calculates the final value. That’s done ten times in a loop just to get more data points.Colorimeter

I tried this setup with different concentrations of fountain pen ink and it kind of worked. But I did not keep a record:-( and now everything is dried up:-( The sketch is here: Colorimeter.tar

That’s it for the 2015 Science Olympiad posts, sorry that this last one took so long. But maybe it will be useful again at some point.

As always, have fun exploring;-)

ForceProbe1_1024 The third sensor in my collection is the force sensor. The Vernier Dual-Range Force Sensor costs around $109. My version was < $20 in parts in addition to the Arduino. Yes, it’s not as nicely calibrated but you should be able to get it close.

What is a force sensor really? A weight scale held sideways. Or the other way around, a scale measures the gravitational force an object exerts and translates it into a weight unit. So I use a scale as the sensor, basically a luggage scale from Amazon with a rating of 40kg. It’s available for around $3.50 (shipping from China) or a bit more from an Amazon warehouse near you. That scale is rated for 40kg which would be equivalent to almost 400N, much more than the 50N of the Vernier sensor.

When you try to push on the hook assembly of that scale, it actually starts to show negative numbers, so it would actually work for both directions. But not really inside the case, the metal parts are held in place by little plastic tabs. They are not indented to carry any force! But it’s easy to remove the strain gauge from the housing and create a new frame for it. An Erector Set or something similar would probably work very well. I did not go that far [yet];-)

The other needed part is an instrumentation amplifier because the strain gauge sensor delivers only very small voltage variations. I decided on the Analog Devices AD620 which I found on Amazon as well. With shipping, it was about $10.

I found a nice video @ the NerdKits site: weighscale that explains the principles very well. My circuit follows the idea pretty closely except I’m using a real Arduino instead of the `bread boarded MCU in the video’.

One word of advise: Be careful when you want to play with something like this. The wires on my  strain gauge were not well attached. So I lost one and had to remove the silicone cover, solder a new wire in place and recreate a cover. Try to prevent it, it’s no fun.

ForceSensor_bbFor the AD620, I selected a gain of about 1000. That means a 49Ω resistor. So I use two, I had laying around. The rest is very similar to the NerdKit circuit, including the reference voltage of 2.5V.

I created a Fritzing part for the AD620 because I could not find one:-( It’s available here: AD620.fzpz (You will have to remove the extra .zip suffix, WordPress did not want to let me upload the file without it:-()

My little sketch is here: ForceSensor.tar It does a zero-point calibration first and then measures the force in the main loop. As always, that can be easily adapted to some data collection/plotting setup on the host computer. The factor to translate the values to Newtons really depends on your sensor and the gain of the AD620. So you will need some known weights and calculate it.

Have fun;-)

— Marco

MotionProbe1_1024 Ok, it took a bit longer than expected. But here is my version of the Vernier CBR2. That sensor is basically a ultrasonic distance sensor. All the other data is calculated based on distance changes over time. I’m using the HC-SR04, which is a very cheap ultrasonic distance sensor. Depending on how long you want to wait, you can get it for less than two Dollars;-) Amazon has many offers which essentially differ in the shipping time(cheap from China or Prime for around $6).

UltraSonic_bbThis sensor has so many examples of interfacing it to an Arduino, so that this post does not really offer much new info:-( I just wanted to add it to the list to be complete. I added an extra LED as an visual indicator how quickly the sensor cycles, but that’s about it.

My little sketch just writes the measured distance in cm to the serial port. All the `higher level’ calculations would be done on the computer side. It would also be easy to add a time stamp for each distance. The sketch is here: SonarSensor.tar

The sensor works pretty well;-)

As always, have fun experimenting.

— Marco

It’s this time of the year again and preparations for the regional Science Olympiads are speeding up. This year, I looked a bit at the four sensors/probes to be used in the “Technical Problem Solving” event. I’m just a parent, so I don’t have ready access to the official Vernier probes or software. But with a couple of electronic components and a/some Arduino‘s, something similar can be build and easily interfaced to a computer.

The advantage of using an Arduino is that you can decide what to do with the collected data. It’s easy to print or create graphs or whatever else you want to do. It also allows a little bit more insight into how those sensors work.

I’m planning to create four posts in the next couple of days, one for each probe. All of the designs can be created with any Arduino/clone or whatever you have already. The additional parts cost less than $20/probe and you might find some in your parts-box already;-)

TempProbe1_1024This post is about the temperature probe. The official Vernier Temperature Sensor is not that expensive at $29 as long as you have the `infrastructure’.

My idea was heavily inspired by another blog post: “Building an Arduino Powered BBQ Thermometer”. There are other thermistors/temperature sensors out there, but the `food/cooking thermistor’ is designed for wet environments;-) So it can be safely used around/in liquids. I got a Polder Replacement Oven Probe for THM-362-86 from Amazon for $10. That was the cheapest I could find. But it turns out that it’s nominal resistance @ 25°C seems to be 220kΩ. So I had to adapt the resistor values accordingly.

TempProbeAside from the thermistor, we just need a resistor for the voltage divider, in my case, I use a 220kΩ resistor plus a 100kΩ potentiometer. I found that the resistor alone was a bit too small, so the potentiometer is used to adjust as needed. With some constants, I found for a similar 220kΩ variant of the VISHAY NTCLS100E3 thermistor, I got mine to within 1°C of another kitchen/oven thermometer. That sound be good enough for most experiments where the interesting part is more the temperature differences than the absolute temperature.

The sketch is very simple for now. It just reads the analog voltage every second and calculates the temperature using the formula and constants from the data sheet. It’s here: TempSensor.tar

That temperature probe should work at least from -20°C – 200°C, that should be enough for most experiments;-)

As always, have fun;-)

— Marco

OK, today was a little bit of a PHP day. I was wondering for a long time if I could get my chosen WP theme to work with the Infinite Scroll module of the Jetpack. I looked for a different theme a couple of times but I could not really find anything that I liked better than the current Arjuna-X theme. But that theme was not updated in quite some time. So I don’t think, it’s high on the original author’s list any longer.

So I set out to look at what it would take to get the theme to cooperate with the Jetpack Scroll. It wasn’t that hard, at least to the current state 😉 So if you’re interested, I created a little patch file: mw_arjuna-x_plus_jetback_infinity.patch

Put please be careful before applying that change to a live system 😉 I created a little local WP installation to play with first 😉 It’s not that hard 😉

Please let me know, if you find any problems.

— Marco


Dexter, the TableBot

No comments

EarlyDexter_1024I’m trying to attend the monthly meetings of the HomeBrew Robotics Club since around this summer. They are quite fun when you’re interested in hobby robotics and can make it to the San Francisco Bay Area 😉 During one of my first meetings I learned about the tablebot challenge. That sounded like an interesting task to work on. I played with partially Lego Mindstrom NXT based robots before and I had seen the BrickPi board from Dexter Industries some time ago. That combination sounded like a good idea and would become the base of Dexter. Two drive motors and a roller in the back in a simple skit steer configuration and one motor for the gripper. A Raspberry Pi B+ was becoming the brain of the robot.

Adding a CMUcam5 “Pixy” to see the coloured ball and some colour codes marking a goal box also sounded doable. But this turned out to be more problematic than I anticipated. The colour recognition of the Pixy camera is very light dependant. After differently coloured balls etc, I settled eventually on a purple cardboard cube (it’s build around a Styrofoam core for longevity 😉 .  But even so, I have to teach the colours again for daylight or florescent light. The Pixy talks via USB to the RaspberryPi. But I did not get the PixyMon (graphical display/configure program for the Pixy) to work nicely on the Pi :-( So every re-teach requires a re-wire to the laptop :-(

To detect the edges of the table, I decided on Pololu IR reflectance sensors. I used eight sensors, two in each corner to make sure, the robot does not drive off the table sideways. To get good results from those sensors, you need a good and predictable timebase. So the Pi did not sound like a good fit, running a complete Linux and doing other stuff as well. That’s why I used an Arduino Micro (any Arduino or single purpose MCU would work well 😉 to do the time critical things for those sensors and basically use a very simple protocol oveDexter - Schematicr USB to get the info to the Pi. The Arduino takes the raw sensor readings and decides if each sensor `saw’ the table or nothingness and sends `one bit’ for each sensor upstream. Before each run, the Arduino does a calibration so that it can account for any light differences etc. The sketch is here: TableBot.tar

Somewhere along the way, I decided that I needed some way to monitor what the robot was doing. Especially with the camera not exactly doing what I expected. So I added a little  Adafruit PiTFT display. That works on the same connector as the BrickPi (with some ribbon cable 😉 since both use different pins. The BrickPi is using the serial connection and the PiTFT uses I2C, SPI and some GPIO pins. The display works as a 320×240 X11 display so it was pretty easy to add some Xlib calls to draw a rectangle where the camera saw the cube or the colour codes. That helped immensely in figuring out that the communication between the Pi and the Pixy is somewhat slow and that the camera is lighting dependent.

I quickly realized that the BrickPi software (the firmware on the ATmega’s and the driver parts on the Raspberry Pi) did not really do what I expected. Especially since I had seen what the ATmega (Arduino base) should be able to do. The original did only very little in firmware and the Pi was supposed to closely watch. So I decided to push more responsibility to the two ATmega’s which build the base for the BrickPi. My firmware is probably far from perfect, but anyhow, it’s available here on github:  BrickPi . It’s a fork of the original and I only looked at the motor controls so far. No guaranties 😉 I updated the C driver header file and the examples. That repository lives on github as well: BrickPi_C.

The vidoes start during the sensor calibration, so the robot takes a moment to start moving :-(

It’s again a fork of the original, but it also has all the sources for my Dexter 😉 Project_Examples/MW/w1.cpp is basically the program for the first step of the challenge, driving from one side of the table to the other. My tablebot can not really drive straight, since  the motors don’t match very well :-( So that program let’s it bounce around the table more like a billiard ball 😉

The Project_Examples/MW/cam.cpp is for the second step. The robot does turn around until it spots the purple cube, drive to it, grab itand then drive to the edge of the table and drop the cube. after that it would return somewhere more to the center of the table and look for the next cube 😉

The Project_Examples/MW/goal.cpp is for the third step. The robot would look for the cube like before but once it grabbed it, it would start looking for a goal colour code and then drive there and drop the cube. The second clip shows the display in action for a couple of moments. You can see the red rectangle representing the purple and later a yellow rectangle representing the colour code.

If you found the strange `antennae wire’ in the previous two clips, that was an attempt to use four wight LEDs as kind of a headlight to aid the camera. But that did not work as well. The camera saw those LEDs as pretty blue and it started to see the grey grippers as the `cube purple’ and got confused :-( But I still have a little clip with the headlights on 😉

This post grew longer than I expected. But I might add more info in the next couple of days. Maybe I forgot something important before Dexter is taken apart again 😉

One more thing, Dexter runs on a RC LiPo battery, 7.4V, 2200mAh. I found that those batteries work pretty well with Lego NXT pieces as well as Power Function motors. Much better than the 6 AA’s or even NiMH’s. And the other advantage is, this little battery has the equalizing connector which can also be used as kind of a slow-charging connector. So I can charge that battery in place 😉

As always, have fun exploring
— Marco

Some Halloween Impressions

No comments

P1000454-1024P1000455-1024Halloween is always a time for me to try different things. So I tried to take some photos and videos of this years displays. Unfortunately, it rained pretty much the whole time, so I had to water-proof the things and did not want to go back in there to fix things:-( But it looked that most things survived the day outside;-)

The first picture is just a static display with some LEDs, EL-Wire and a UV lamp overhead. You can’t hear the sound;-) Speakers and an old CD-walkman are hidden under the cloth;-) This image on the door is a scary fridge;-)

The second image is a skeleton lounging on our bench with just a couple of LED tea lights for illumination. The big spider in the window is probably not happy that there is no juicy flesh left;-)

P1000460-1024The third image is of a little scary grave yard. It’s normally dark until people come by. Then the candles come on one after the other and the eyes of the grave diggers and the skeleton start to glow. The skeleton gets it’s heart beat back;-) and starts moving it’s arms. All of that is surrounded by some nice Halloween sounds. All of that is controlled by two Arduinos, one dedicated only to the sound. I found that the sound shield and the PWM for the RC servos did not play together nicely:-( The candles are the little LED tea lights, but instead of the normal batteries, I soldered wires to the LEDs. The lights are normally driven by 4.5 volts (3*1.5V batteries), but they work just fine on a digital pin on the Arduino;-) The lights got a 4″ nail hot-glued to the bottom, that works pretty well as lawn spike;-) I tried to make a little video outside but there is not too much to see. So I’ll also include a video from an inside test-run;-) I’ll upload the Arduino sketches somewhere, but it looks like I’m doing more and more of those. So I might start a repo or something. Especially since I will probably want to reuse those next year again.

I actually added some potentiometers after that test to dim the eyes a bit;-)

The next little video is of a bush by the side of our driveway. I added some LED eyes into it and some nice sounds of a lion and some kittens which will play randomly. It’s very dark again, so I have a outside clip and again on from a test run. Last year, I tried something similar but with smaller speakers and that was simply too little volume for the outside. This display is again controlled by one Arduino and using a Adafruit sound shield with amplifier. The speakers were 2* 4Ohm, 3W. That was loud enough.

Both displays use passive IR (PIR) sensors to detect people and only start up when somebody is around. They slowly play out when no motion is detected any longer.

As always, have fun playing;-)

— Marco