I want Student Robotics to grow. I want this to happen for many reasons. The most greedy of these is that I get to play with some cool kit and meet some cool people. Hopefully the least greedy reason is that pre-university engineering education in UK schools sucks. Student Robotics can and does make it better. The impact of Student Robotics on schools in the UK at the moment is very small. I want that to change.
Student Robotics is run by university students. This is really important. Those students gain a massive amount of knowledge and experience from running it. I know this to be true as I was and still am a student member of SR, and I’ve spoken to at least one other person who thinks the same. I’ve yet to find someone who admits otherwise!
Student Robotics is a young community. I guess that all just-starting communities have to grapple with the problem of getting new people involved. Over the last couple of years there have been a few attempts at doing this. These initially appeared to be successful but almost none of the people who joined continued past a month or two. This certainly wasn’t a problem with the people who joined. I don’t think it was that they didn’t have time or didn’t like my face (OK, it could have been the face). The problem is difficult to understand.
I’ve spent many hours discussing with people why we have this recruitment problem. The answer that’s come up quite a lot is that new members have to climb an extremely steep learning curve before they can participate in discussions about what the group is doing, let alone discussions about developing the hardware that will fits those goals.
There’s always going to be a barrier to entry set to an arbitrary level by a community. Working out what to change to lower that barrier can be a hard problem that I think can only really be approached through experiment.
So, I’ve decided to try and inject some new variables into that experiment and start by addressing the problem in two ways. You’ll find out what they are soon :-)
When I want to link someone to a part on the Farnell website, I get because the URLs are both horrible and also I have absolutely no guarantee from Farnell that the URL will exist for any given period of time. This is the sort of URL you get for a Farnell part:
There most important part of the above URL is the Farnell part number. The rest is superfluous.
So I created a small script that creates nicer URLs for Farnell’s parts:
Besides just being generally shorter and easier to parse, these URLs potentially have a longer lifetime. When Farnell change their website and all their URLs change, I can just change my script to match whilst keeping these links valid.
Feel free to use this redirection service. Just stick the Farnell part number on the end of the URL:
I had thoughts about adding RS, but haven’t yet got around to it.
Disclaimer: This is a bit of an opinion post. No real work here!
Throughout my Electronic Engineering degree, I was often presented with information about sub-micron and sub-nanometre structures. Initially, I thought that these things were really small. I didn’t really stop to think exactly what these sizes meant. As my degree continued, I became more at home with talking about things that are this sort of size — despite never really coming close to actually building them.
So what does this small stuff actually mean? Take a ribosome as an example. These structures are found in basically every cell on the planet. They’re approximately 20nm across. These things are responsible for piecing together every protein in living things. They take in instructions in the form of messenger RNA (mRNA) and follow them to build proteins of a given structure by connecting amino acid building blocks together. That all fits within something that’s around 20nm by 20nm by 20nm.
Let’s assume that ribosomes are actually 20nm cubes. They’re not — they’re actually a much more complex shape — see the pictures on the Wikipedia page. Let’s make this assumption because it makes it much easier to consider their volume.
It’s extremely common to find articles comparing things to the width of human hair. I guess this comparison is often made because people know what hair is like. Whether it’s a useful comparison is a different matter. Wikipedia tells us that a European’s hair is usually between 57 and 90 microns in diameter. Let’s take 60um, as it makes our numbers more pleasant. That means that it’s possible (given the right tools) to line up 3000 ribosomes across a human hair. That seems like a lot of ribosomes, doesn’t it?
How big is three thousand? What can that be compared to that makes sense? Well consider that there are one thousand millimetres in a metre (duh). Most people are comfortable with that. Now think of three metres. That’s three thousand things.
Now ribosomes don’t seem as small as they once did, do they? Maybe they do to you, who knows. They don’t to me.
The technology to manufacture our own machines of this scale doesn’t exist yet. The technology to build planar devices that have features on this scale does exist. It’s unbelievably expensive, but technically possible.
I think it’s a shame that one doesn’t really get to interact/manipulate with things that are this size from an early age. We don’t even get to interact with things that are 1000 times larger. Hopefully, my dreams will come true soon and it will become feasible for anyone to construct nanometre-scale devices for approximately no money.
Maybe this will come as part of the promised “desktop manufacturing revolution”.
I’m releasing the PCB designs for the univ430 under a Creative Commons Attribution-Non-Commercial-Share Alike license.
Why non-commercial? I used a freeware version of EAGLE to design the board, which comes with the condition that designs made with it are used in non-profit applications. Any moment now I will start using gEDA — I promise. When gEDA gets to the top of my project stack again, I will migrate!
You can download the tarball containing the PCB designs here.
univ430 adapter by Robert Spanton is licensed under a Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England & Wales License.
Connectors are expensive. PCB space is too. Therefore PCB designers try to reduce the number of pins on connectors and the space that they take up on the PCB. On MSP430 boards, the programming and debugging connector is very often subject to this reduction.
TI uses a 14 pin connector on basically all their demonstration boards. This has unused pins — and these immediately get sacrificed when designing real boards. The engineer may also attempt to arrange the connector so that plugging the lead in the wrong way around doesn’t do any fatal damage. This leads to different connectors pinouts being adopted by different engineers.
I got fed up of making adapters for basically every board that I came across. Keeping track of them once I’d made them was also an issue. I now have a component draw completely full of stripboard adapters. So I built a universal adapter, which I have named the “univ430”:
The 14 pin connector on the right-hand side is the connector that goes to the MSP430 programmer, and the connector on the left-hand side connects to the target board. The jumpers in the middle allow any useful signal on the 14 pin connector to be connected to any of the other connector’s 8 pins. The jumper that looks out of place at the top right of the board is for selecting whether the programmer should power the target board.
So now moving from programming/debugging one board to another is just a matter of moving some jumpers around on a board. The markings on the univ430 contain enough information for one to reconfigure the mapping given the target connector’s pinout. However, after doing this a few times and telling others how to do it with theirs, I found that this process could be a little tedious. So I wrote a utility that takes in a file containing the pinout of the target connector and outputs a diagram that looks like the one on the right.
You can grab the source from the git repository:
git clone git://gitorious.org/univ430-map/mainline.git univ430-map
% cd univ430-map % make
Have a look at the signals that you can put in your connector map by reading the MAP file.
% cat MAP A: 1) TCK 2) TEST 3) VCC 4) GND B: 1) RST 2) TDO/TDI 3) TDI/VPP 4) TMS
Create your connector map file. I now try to put these maps in with the source code of all the msp430 projects I’m involved with, in a file called “jtag-map”. Here’s the map for the Student Robotics motor controller:
vcc tdo/tdi tck gnd
Getting the tool to generate the image is straight-forward:
./univ430-map -o map.png jtag-map
Your jumper layout will then be in map.png :-)
A Fedora RPM for this is coming soon, as is a connector for EZ430 programmers.
Site by Rob Gilton. © 2008 - 2019