Marco's Corner

Just another Software Developer's Musings

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 github.com 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

OK, I got a set of YubiKey‘s some time ago and I use one to supplement my Linux desktop login. But I wanted to lock my screen automatically when I remove my YubiKey-Nano. So I wrote a little Python daemon which is auto-started on login and watches for USB remove events. Once the USB-subsystem reports that `any’ YubiKey is removed, the screen is locked. Maybe you spotted the little problem here, the USB stuff does not know which key was removed. But since I don’t think I’ll let too many other keys connect to my laptop, it is only a little problem;-)

My little program is here: yubikey-notify.py

I’m using KDE, so for me, I dropped this into ~/.kde/Autostart/yubikey-notify.py , just make sure it’s executable by the user;-) But other desktop environments should have a similar location.

This little program can easily be modified to do other things triggered by USB (or other) udev events.

As always, have fun,

— Marco

P1000269_1024OK, so we saw and played a bit with the MaKey MaKey at the Bay Area Maker Faire and it’s a fun little piece to play with. I have a fifth-grade teacher in the family, so the plan is to enrich the class room a bit;-)

 


P1000265_1024P1000268_1024I always want to look a bit behind the scenes to understand how things work. So after a bit of google-ing, I found that it should not be too hard to implement a DIY MaKey MaKey  with an Arduino Leonardo, some resistors and some alligator clip cables. I did have the Leonardo and some resistors (1 MΩ – a little bit smaller than the 22 MΩ suggested around the web) and found the cables at the local RadioShack. I found the original(?) sources in the sparkfun github (https://github.com/sparkfun/MaKeyMaKey) and tried to adapt it a bit. I pushed my changes to a fork: https://github.com/mw46d/MaKeyMaKey. Overall, the setup worked pretty well, I guess not as sensitive as the original, but OK for mostly parts-bin parts.

So, overall, I would suggest to buy the original MaKey MaKey when you’re interested in something like that or want to attract kids to electronics. I don’t think, the DIY version would save you anything. It’s just a way to see what’s `in the box’ ;-) It’s some thing to read specs but it’s a different thing to be able to create a working setup.

As always, have fun exploring;-)

— Marco

 

P1000224_1024I was thinking about a more flexible sprinkler controller for a very long time. We have circuits which would benefit from different patterns, from the normal lawn watering to drip circuits for some flower/veggie beds to some pots and even some soaker-hoses for trees.

When I saw Daniel’s setup @ Garden Automation, I knew that this is a setup I would like;-) (Daniel is an organizer/marshal @ RobotGarden in Livermore, were I hang around once in a while.)

I looked a bit more into OpenSprinkler and especially into the different setups. I liked the `real OS’ setups better than the Arduino-like version. And in the end, it came just down to availability. When I was ready, the BeagleBone Black was just on it’s way to the revision facelift. It was not in stock anywhere.  So I settled on the Raspberry Pi as base-board. I have both running here already, so it did not make a big difference;-)

So the current setup consists of the Pi, the OpenSprinkler Pi with a zone extension board, a SainSmart LCD Module For Arduino 20 X 4 with I2C daughter board and an USB WiFi dongle. The WiFi dongle is inside the box as indented, but the LCD module did not fit:-( I might look at a higher version of that box eventually. For now, it’s kept in place by two rubber bands;-) I want to use the LCD to display status info. It currently displays the hostname, the IP address and the current date/time. Eventually it should also display info about the running/upcoming program & station etc.

The WiFi connection is not as reliable as I would have liked:-( So I’ll have to play with that a bit more. But I’m not sure, if it’s the Pi or the access point:-( Something between the two. I saw times, when I could not ping the Pi from my laptop but it would answer to pings from the AP (the laptop was used to log into the AP’s web interface, so it could talk just fine to it).

I needed to control 11 sprinkler circuits, so I had to get the Zone Expansion Board. But the extra 16 zones looks like a bit of overkill;-)

P1000215-1024P1000219-1024The OpenSprinkler Pi board (from V1.2, I believe) also includes a 4-channel ADC (8 bit) and an relay. So I want to use one channel connected to a photo resistor and the relay to control the lights outside our garage. even while the relay is rated for it, I did not like the idea of running mains power into the OpenSprinkler box. So I control another relay (in the old mechanical timer box) with the included relay. That seems to work ok.

P1000216-1024I also added an AM2301 temperature/humidity sensor along with the existing rain sensor.  I hope to use that eventually in calculating the watering needs. So far, I can just get reasonable looking values from it with the Adafruit library;-)

So overall, the bits & pieces work together. I’ll need to get some cable fasteners next time I hit Home Depot. Unfortunately, we don’t have any of the blue wall colour left over, so the footprint of the old sprinkler controller will stay for now:-(

Now it’s just up to writing/adapting the software to do what I want;-)

As always, it’s good when you can control your own world;-)

— Marco

 

Update: I got some blue paint;-) So the setup looks a bit more finished now. P1000228_1024Also, that image shows the info on the display a bit better. The software is still not at the state wher I would be happy, but I have a working setup, so that will probably move slower now:-(

 

 

IMG_20140711_143029_1024IMG_20140711_143430_1024
Update 08/20/2014: OK, a collected order from Digikey included a new case and my LCD display has a final place. It fits pretty good. I only had to remove the two top screw holes. Some more pictures as it looks right now.

IMG_20140711_143602_1024IMG_20140711_143544_1024IMG_20140711_144948_1024

 

UNI-T UT61E and Linux

No comments

For a long time, I was working with a very cheap multimeter, that I picked up somewhere at a sale. But I decided, it is time to upgrade to a bit better tool;-) Of course, when you look at electronics testing/measuring equipment, everybody knows about Fluke. But for me this is just a hobby, so those things are a bit out of my price range.

After long days thinking about it and searching the net, I eventually found the UT61E, which looks like a very nice tool. It also supports data logging to a computer which might come in handy at times;-) So that’s what I settled on.

After I got the DMM, pretty much the first thing I tried, was the connection to my Linux laptop via the UNI-T USB cable. I saw before, that it should work. But it turned out a bit more involved than expected. The best resource was probably Rainer Wetzel’s page to the UT61E . But I was also running into the `suspend’ problem. So the next page is UT61 , which has the trick with the suspend.

But overall, I did not like the idea to run everything as root as both pages suggest/require. So I wrote a little udev rules file, with seems to take care of both problems;-)

# UNI-T USB Adapter
# This file should be installed to /etc/udev/rules.d so that you can access the Adapter without being root
#
# type this at the command prompt: sudo cp 99-UNI-T.rules /etc/udev/rules.d
SUBSYSTEM=="usb", ATTR{idVendor}=="1a86", ATTR{idProduct}=="e008", MODE="0666", ATTR{power/level}="auto", ATTR{power/autosuspend}="0"

Install that little file into /etc/udev/rules.d/ and restart udev and the next time you plug the cable in, it should just work without being root;-)

I hope this little gem helps the next guy;-)

Have fun,

— Marco