Thursday, January 29, 2015

Arduino and NRF24L01 for Quad-copter build

As part of my Quadcopter build, I am using a couple of Arduino's along with some cheap NRF24L01 from Banggood for the radio transmitter and reciever. The idea came from watching the YouTube channel iforce2d.

When I started developing (copying) the code for the NRF modules, I did a quick search for the required library. For no good reason, I opted for the RadioHead version. Part of my thinking was by using a different library from iforce2d, I would have to poke around in the code a bit more and lean something.

All went well with the initial trials. I managed to get the two modules talking to each other, and even had a simple processing script show the stick outputs by reading from the serial port of the receiver.

Things did not look so good when I plugged the flight controller in. For that I am using an Afro Mini32. With that connected to the computer and Baseflight running, the receiver tab showed a lot of fluctuations on the control signals.

Lots of poking , thinking, and even taking it into work to connect to an oscilloscope, it looked like the radio was mucking up with the timing of the PWM signal for the flight controller. Finally, I decided to give an alternative NRF library a try, and from the Arduino playground site, I selected this one. As per iforce2d, I think.

Well that fixed it. Although, at the same time I cleaned up my code and pulled lots debugging stuff out and changed one if loop to a while loop, so there is a chance that changing the Library was not the answer. Anyhow, it works well now. Just need some more bits to turn up and I can start on the actual copter!

Monday, January 19, 2015

Quad-copter Build Log - Part 2

Working Transmitter

After a bit of fiddling, the transmitter works. I have not tested it for range, other than making sure it works across the length of the house. At the moment it only has the standard NRF24L01 module. Although the high-power module has turned up, the antenna for it is still in transit.

As there is still no Quad copter to control, most of the testing has been done by watching numbers scroll up the screen from reading the serial output from the receiver. As this was getting painful, a simple processing script was written to display the control positions on the screen. 

Almost as soon as I started this, I wondered if it would be possible to get the processing script to pass the stick controls onto a flight simulator. A quick look at FlightGear turned into a quick flight around L.A. That is a project for another day.

Flight Control Board

A flight control board has been ordered. I decided on the AfroMini32. This has the usual accelerometers, gyroscopes and a barometer. It also uses a 32 bit micro controller so should be a capable piece of kit. Hopefully it will all come together by the summer.

Monday, January 05, 2015

Quad-copter Build Log

Having enjoyed watching a series of videos on YouTube, I have been inspired to have a go at building a quad copter. I hope to include here some notes that will act as a reminder for myself. If anybody else decides to try this, please don't rely on this information alone, but please do your research.


This seems like a good place to start. If this bit can't be made to work, then nothing has been wasted on motors, batteries ESC's etc.

Rather than build an entire transmitter, an old DigiFleet transmitter will be gutted and used for the housing, control sticks, knobs and switches.
I had been hanging onto this transmitter, thinking that I would use it someday, but in the meantime, the NiCAD cells had spilt their guts and pretty much wrecked the circuit boards inside. So nothing was lost by tossing out the control boards, to make space for an Arduino. At the same time, all the parts were removed to give everything a good clean.

Some parts were ordered from Banggood to get started on the radio. An Arduino Pro Mini to use as the reciever, and Arduino Leonardo for the transmitter, and a couple of NRF24L01 boards for the 2.4GHz radio link.

Connecting Arduino to NRF24L01 Boards

After receiving the Arduino boards, the first thing was to load new Blink programs. This confirmed that they worked, and I could program them. The only issue was for some reason the Leonardo will only work as root. When it cam to connecting the the NRF modules to the Arduino, it was again the Leonardo that was proved to be more challenging. In addition to the power lines, the NRF's require five extra connections. Three of those connections are not available on the standard header, but are available on the ICSP header. As the remaining two connections can be assigned to any digital pin, it is possible to have all of the Leornardo's 12 analogue input pins free to use. This would make it possible to connect up all the controls on the radio, if needed.

The diagram below shows how the NRF boards were connected for initial testing.

With this set-up, it has been possible to communicate between the boards from different locations in the house.


The YouTube videos that started this mentioned a specific library for the RF modules. For no good reason, for this test, the Radio Head library has been used.

Learnt so far

  • Getting the radios to work was easy.
  • The Leonardo is not quite as simple to use as the pro-mini. Mainly due to the build in USB has to be handled by the Arduino software in a different way.
  • Choosing the Leonardo for the transmitter will allow me to use all 12 analogue inputs.
  • Just because a NRF24L01 board has a plug for an aerial does not mean that it is the high power version!

Friday, November 08, 2013

Android speculation

This is just some idle speculation on my part, and should not be considered as having any authority whatsoever.

Android to support alternative to Java

For some time, I have thought it must sit a little awkward with Google having Java so firmly entrenched in Android. Of course Google bought Android, so the original decision to use Java was not theirs, but have they considered moving away from it?

That would be a huge task. A number of things would need to be put in place before that could be considered. The development tools would have to be able to use the new language, and the runtime engine will have to be flexible enough to use the ne language as well as support the existing Java written apps.

Google have recently previewed a new IDE called Android Studio. Would this be better suited to supporting different languages?

With the recent introduction of Android 4.4, there is now the option to use an alternative runtime to Dalvik. ART. It would make sense to me that this would be an ideal opportunity to include the possibility of having an alternative programming language to Java.

As I said before, this is just speculation, but I really do wonder if by the time Android 5.0 comes out, will we be able to use something other than Java to write applications for android phones SDK? I know that is possible now with the NDK but that does not count!

Saturday, October 19, 2013

PDF editing and PS hacking

I have a PDF book that is a good reference. It would be great to be able to have it available on my tablet computer, but the PDF reader apps that have been tried are rubbish at navigating. Being a reference book, it is often required to skip to a specific chapter. This is slow when the PDF does not contain a sensible linked index. The only index it does have is in alphabetical order!

My initial thought was to use something like pdftk to split the book into separate files for each chapter. Having these in a folder, and using a file manager to select the required chapter as needed. This would work, but seems untidy. A better solution was required.

What I really wanted was to change the original PDF as little as possible. So I decided to add a single page to the start of the file with a linked list of the chapters. To do this required a little PostScript.

The Index

Create a file called, say, And in the file add some PostScript commands to create the index. First we can set a title. The word "Index" is placed near the top of a 4.5 x 6.5 inch page.

/Times-BoldItalic findfont 20 scalefont setfont
100 430 moveto (Index) show

Next the text for the chapters needs to be added.

/Helvetica findfont 12 scalefont setfont

20 400 moveto (Chapter 1) show
20 380 moveto (Chapter 2) show

The first line sets the font size, and then the next lines position and set the text. This is repeated as much as required.

Now we need to make the text clickable. This was done using pdfmarks.

[/Page 4 /View [/XYZ null null null] /Rect [8 393 52 413] /Subtype /Link /ANN pdfmark
[/Page 5 /View [/XYZ null null null] /Rect [8 373 52 393] /Subtype /Link /ANN pdfmark

The coordinates for each rectangle needs to align with the relevant text above, and the page number adjusted to point to the correct page in the PDF document for that chapter. This part was a bit long winded, and I am sure could have been made better with some more fancy PostScript tricks, but at least this works.


The Index was intended to go at the front of the PDF file so that it was the first page seen when the document is opened. If this was placed there directly, I would have to adjust the page numbers above by one to account for the extra page taken by the index itself. This would work, but caused an issue with the existing index in the PDF. This would also then be out by one page. So it was decided to put the index as the last page in the PDF. This way it would still be easy to find without disturbing the rest of the document.

The code to combine my new index with the existing PDF looks like this:

   -sDEVICE=pdfwrite \
   -dAutoRotatePages=/None \
   -sOutputFile=temp.pdf \
   MyBook.pdf -f

This adds the Index to the back of the PDF MyBook, and puts the result into temp.pdf.

The final stage was discovered by accident. I found that if I used pdftk to manipulate the book, it would update the internal links to keep them pointing to the correct page. So I could use pdftk to move the index to the front of my PDF as I first intended, and also, the existing index would also still point to the correct pages and not be shifted by one due to my added page.

The command I used with pdftk is as follows:

pdftk A=temp.pdf cat A228 A1-227 \
    output MyBook_Index.pdf

I now have a quick index card at the front of my PDF book that can be used to navigate to the required chapter.

Saturday, May 11, 2013

Tracing buildings from OS OpenData Street View for Openstreetmap

First, it needs to be said. Automatic tracing and dumping data into Openstreetmap is not a good idea. This page is something I have been playing with as an aid to manual edits.

This is a simple summary of the steps I used. If you need more information, then you probably should not be doing this.

Source Data
Grab some data for the area of interest from Ordnance Survey.
The Gimp
Find the tile required and open in The Gimp. The following steps should isolate the buildings.
  • Select by colour, threshold set to 26, pick the centre of a building, avoiding the antialiased edges.
  • Sharpen selection.
  • Fill whole selection with black
  • Invert Selection
  • Fill whole selection with white.
  • Save image in bmp format.
Make sure that you have the latest potrace that does geojson. With the required tif image from the OS data, run to following command:
potrace -b geojson -L XXXXXX -B YYYYYY -O 1 -a 0 tile.bmp
Replace XXXXXX and YYYYYY with the appropriate offsets for the tile being worked on. The required data is in the package downloaded from OS.
Quantum GIS
  • Create a new project with CRS OSGB 1936 / British National Grid. EPSG:27700.
  • Load a new vector layer, select the json file from potrace and make sure the CRS is as above. Make sure that the scale is making sense. It would be possible to load another layer of known good data as a check. Be sure to allow on the fly CRS transforms if the data you check against is not OSGB 1936.
  • Save the layer as a shapefile. Use the same CRS as the layer for the shapefile.
The shapefile can now be loaded into JOSM. The polygons should line up well with the OS OpenData StreetView background images. However, there will still be a lot of manual cleaning up required. Extra nodes need to be deleted and squaring up done.

I am not sure if this actually makes much improvement over simply clicking over the background imagery by hand. Maybe someone else can improve this process a bit more. This is really written as a reminder to myself incase I come back to this later.

All this is done with free software. The initial idea came from the openstreetmap wiki. There is also a python program that can do this called Mapseg, but it is not very fast on my little computer.

Thursday, February 21, 2013

Ubuntu Touch pre-Alpha on Nexus 10

First Boot

Curiosity got the better of me. Having seen a few YouTube demos of the new Ubuntu touch interface on the phone, I was excited to learn that the developer preview was going to be released for the Nexus 10. Not that I am a developer though.

First thing I needed to do was decide that there was nothing on my tablet that I needed. Once I was happy about that, I went ahead and followed the instructions. The only problem I had was after unlocking the boot-loader  the tablet would not boot up. It was stuck at the boot animation. As I needed to be in Android to complete the next step, I had to reinstall Android first.

After that little hiccup, it all went fine. Then I was presented with the image above.

There is still allot that does not work. Most of what does work, works well. There are many rough edges, and a few little quirks that no doubt will be adjusted over the next few months. The one thing that did strike me was the lack of a back button. That was probably the most unintuitive aspect to the interface.

It seemed that allot of what was working were internet apps. Gmail, Maps, Twitter, Facebook etc. And they all thought they were running on an iPad.

So far it seems like a good effort. Not sure I fully grasp the point though. It seems to be trying to do what Android does, but differently. What I was hoping for was something more like the Ubuntu Desktop. For that I would need at least a terminal, ssh, vim, LaTeX, apt-get etc. If proper user access control is implemented, that could be a real advantage.

In the meantime, I will be running Android on my tablet, as I only have the one. It would be nice to have a spare that I could keep on Ubuntu so that the development can be tracked. In a few months time, it may be worth trying again.

It is going to be interesting to see where this goes.