Marco's Corner

Just another Software Developer's Musings

OK, this tooArm1k quite some time but some info to our entry for the RobotArm event for the Science Olympiad Division C. This robot is probably overkill for the event, but maybe other teams can find some interesting tidbits for the next iterations of the event. After our first attempt with the team of our daughter in 2013, this was the second version with the team of our son. In the three years in between, we got somewhat more into the whole robotics area;-) I competed two times in the RoboGames and overall learned a bit more about the whole area.

So this year’s robot arm is using mostly Robotis Dynamixel AX-18 & AX-12 servos. They work much more consistent than the normal RC servos, but they are also much more expensive. Most mechanical parts were laser-cut @ RobotGarden, a maker space in Livermore, CA. The `gripper glove’ was 3d-printed;-) Both of those things were not really available three years earlier. The FreeCAD drawings for all are included in the so_arm repository. The gripper itself is one pre-made part, the LynxMotion Little Grip Kit with the only RC servo in the arm.Arm2

The brain stem is a little  Robotis OpenCM 9.04 board with an adapted Arbotix firmware. The idea behind that little board was good, but it looks like there is not too much progress with the OpenSource Support:-( In 2013/14, there was some momentum behind it, but now it looks pretty dead. Why the Arbotix firmware? It makes the connection to the higher level Robot Operating System (ROS) very easy, in this case via a Serial-USB connection.

ROS is used in many different robots in research/education as well as in production environments. It brings many features for higher level control and can be adapted to new robots as needed. So this was a good way to explore it’s features. In the process, we learned a lot with the help of Patrick Goebel’s “ROS by Example” books😉  They show a lot in a `simulated environment’ as well as with real robots when you happen to have the right hardware. But we were able to adapt things to our arm as well.

The first idea was to use a Raspberry Pi2 as ROS computer. I use such setups for some driving rovers. But we quickly learned that the path calculations were too much for the Pi. So in the end, ROS was runArm3ning on a laptop with Ubuntu 14.04 which worked very well. If you watch the video above carefully, you see the model of the arm in RViz on the screen before the laptop turns the screen dark (on batteries).

The Arbotix ROS repo is cloned from the original with my changes and the CM firmware.

The SO_Arm repo contains all the other ROS source packages (some modified copies of the rbx arm packages) and the mechanical designs.

And the result of all that? A second place at the San Joaquin County event;-) The first place went to a `two arm, remote controlled setup’. But overall, we learned a lot;-)

As always, look to explore something new;-)

A little update: The thumbnail images actually hide some larger versions with extra notes. They are very hard to see on the little versions and I got some comments about that.

Over the lasspamt couple of days we saw a big increase in SPAM bugs and SPAM comments in a Bugzilla installation. After the initial rush to stop that influx and clean up the mess, I took some time to look around and try to find some help to fight that issue at the source. Basically trying to filter/reject those bugs/comments right at the submission. Unfortunately, I did not really find much  🙁

The next step was to look at the sources (thanks for Open Source Software 😉 and see how hard it would be to to add a classification setup on my own. Bugzilla has a nice setup for hooks, but unfortunately there were none that fit my purpose. So I decided to add my code right into the normal sources. It turned out, that the majority of the additions were limited to two spots in one file, after the normal validations for the bug creation and the comment addition. I made some more changes related to configuration of the new service and to the error handling/text. But overall, it was quite easy and quick 😉 Thanks to another piece of Open Source Software: the CPAN Net::Mollom module.

The bz_4.4.11.patch was done against Bugzilla 4.4.11 and the resulting installation was tested locally with some simple messages and a free Mollom account. It seems to work as expected, but I don’t yet claim a real-world deployment. That would probably cost some money depending on how large the installation would be.

An additional Net-Mollom.patch to the Net::Mollom sources allows it to use the proxy configuration from Bugzilla. I thought, this would make things easier if the installation would need a proxy to reach the Mollom servers.

This whole exercise was just an attempt to see how much effort would be needed to implement a service-based SPAM classification for Bugzilla. This blog uses Akismet to classify comments and I believe my code could easily be adopted for that or even any other service. The most important part was to find the right spots where all the information is easily available before anything is committed to the DB. I think, I found pretty good spots 😉

As always, have fun expanding you horizon 😉

Our swim season is almost over, so here another post about my CTS console experiments.

I tried to do two things for the scoreboard connection:

  1. Create a wireless link to the scoreboard.
  2. Understand the protocol enough to build my own example scoreboard.

So far, I was only partially successful.

IMG_20150717_114928_1024I know the link is running a RS-232 with 9600Baud 8-E[ven]-1. So that’s the first hurdle. My firmware for the 3DR telemetry radios should be able to handle that and it seems to work for a while. But eventually, the radios loose the wireless link and then wait a couple of seconds before re-establishing it:-( So the wireless link is somewhat jumpy so far:-( Of course, I needed a MAX3232 breakout board as well between the console and the radio, very similar to the link to the computer. But I had to add a 820Ohm resistor into the RS-232 receive side. Otherwise, the MAX3232 would get very hot:-(

IMG_20150717_105839_1024I also logged soIMG_20150717_105815_1024me of the transmissions from the console and I believe, I have a pretty good understanding of the used protocol. I was able to write a little Arduino Mega (or ADK) sketch to handle it and drive a little display and send the decoded strings to an attached computer for more interesting processing;-) I used a Mega because it has multiple hardware serial ports;-) I decided to use “Serial” for the connection to the computer and “Serial1” for the connection from the Colorado console. My sketch is here: ScoreboardEmulator.tar I used three of the Sparkfun four-digit 7segment displays, but I only drive eight digits and one colon right now. That would also be hard on an Arduino Uno or similar.

P1000673_1024Right noP1000670_1024w, the little display shows the Colorado scoreboard `0F’ channel but all channels are sent to the computer.

Using a different display setup, that Mega would be able to drive a complete ten+ lanes display;-) Sparkfun has 6.5″ digits with a storing driver board for about $20 each. You could probably find them even cheaper directly from China, especially when you want to build a 10 lane display which would need about 100 digits. I tested mostly with the older Colorado System 5 but the System 6 is working as well;-)

So, overall more to think about;-)

Have fun,

— Marco

P1000667_1024Today’s post is going into a somewhat different direction. I was a tech-dad for our summer swim team, the Tracy Tritons,  for maybe ten years now.

My first extension was a little Ruby on Rails application to publish the meet information quickly to all the parents on a local WiFi network and on the internet. I started that in 2008 and used it until about two years ago when we switched to Hy-Tek’s MeetMobile. The application is still working with Hy-Tek MeetManager 5 backups and the sources live @ my github account;-) But that’s actually not what I wanted to write about today;-)

About a month ago we had some problems with our ageing meet laptop. So I was looking at possible backup solutions. MeetManager 5 seems to run fine on my Windows 7 64. BUT I could not find any drivers for our USB-serial adaptor:-( Others on the web described different attempts with different drivers but nothing wanted to work.

I also know that we push the cable length of our serial cable with more than 150 feed.

So I started to look at alternatives.

P1000666_1024I’m also playing with some autonomous rovers, and there I learned about the wireless 3DR telemetry links. They are basically a serial connection over a long-range 915 MHz  link. You can find them cheaper on ebay and they have a nice open firmware;-) I know, that link is working fine on my Windows 7 64;-) So those looked like a good fit to what I was trying to do;-)

But there is one more hurdle, the Colorado Consoles do have real RS-232 ports, not the TTL-levels expected by the radios. So I needed one more building block. The Ti MAX3232 is exactly what I needed and you can get complete little boards on ebay;-)

With all the hardware components sourced, I was looking at the software side. The link between the timing console and the meet computer uses 9600 Baud 8-O-1. That Odd parity bit is not supported by the original radio firmware. So I had to adapt that a little bit. I cheated a little bit there;-) my modifications accept the parity bit and ignore it on the receiving side. The error correction over the wireless link is done as it was before with the [now] normal 8-N-1. On the transmitting side, I calculate the parity bit again and send the required 8-O-1 to the target;-) While that’s not officially correct, I believe, it should be good enough since much faster links over longer distances don’t rely on the parity bit any more.

My changed firmware with support for Even and Odd parity bits lives on github as well;-) If somebody wants to have fun, feel free;-)P1000665_1024

The link seems to be working OK for what I have tested so far;-) With one side on our living room floor, I could take the other side outside more than 200 feet away. Then there were more houses in the way, so I don’t know the maximum reach;-)

As always, take bits & pieces and combine them in new and exiting ways;-)

Have fun;-)

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