Gradle Generate Release Notes from Git

I thought my ‘Gradle Generate Release Notes’ script might be useful for others, so here you go:

If you are using the built in Gradle tool for Android Studio and you want to automagically generate release notes (or a list of commit messages) from Git then this little script might help (whilst it is pretty specific for Android Studio, it could easily be modified for any Gradle


I got the inspiration from this post over at coders kitchen – but it seemed a little to complex for my needs, so I cut it right back to just text based, and just dates and commit messages between the tags. More than sufficient for my needs.

Raspberry Pi P6 Reset Hack

I’ve been trying to get some code running on my Pi 2. The code has been ‘problematic’ to get running, and I’m running into frequent hangs on the Pi where I cannot initiate a new SSH or console session. It’s also complicated because the Pi is outside in the garage (I have a GPS hooked up so it needs some visibility of sky). That means that every time it hangs I have to head out to the garage, pull the micro USB cable, reinsert it and then start the whole ‘Edit, Compile, Run, Head out to the garage to Reset’ cycle again.

Anyway, in an effort to simplify things I was looking around for a way of remotely resetting the Pi without having a connection to it. I found a ton of sites talking about the P6/RUN header on the newer boards, but this was mostly just about adding pins to short out with a jumper or adding a momentary switch to do the same. What I wanted was something more like connecting an Arduino pin, or a pin from another Pi to the P6/RUN on the target Pi and forcing a reset that way. What I wanted was a “Raspberry Pi P6 Reset Hack” – unfortunately AdaFruit don’t sell a kit for that.PiP6PullUpResistor

I was initially concerned about the current that the watchdog Pi would have to sink on the GPIO0 pin, but looking at schematics it seems the RUN pin is pulled up to 3.3V by a 10K resistor – a little bit of Ohms law says this will mean 3.3v/10K = 0.33mA will flow, well within the recommended limits of the GPIO pins 2mA to 16mA

I have an ESP8266-12 laying around just waiting for this kind of thing, but for the sake of speed I opted for another Pi I had (already hooked up, working and configured). So this essentially came down to :

  • Solder header pins on the target Pi (the one to be reset)
  • Connect the grounds of the target and ‘watchdog’ Pis together
  • Connect a GPIO pin from the ‘watchdog’ Pi (GPIO0) to the RUN pin on the target Pi
  • Putting together a small app to force the GPIO0 pin low for a few milliseconds and then high again.


For the app to be run on the ‘watchdog’ Pi, I’m making use of the excellent wiringPi library. Instructions for downloading and building it can be found at
The code for ‘reset-app’ is simply (nano reset-app.c):


#define <wiringPi.h> 
int main (void) 
    pinMode(0, OUTPUT); 
    digitalWrite(0, HIGH); 
    digitalWrite(0, LOW); 
    digitalWrite(0, HIGH);
    return 0; 

… then to build it just execute :

sudo gcc –Wall –o reset-app reset-app.c –lwiringPi

Now when my target Pi hangs I can just ssh into the watchdog one, and run sudo ./reset-app and the target Pi reboots.
Also, when I’m done with this testing/hanging stuff I may simply connect a switch to the header for ‘’future ‘just-in-case’ things…


This is a QuickAndNasty™ solution. I am not responsible for any damage to your Pi, your electrics, your health or anything else – anything you do as a result of reading this is at your own risk.
Using this to reset you Pi can result in SDcard corruption !!   All calculations are off the top of my head, and could be wrong.

There are a ton of things to improve it also:

  • It relies on the GPIO pin on the watchdog ‘floating high’ while it is an input – it really should be set as an output (HIGH) at startup.
  • I’ve not tested what happens when the watchdog Pi reboots – there’s a chance (likelihood?) that it will reboot the target Pi.
  • The ‘reset-app’ can be improved (drastically!!)

EDIT: I have tested what happens when the watchdog Pi reboots and, for me, it does not reboot the target Pi – however there is a chance (likelihood ?) that it will reboot the target Pi.
Anyway – enjoy, and let me know if you found it useful….

Quadcopter V1

So for the past few weeks, on and off, I have been focusing on hardware – building a magnificent flying machine – a quadcopter.

I bought a build it yourself quadcopter kit from ebay, just for quickness – it was around £120 and came with all the required bits to get started:

  • 4 x generic 2212 motors with mounts
  • 4 x generic 30A Electronic Speed Controllers (ESCs)
  • A power distribution board
  • 600mm frame (X layout)
  • A flight controller module (KK 2.1.5)
  • Propellers (2 x CW, 2 x CCW)

The only bits missing were batteries (I bought 2 x 3s LiPo and a charger) and the remote controller (I bought a FlySky TH9x and receiver). A few sundries were also needed – a little buzzer, some cable ties, tape, soldering etc.

After taking delivery of the various bits, I put the quadcopter kit together in a couple of hours, and I’ve been noodling around for the past couple of weeks with getting the right settings and configuration sorted out on both the Flight Controller (FC) and the Transmitter.

It seems that not many folks have the FC and FlySky combination that I had, but with enough googling around I found that I should have had the Transmitter set to ACRO mode rather than HELI mode. HELI mode only allowed me to get the sticks registering +-60 rather than the +-100 that I needed, also the trims couldn’t get to 0

The final setup for the transmitter was:

  • Mode Type = ACRO
  • Throttle = Reversed
  • Elevation = Reversed

Then I headed to the ‘Receiver Tests’ menu in the FC and using the stick trims to make sure all settings were trimmed to 0, and when I moved the sticks the correct values were displayed on the FC.

Make sure you have programmed your ESCs – you can do all 4 at once by removing power from the ESC, making sure your throttle is at maximum and all ESCs are plugged into the right connector then while holding down buttons 1 and 4 reapply the power. You should see the display saying ‘Throttle passthrough’, wait for the beeps and move the throttle to minimum then let go of the buttons, you should hear more beeps and your ESCs should be calibrated.


The litmus test for me is arming the unit, giving it a little throttle so the props spin and then holding it in my hand. Dip each of the motors and make sure it speeds up and the quad tries to level itself, then hold it level it again and make sure the motor slows again. I find this test, as well as giving it a bit more throttle and making sure it tries to lift as a great indicator that everything is set up correctly.

When that’s all working correctly, you know your quadcopter is ready for flight.
Outside, open space, little or no wind, time for the first flight – give it throttle, have the quadcopter lift then reduce throttle and let it land. Now the basics are out the way time to test out the maneuverability and do the PID tuning etc to get smoother flying.

Next up is attaching a camera – maybe a Raspberry Pi with a USB camera, or an unused smartphone.

essay whether you sustain time odd in this trial stop sites for essay writing Its well-nigh consanguineal to purchasing an efficient, essay-producing robot, solitary we dont hold to coldness, thickened interactions essay writing software reviews pc – Thither was a whether some groups get us so the tall act of children in the community who

Git – Push to a new remote server repository

Short reminder to myself on how to create a new server repo and do the initial push to it from a workstation.

On the Server:

cd Repositories
mkdir Project.git
git init –bare

On the Workstation:

cd Project
git init
git add *
git commit “Initial commit”
git remote add origin
git push –u origin master


Baking Pi – Part 2

The first part of this ‘getting things up and running’ series can be found here.

In this post I wanted to outline what was required to set up Wi-Fi and to get a Microsoft LifeCam 6000 working, providing a web page with the camera image streaming.

So, Wi-Fi… I bought a £6.99 USB Wi-Fi dongle from eBay. After plugging it in and rebooting the Pi I opened a SSH session to it and typed ‘lsusb’ This lists all the usb devices, and I could see the Wi-Fi adapter in the list as a Ralink RT5370.

First thing was to get the drivers – doing an ‘apt-cache search ralink’ found me the correct package (firmware-ralink). On issuing ‘apt-get install firmware-ralink’ it told me that the version I had already up to date – great it seems the Raspbian ‘Wheezy’ image comes with it installed.

So, it was just a case of setting the Wi-Fi options and giving it an IP address (static). I do this directly in the interfaces file. So…

  • From the command line run sudo nano /etc/network/interfaces
  • Change "iface wlan0 inet dhcp" to "iface wlan0 inet static"
  • below this add…
  • address
  • netmask
  • gateway
  • also add the following Wi-Fi options
  • wpa-ssid YOUR_SSID
  • wpa-psk YOU_KEY
  • wireless-power off
  • Now reboot (sudo reboot)

You should now have a Wi-Fi enabled Pi.

lifecam6000For the webcam, things were a little trickier… A lot of people are using ‘motion’ for setting up security cameras, as it does motion detection and can spit out images or movies when some motion is detected as well as do time-lapse and provide a web based video stream for viewing in a browser. However, this was overkill for what I had in mind (just simple streaming of the video), and it also uses a lot of horsepower.
So instead I selected mjpg-streamer, an open source project hosted on SourceForge.

There are no prebuilt binaries for the Pi, so it’s a case of building it yourself – not too difficult…

First get all the dependencies…

  • sudo apt-get install libv4l-dev
  • sudo apt-get install libjpeg8-dev
  • sudo apt-get install imagemagick

I tried installing subversion to check out the code, but the svn urls have moved around and it wouldn’t let me do a checkout as it couldn’t find the correct url, so instead I just downloaded the zipped tarball and extracted it…

At this point I tried to do a ‘make’ but it failed stating it could not find linux/videodev.h. A bit of noodling around found that I had a videodev2.h file, so all that was needed was a symbollic link.

  • ln –s /usr/include/linux/videodev2.h /usr/include/linux/videodev.h

Now to build it…

  • make clean all

I did get a few error towards the end, but the key elements built correctly (I think it was just a plugin or two that failed to build, so I simple glossed over that).

Now you can start the application manually with the following command line:

  • ./mjpg_streamer -i "./" -o "./ -w ./www"

.. but what we really want is to start it automatically when the Pi boots so…

  • sudo /etc/init.d/webcam

… and add the following text to it…

# Provides: mjpg-streamer
# Required-Start: networking
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Starts mjpg-streamer
# Description:

#! /bin/sh
# /etc/init.d/webcam

# Start / Stop the webcam streamer
case "$1" in
    echo "Starting webcam streaming"
    /home/pi/mjpg-streamer-r63/mjpg_streamer -o "/home/pi/mjpg-streamer-r63/ -w /home/pi/webcam/mjpg-streamer-r63/www" &
    echo "Stopping webcam streaming"
    killall mjpg_streamer
    echo "Usage: /etc/init.d/webcam {start|stop}"
    exit 1

exit 0


Now the final touches of making it executable and making sure it get started…

  • sudo chmod 755 /etc/init.d/webcam
  • update-rc.d webcam defaults

.. and the final part is of course viewing your handiwork – so open a browser and type :8080">http://<your_pi_ipaddress>:8080 and you should be able to see the webcam image.