come and join us to build LinoRobot

Hello,

We’ve finished building the prototype of the LinoRobot and have an understanding of how all the software and hardware fit together.

old robot

There was a few issues along the way and ill summarize what we’ve learnt:

  • ROS and the navigation software requires a faster machine than the current VM.  Now we understand more we’re going to build ROS on the direct hardware.
  • The Raspberry PI doesnt have SWAP memory enabled by default and ROS ran out of memory when first starting ROS.  Enable SWAP for initial ROS startup and then disabled it.
  • We cheated the first time by using ubiquityrobotics ROS image the first time and we’ll probably cheat again, it makes setup a lot easier 🙂
  • Don’t use very cheap cheap motors as they don’t give similar results and the robot goes around in circles.  We bought some more expensive motors this time so hopefully they will move when we want them too.

The parts have arrived and we’re now getting started on the second robot.

Sheffield Hackspace install Lorawan gateway

Sheffield Hackspace has setup and installed a LoraWAN (The Things Network) gateway.  LoraWAN is a new technology that enables small amounts of data to travel large distances with low power and the best bit of it is….its free!!  This is being used by universities, corporations and hobbyist a like to transmit data such as air quality, traffic, temperature, gps informational ect. from battery (or wire) powered devices that last up to 10 years and more.

lorawan gateway

Come to the Sheffield Hackspace to learn about this new technology and make use of the gateway to prototype your idea.  If you want to make your own gateway and add to the things networks, come and learn how to do that.  See if your area has a gateway installed by clicking the link here.

For our gateway, we used a Raspberry Pi and RAK 831 to receive multiple frequencies at the same time. For some unknown reason the RAK 831 use to switch off occasionally so we’ve added a on/off relay (as can be seen in the photo) to power recycle it automatically/remotely when when it stops responding to the Raspberry PI. Hopefully we’ll find the root cause.

The Hunt for J5

Pi Zero J5 Connections

Pi Zero J5 Connections

J5 is alive, and is definitely not called johnny or a robot in a kids sci-fi film. J5 is the mystery connector footprint on the bottom of the Pi Zero. I have been puzzling over what it was intended for since getting my Pi Zero from Pimoroni.  Asking around amongst those who would know more than me about it (Not difficult to find) the hot favourite was a JTAG port but no one was entirely sure and there was no pinout. An extensive google around was surprisingly information free.

Time then for some reverse engineering, first stop was a USB microscope and a look see for obvious pin functions, gotta tackle the low hanging fruit first. Taking pin 1 to be the pin nearest the J5 ID we can see the footprint is for an 8 pin connector and the body or screen is not connected. 1 is the Pi system reset or run pin as it is labeled, 4 and 7 are ground connections. OK that leaves 5 pins to go. I visually traced the connections and lost them in to the maze of CPU via’s. As other than the reset they did not go to the GPIO pins I could rule out an easy hit as to what they were. The up side is if they were JTAG, it would have to be dedicated pins, not GPIO pins, and therefore projects could be debugged even with a phat in place. Hmmm what were those other 5 pins for. Normally at this point I would start on in with a multi meter or a scope and see what I could find out next. But serendipity smiled upon me, in that way it never normally does.

B+ J5 Connections

B+ J5 Connections

Putting some time into a side project (building a Graphite graphing server) I was working with a Raspberry Pi B+. Purely as I tend to mostly use Pi2’s now and was using up any older ones that were lying around. Embedding them irretrievably into other things. Fiddling with the board during one of many mental luls, I noticed the same mystery footprint on the board directly under the HDMI video connector. In fact it is so much the same it is also labelled J5. Cross referencing the ground pin outs that we know from the Pi Zero we get a match. What is more the 5 pins we had not identified are broken out to pogo pin pads bang next to the footprint. All along with nice labels. Combining the data we have then gives us the following table:-

J5 Pin Information
Pin No Pi Zero Function Pi B+ Function Comment
1 Pi System Reset ? Pull low to reset the Pi
2 ? TRST_N TAP Reset pull low to reset the TAP
3 ? TDI Test Data In
4 Gnd Gnd Signal Gnd
5 ? TDO Test Data Out
6 ? TMS Test Mode Select
7 Gnd Gnd Signal Gnd
8 ? TCK Test Clock

Some further technical info on TAP & JTAG can be found here worth a look at to illustrate some of the concepts behind JTAG. OK, all well and good, what is left to do, identify what sort of connector J5 actually is and make up a JTAG lead for it then connect it up and see if we are right.

Inertial Logger Prototype

Prototype Inertial Logger

Prototype Inertial Logger

The prototype hardware for my inertial logging project is built. Lovely you say, looks nice, fits in a small tin, and just like everyone else, you immediately follow it with “What does it do ??”.

This project follows on from a bunch of discussions in the SHHMakers mailing list. Basically the idea is that you can record or log a track that the tin has followed using only sensing of the movement of the tin. The movement of the tin is the inertia bit. Everything has inertia and sensors that can measure that can also infer how much and by how far something has moved. Inertial guidance works on the same principles and is used for quad-copter pilot electronics etc. This is the point at which, like everyone else, you interject “I just use my phones GPS”. But what about those instances where there is no GPS signal. Try Caving, UrbEx, SCUBA Diving, or just simply finding your car in a multi-story, when you have forgotten where you parked it. Maybe you want to know where the tube system really is under the map of a city rather than the schematic map most underground systems give you. These examples are where inertial navigation and logging have a part to play.

“OK” you say “I understand now. how do you do it ?”. If you put on a blindfold and someone manoeuvres you along a track you can, if you concentrate remember it, this is the logging bit. Each time you are turned this way or that you can feel being turned, this is what a gyroscope measures, rate of turning. If you are moved quickly or slowly you can feel that too, this is what an accelerometer measures, rate of acceleration. If you are in a lift as well as feeling the acceleration, you can feel the pressure on your eardrums change as you go up or down, this is what a pressure sensor measures. You can feel if you are outside or inside by temperature changes, this is what a thermometer measures. People who are blind are more sensitive to these things than the sighted, purely as they use these clues to navigate in a world they cannot see. They also count steps. I don’t think this project will be sensitive enough to count steps but maybe it will. It certainly can measure the passage of time against acceleration/rotation and therefore infer distance.

Zoom in to see the contents of the tin

Zoom in to see the contents of the tin

“So what’s in the tin?”. You are bored with explanations now and want to know about the techy bit. If we zoom in to the tin, we can see a 10 DOF inertial navigation board (GY-87) top left. Under that on the left is a micro SD card. In the middle is a Teensy 3.1 micro-controller. At the right top there is an Adafruit Power Boost 5oo Charger. To the bottom right is the coin cell battery backup for the Teensy’s RTC (real time clock). Underneath the board is a 2.5Ah LiPo. The power boost, LiPo and teensy were bought in from our local supplier Pimoroni. The 10 DOF (degrees of freedom, or number of things it measures) board came directly from china via AliExpress. The power supplying arrangements are a compromise that niggles somewhat. Whilst the LiPo has plenty of power, all the other components actually run at 3v3. the conversion from 5v to 3v3 is done locally on the boards using linear regulators so we are wasting nearly as much power again as they draw. Unfortunately linear regulators dump the surplus energy as heat, far from ideal in a closed tin. Particularly where we want to be able to measure the temperature as part of your logging. Altogether though an adequate first pass for prototyping and testing purposes. There is a bit of a learning curve to be climbed and this is a reliable way to do it. The 10 DOF board has 3 axes of Magnetometer, Accelerometer and Gyroscope on-board as well as an air pressure sensor for us as an altimeter, giving the 10 things or DOF it can measure.

“If you were doing this again what would you do different ?” you ask. Well bearing in mind that I acquired the parts for this a bit back and they have been gathering dust the purchasing decisions would be different. I would be replacing the hand wired SD card holder and Teensy with a Pi Zero. But have to add an RTC. Also I would get rid of the linear regulator on the 10 DOF board and power it form the Zero’s 3v3. Just to move the self heating away from the air pressure sensor which relies on an internal temperature measurement for air density compensation. I would probably add a press button on the outside of the case so that way-points or events could be marked in the track log. Useful for overcoming cumulative errors. One last thing, inertial navigation chips and managers are a field of rapidly advancing technology, many of our smart phones already have them inside. The inertial sensor chips themselves are becoming ever more integrated placing it all on one chip together along with local processing to make them ever more accurate. So something to watch out for and periodically check the current state of play.

The firmware for this prototype is available from my git hub repository https://github.com/AndyKirby/Firmware/tree/master/InertialLogger please note it is a work in progress rather than a finished item.

DigiStump DigiSpark Arduino and Debian 8 64bit

UPDATE 2016-02-02: There is an updated version of the script below which also works with the DigiSpark Pro. See below.

In the space recently we’ve been playing with the super low cost Digistump Digispark 16.5MHz boards and the Arduino 1.6.5 environment.

Unfortunately there are some issues with these working out of the box with 64-bit versions of Linux (we use Debian 8 64-bit) as one of the attached binaries is compiled for 32bit only. However, after some major head scratching, I have managed to get them to work reliably.

To get them to work. You need to install the Digispark hardware library as normal and then follow the steps below.

Installing the DigiSpark library

Add the following line to the Additional Boards Manager URLs in File –> Preferences. If you have previously added boards to this list, you will have to separate them with a ; or use the button to edit it in list form. If you need an in-depth guide, there’s one in the links at the bottom from everyone’s favourite Adafruit.
http://digistump.com/package_digistump_index.json

Fixing the missing bits

Once you’ve done that, you will need to download the following script (I’d of included it as a downloadable file, but someone disabled it on our server)…

#!/bin/bash

# Adds necessary libraries and UDEV rule for using the Digistump DigiSpark boards in Arduino 1.6.5 on Debian 8 64-bit
# Written by James Muirhead. 2015-10-12

# This works on the 16.5MHz original Digispark. Has not been tested on other varients.

# Checks if you are root, as this is required.
if [ $(whoami) == “root” ]
then
# Updates apt then installs 2 necessary libraries and their dependencies
apt-get update
apt-get -y install libusb-dev lib32stdc++6

# Adds UDEV rule which adds the DigiSpark device to the dialout group, same as required by Arduino IDE.
echo ‘SUBSYSTEM==”usb”, ATTR{idVendor}==”16d0″, ATTR{idProduct}==”0753″, MODE=”0660″, GROUP=”dialout”‘ > /etc/udev/rules.d/99digispark.rules

# Restarts UDEV to enable the above.
service udev restart


echo "DONE!!!"31
else
echo "You need to be root to run this script, use su / root to try again."
fi

Right, once you’ve got the above copied into a file called e.g. digispark.sh you will need to make it executable. To do this, you will need to log in as root (type su at the command line and type your root password). Then type the following to make the file executable.

chmod a+x digispark.sh

Ok, once the file is executable, stay root and run the following…
./digispark.sh
This may (or more likely will) take some time, so leave it till it’s done what needs to be done.

Once finished, close and re-open the Arduino IDE.

DONE!!!

Once this is all done, you should be able to upload a sketch to your DigiSpark without problems.

Links

Update 2016-02-02

I’ve written a new version of the script above which also works for the Digispark Pro. Follow the same instructions as above, but use the script below instead. It is longer, but does a few more things.

And, just because I’m feeling nice, I’ve put it on GitHub to make life easier.
DOWNLOAD NOW

#!/bin/bash

# Digispark installer.
# Written by James Muirhead.
# 2015-10-12
# https://www.sheffieldhackspace.org.uk

# CHANGE LOG
# 2015-10-16 – Only installs 32-bit extensions if 64 bit OS detected.
# 2015-11-04 – Now creates UDEV rule for DigiSpark & DgiSpark Pro.

if [ $(whoami) == “root” ]
then
apt-get update

# Installs required library.
apt-get -y install libusb-dev

# Checks for 64-bit environment and installs required 64-bit extensions.
uname -a | grep x86_64
if [ $? == 0 ]
then
apt-get -y install lib32stdc++6
fi

# Creates UDEV rule for DigiSpark
echo “# Rule to allow use of the basic DigiSpark (ATtiny85) board in the Arduino IDE 1.6.3+” > /etc/udev/rules.d/99digispark.rules
echo “# Written by James Muirhead (@PhantomFreak), 2015-10-12.” >> /etc/udev/rules.d/99digispark.rules
echo “# https://www.sheffieldhackspace.org.uk” >> /etc/udev/rules.d/99digispark.rules
echo “” >> /etc/udev/rules.d/99digispark.rules
echo ‘SUBSYSTEM==”usb”, ATTR{idVendor}==”16d0″, ATTR{idProduct}==”0753″, MODE=”0660″, GROUP=”dialout”‘ >> /etc/udev/rules.d/99digispark.rules
# Creates UDEV rule for DigiSpark Pro.
echo “# Rule to allow the use of DigiSpark Pro (ATtiny167) board in the Arduino IDE 1.6.3+” > /etc/udev/rules.d/99digispark-pro.rules
echo “# Written by James Muirhead (@PhantomFreak), 2015-11-04.” >> /etc/udev/rules.d/99digispark-pro.rules
echo “# https://www.sheffieldhackspace.org.uk” >> /etc/udev/rules.d/99digispark-pro.rules
echo “” >> /etc/udev/rules.d/99digispark.rules
echo ‘SUBSYSTEM==”usb”, ATTR{idVendor}==”16d0″, ATTR{idProduct}==”0753″, MODE=”16d0″, GROUP=”dialout”‘ >> /etc/udev/rules.d/99digispark-pro.rules

# Restarts UDEV
service udev restart


echo "All done, please close all open Arduino IDE windows & reopen before attemptting to upload code."
exit 0
else
echo "You are not root, please use sudo or su to continue."
exit 1
fi

Salvaging Lead Acid Batteries

Working on a previous project to make a prototype Pi UPS I pulled a number of salvaged lead acid batteries out of the scrap bin.

Battery Resuscitation through Desulfation

Battery Resuscitation through Desulfation

It quickly became apparent that the batteries were all flat and as each had a terminal voltage of around 0.5V they appeared to be beyond life ever again. Not surprising considering the number of years they had lived in the scrap bin without ever having a charge.

Initial attempts to put a charge into them and get them going again were without success. Even over voltage-ing them a little to get them started failed miserably. The best of them was taking around 10 micro amps. After leaving them on charge for 5 days or so the situation had not improved. So what were we looking at ? Maybe they had dried out, maybe the plates had fallen apart and were now mush or maybe being overly discharged the plates were caked irretrievably in insoluble hard lead sulphate crystals.

There are plenty of miracle cures for dead lead acid batteries and desulfation. Frankly I am rather sceptical of most of them. But for some reason I thought although slightly implausible desulfation was a fun hack to try. Chemical means to reverse the crystal build up were out as the batteries are sealed units. So it was time to rummage through the internet for ideas and then hit the scrap bins again for parts. The circuit I settled on is here Pulse Desulfator Doc. This formed the basis and the prototype as shown in the photo was a derivation of this.

Having nothing to loose other than a bit of time constructing and debugging it I set too to build it. The inductor was a hand wound approximation, the logic inverter shown in the schematic was replaced with a simple transistor based inverter using a 2N2222 NPN transistor and the mark space ratio of the 555 astabel circuit needed adjusting. Probably because the inductor value was a touch lower than it should have been. But in the end it appeared to be working.

Now the acid test (see what I did there….). From the picture you can just see the ammeter on the bench PSU showing the battery taking a charge of 200 milli amps. So success. It took 2 days of float charge plus the desulfator pulsing away to get this recovery. Over this period the input current could be seen steadily increasing, whereas before with a stable DC supply it had just sat there and done nothing. The open circuit voltage of the battery at the time of writing now shows 4.5 volts so there is a way to go yet. It could be a couple of weeks or so before the battery is as recovered as it ever will be. In reality I can’t see them ever being “as new” however a trick worth knowing about and trying when salvaging neglected lead acid batteries.

Not to self if trying this with an old car battery check the electrolyte levels first and be prepared to except that the plates could just be mush and the battery beyond recovery.

Indoor environment sensor with ESP8266

Burnell Bot Breadboard

As part of our hacking the space project, we’re building a network of sensors and effectors in our space. Communicating over WiFi using the MQTT protocol, the idea is to make lots of data about the hackspace easily available for members to use in their projects, and to make it easy for members to add their own data streams to the space’s network of things.

One of these is the Burnell Bot, responsible for monitoring motion and light intensity, plus temperature and humidity. These data will end up being used to automate the hackspace’s lights and heating, as well as forming part of our security system. In the meantime, they’re flying over the WiFi in our hackspace ready for members to monitor and use however they want.

At its heart is an ESP8266-12E, sitting on a handy breakout board; you can see its silver enclosure covering most of the board, plus the etched WiFi antenna. This takes input from a BH1750 light sensor over I2C, a passive infra-red motion sensor that sends a digital HIGH signal in response to movement, and the DHT22 temperature and humidity sensor. Thanks to the support for ESP8266 in the latest Arduino IDE, the BH1750 and DHT22 are used via their existing Arduino libraries. A couple of warning messages pop up when compiling, but the code runs without issue. The motion sensor, of course, is monitored by simply checking the status of a GPIO pin set to input. Data from each sensor are transmitted over MQTT in their appropriate topics, subject to dampening (e.g. change in light level must exceed a certain threshold before being reported) and throttling of message rates.

Now that our planning permission has gone through (the downside of being hosted in such a great, historic building is dealing with its listed status) and we’ve refurbished our ceilings ready for the wiring grids to be installed, expect to see a few of these appearing in the space and start thinking of things to do with the data!

Personally, I want to add sensors for carbon dioxide, carbon monoxide, nitrous oxide and particulates, to keep an eye on our air quality and to try to get a sense of whether the reported effects of high CO2 / low O2 in classrooms (impaired concentration, amongst other things) affects our hacking. If you want to get involved in this or other projects, get in touch or just look at our calendar and turn up to a session!

ATtiny 85/45/13 Programming Shield

Author: James Muirhead

ATTiny Programmer photo

This is a modified version of the programmer described on the High Low Tech Group’s page. I have however added a few customisations…

  • Reset buttons for both the ATtiny and the host Arduino,
  • Headers in paralel with the IC,
  • Rails for 5V, 3.3V & ground,
  • A mini breadboard.

This shield simplifies the development of ATtiny (13/25/45/85) projects giving you direct access to the ATtiny as if it were an Arduino Uno with the added convenience of an attached Breadboad with rails.

Continue reading

High Altitude Ballooning Update

So… With preparation for our High Altitude Balloon launch well underway, we thought that we would let the community know what we where up to on this challenge.

The bits that we are working on at the minuet include:

– The telemetry hardware (the radio transmitter sending GPS data ect)
– Selecting a suitably sized gondola (the payload box)
– Constructing a parachute
– Experimenting with different methods of reviving the telemetry data

The telemetry transmitter module is now in the stage where it is being made more permanent. It has been soldered on to some strip board with a whole host of components, including a GPS and pressure sensor.

We have been able to acquire some various shaped polystyrene boxes for gondolas. We just need to decide witch one will be the most suitable to carry our payload.

We have also been very lucky to have a group member construct us a parachute for helping the payload get back down to the ground in one pice.

December the 14th Build Day

On december the 14th we had our monthly build day at Access Space. We had a large array of 3D printers and electronic projects
being worked on, some of the things that went on throughout the day include...
- 3D Printing parts to improve the hack space
- Laser Cutting
- Tinkering with electronics

3D Printing parts to improve the hack space

We have been hosting our meet-ups at Access Space for around 9 months now. From the start Access Space has very kindly given us a space in there Refab Lab for us to store and use our 3D Printers. We where asked to put forward suggestions for in ways witch we
could improve the hack space. We discussed with Access Space about making it an easier space to work in. We decided to create and print some coat hooks. We drew up some 3D coat hooks in Open SCAD, a free open source 3D CAD programme.

3D Printed coat hook being drawn up in Open SCAD

Once the object had been Compiled and Rendered it was exported as a STL file, it could then be sliced and printed. altogether we
printed four of the coat hooks, in total we had three printers on the Job. Including the small foldable, portable printer that
has been made by one of the group members (we will try any get picture).

3D coat hook being printed

This above is this is the finished product. The coat hooks where mounted on to a pice of wood witch was screwed on to a shelving
unit.

Laser Cutting

One of the 3D printers that was brought along to the build day was a SUMPOD Delta, this printers X,Y and Z axis sit on three
threaded rods. Some pieces where designed using Ink Scape (a 2D open source CAD programme) and laser cut. The pieces where to
mount the stepper motors on to the printer.

SUMPOD Delta 3D Printer

Among all of this we also had some people with Arduino's creating projects, including light synthesisers.  

We would also like to thank Access Space for providing us with a work space and access to tools and machinery in there Refab Lab.
The next meet up will be held at Access Space on the on January the 27th.

You can keep in contact with us by following us on Twitter @SHHMakers or on our forum at: https://groups.google.com/forum/#!forum/sheffield-hardware-hackers