LS3020 refurbishment.

WARNING: Working on a laser cutter should only be carried out by a competent person because of extra high voltages generated to power the laser tube, over 20,000 volts with a possible 30mA current*, mains voltage present, the laser beam is invisible and will easily damage your eyes or start a fire. 

Eye protection is recommended when working on the laser cutter with the power on, the safety covers open or modification of the safety circuits. The safety switches/sensors should disable the laser when a panel/lid is open, their operation needs confirmed after working on them. 

*30mA is enough current to affect the operation of a human heart this could therefore kill. 

dirty ls3020 laser cutter

I have been lucky to been gifted a LS3020 laser cutter that was surpluses to requirements at Makespace. The LS3020 is a Chinese cutter specified and imported into the UK by 

The LS3020 is a tabletop A4 CO2 35W laser and needs a USB security dongle to run the supplied Newly Draw software, unfortunately the dongle had been missed placed. 🙁 I checked on and a replacement dongle would cost £150. 

inside the laser cutter showing the dirty bed
The bed

The cutter had not been used for at least 3 years and needs a deep clean. I did not want to go to the trouble of cleaning it if it was not working so I decided to test it first.   

First, the air compressor, fume extraction and the water-cooling pump had to be connected. 

All three of them plug into sockets on the rear of the laser, first issue is that the water pump socket does not hold its’ plug well and is unreliable. This is temporary solved by wedging a piece of card under the plug. I switched on the laser cutter, the head homed, and the water pump started to circulate water through the laser tube. I left the pump running for 10 minutes or so, then checked the tube for air bubbles. Bubbles in the tube can kill an tube in seconds and have to be avoided. This was a great start, it proved that the stepper motors and home switches were OK. Next up was to test the air compressor, the compressor is controlled via a switch on the laser control panel. I switched it on and happy to report that it Worked.

cardboard with a burnt hole
The hole

 The next test was to fire the laser, the laser power is set manually with a pot on the control panel. For this test I tapped some cardboard over the head mirror portal, close all the doors and lid, when I fired the laser. It burnt a neat hole in the cardboard and looked to be even, this is a good sign that laser is in alignment, further checks and tests to be done when I can control the laser head. 

So, what is next? 

Currently I have no way to cut any designs and control the laser cutter, some options are. 

  1. Buy a dongle and use Newly Draw software to control and import designs to cut/engrave.  
  1. Replace the controller for an open-source design and use an open-source G-code sender to control the cutter 
  1. Replace the controller for an open-source design and use proprietary software. 
  1. Replace the controller for a proprietary design and use proprietary software. 
  1. Replace the controller for a proprietary design and use open-source software 

Option 1.

My main objection to this option that it will cost £150 to buy the dongle to run 8-year-old software that needs Windows XP to run. 

Option 2.

I like this option; I need to see what the options for both. 

Option 3.

Same controller for option B, with proprietary G-code sender. The disadvantaged of this option is that good software can cost a lot of money.  

Option 4 & 5.

Proprietary controller has several issues, cost being the first one, they start at a few hundred pound and climb quickly into silly money, the cheaper ones normally use proprietary software. 


I need to research the open-source software options and finding out what open-source controllers they can control will lead on to what open-source hardware to look at as my next step. The other thing that I must sort out are the rear power sockets on the laser cutter. 

Hello World

Welcome to the blog of the Pi Wars Robotics team Bad Pidea, our members are:

Brian Corteil
Position: Herder of Robots

Brian at the last Maker Faire UK 2018 🙁

Robert Karpinski
Position: Forger of Electrons

I just don’t have the words for this!

Tom Corteil
Position: Ace Robot driver

Bye for now

Robot control and a menu

I have been taking part in Pi Wars since it started. The first year I got in with a reserve ticket, finished in the lower 3rdof the competition and was determined to come back next year and do better.

One of the many issues I had that year was not having a menu system to run the challenges code, a way of shutting down/rebooting my robot and finding out information like the robot IP address or battery voltage.

The next two Pi Wars, I used a touch screen hat with a menu to select the challenges code and manual mode plus display useful information. This worked well and used modified code from Spencer Organ’s internet radio project link here ( For Pi Wars 4 I used a SSD1306 OLED 128 x 32  to display the menu and information, the joypad ‘D’ pad to change the options in the menu and last years Pi Wars I run out of time and did not end up implementing a menu system and repeated most of the issues I had the first year. 

This year I’m not going to repeat that mistake!

This years robot Sherpie is a rover with four silly sized large wheels at each corner and goggly eyes. Sherpie has a Raspberry 3 model A for its brains, a Red Robotics Redboard+ motor driver hat for contolling the motors, servo and other stuff plus a daughterboard for comm’s, a SSD1306 OLED display for displaying useful information and the menu system .

Before I go any further I must mention that Neil gave me a Redboard+ hat to test and he only asked for me to give my feed back.

Mini review of the Red Robotics Redboard+ 

The Redboard+ is a hat sized motor driver that packs a lot of features into the hat format. They include

  • Built in BEC only need a single power source required to driver the motors and Raspberry Pi.
  • The really useful header breaks out Physical pins 1 to 10, that’s 5v, ground, serial,  i2c, and GPIO 4.
  • Up to 6A per channel, 
  • Battery voltage monitoring
  • 4 channel ADC one channel is dedicated to monitoring the battery voltage.
  • 4 5V outputs 
  • Spare GPIO pins are broken out to 3 pin headers with 5V and GND.
  • 3 x i2c headers
  • On broad RGB LED.
  • Power switch
  • Programmable button

Adding the daughterboard adds the following features 

  • OLED 128 x 32 SSD1306 display
  • Serial
  • i2c header for an i2c keyboard 

Heading to the Redboard page on GitHub, the readme is a great introduction to the Redboard+ with clear instructions how to install the required libraries and example code plus setup services for monitoring the battery and the user defined button. Neil has also supplied a pre-built image for you to flash to a SD card. Tried both methods and was able to get a robot up and running in a few minutes. Using a Pi Hut controller Sherpe respond well to input. The OLED screen displays your robot IP address if connected to wifi network and the voltage of the battery. The user define switch as been setup to display the IP address of your robot, when held in for a few seconds will reboot your robot  and if held for longer will turn off your robot.

In conclusion

 the Red Robotics Redboard+ is a good value robot controller with great features and an easy to use Python library with a well written guide how to setup your Raspberry Pi with example code to get you started. I was so impressed with the Redboard+ that I treated Bill my eldest son aka @jedifodder on Twitter to an early Christmas present.

The code

Despite the example code written by Neil for the Redboard+ I want to use a PS4 controller which Neil’s code currently does not support. I decided to roll my own, I based my code on the example code for my Tiny 4WD robot kit downloaded from Tom Oinn’s inputs Python3 library examples. The code is based on code written by myself modified by Emma Norling and Tom.

To use the code I had to modify two functions and add an import statement for the Redboard+.

The functions were set_speeds and stop_motors and the lines where the code updated the motors power was replaced with code for the Redboard+. Next I wrote some code for the menu and finally added code to display the menu on the OLED display.

After testing the code, I realised that the code would not run if the OLED display was not present, I added code to check that a display was attached and the display function prints to the console if a display is not discovered.

The main loop tests for changes in the status of the connected joypad sticks , button presses and updates as required. If the menu button is pressed the current mode is suspended and the menu is displayed. Pressing the up/down buttons on the controller will change the menu item and pressing O will select the menu item. This clears all menu flags to False apart from the select menu item. The code in the conspiring code block will be switched on.  When writing code for the code blocks, it is important to avoid blocking the main loop with sleep statements, instead of using sleep statements, it is best to save the current time, then check the elapsed time and if enough time as passed carry out task as required. An example can be seen in the home screen refresh routine. 

# screen blanking or home screen update
# home screen refresh time in seconds

currentTime = time()
if displayTimeOutFlag and (currentTime - savedTime > displayTimeOut):
displayTimeOutFlag = False
displayHomeScreenFlag = True

To add menu items you just need to update the menu dictionary and create a new menu test to switch the code on. The rest of the required setup is handled by menu setup code before the main loop is started. 

The menu dictionary

menu = {'Manual': True, 'Line': False, 'Maze': False, 'Toxic': False, 'Zombie': False, 'IP': False, 'Exit': False, 'Shutdown': False, 'Reboot': False}

Example menu item

if menu['Toxic']:
    # code for Toxic here


Add your code instead of the pass statement. If you wish to control your robot while running your own code you need to set the manual control menu item to True.

Menu[‘Manual’] = True

The code I have written is not the only way of controlling your robot there are other methods and techniques that can be used but hopefully my code is easy to understand and modify for your own robot. I have made the full code available to download from the Open Pi Robotics project GitHub repository.

LiDAR on the cheap using the HLS-LFCD2. Pt2

A quick recap, I brought a cheap LiDAR from Ebay for around £30, see Pt1 for more details.

I started by removing the tiny plugs and fitting DuPont 2.54 headers(female) to the cables.

The next job was to make a converter board, so I would be able connect the LiDAR to a serial port, power it and connect the motor to the control circuit as according to the data sheet.

bottom of the converter

I connected an USB serial cable and started PuTTY, no magic smoke was released so far good. next I tapped ‘b’ and the top of the RiDAR start spinning and began spitting out data on the screen. hitting ‘e’ stopped the top spinning. I copy the output and pasted into a HEX editor to look at the data and could only see garbage!

LiDAR serial output with PuTTY
data in hex editor showing garbage

I next tried a some incomplete Python code written by partner in crime Rob, I butchered it, printed the data to PuTTY screen and saved the output, this look promising but still did not look right and looked to have errors and/or missing data.

Finally I done what I should have done at the start, I wrote a simple Python program that read the serial data and writes the data to a file.

import serial
import time

startTime = time.time()

with serial.Serial('com3', 230400) as ser:
    print('Start spinning')

    while (startTime + 20) > time.time():
        data =

    print('Stop spinning')


The code basically, opens the serial port, send the start command to start the sensor spinning and outputting data, then reads the data from the serial port and writes the data to a file. after 10 seconds it stops collecting data and sends the stop command.

correct data!!!!

Once again loaded the file into a HEX editor and the data looks to be correct with no errors! on this high note, I will end this post. In part 3, I will try to extract meaningful data form the data set! wish me luck!

LiDAR on the cheap using the HLS-LFCD2. Pt1

First of all let’s define what LiDAR is

“LiDAR is a surveying method that measures distance to a target by illuminating the target with laser light and measuring the reflected light with a sensor.”

taken from Wikipedia ( )

Pimoroni Pirates’ ToF VL53L1X breakout – image stolen from the Pirates 😉

The VL53L1X infrared ToF sensor is a simple form of a LiDAR sensor. and commonly used by Pi Wars robots for detection of walls and objects. One of the disadvantages of using them is that they only have a single point of measurement, to overcome this you need to use more than one sensor to get a better overall picture of the environment around your robot.

To get over the issue of having to use more than one sensor to get a better overview of the physical environment around a robot, sensors like WW2 radar were developed using lasers instead of radio waves. But there has to be a ‘but’ the available sensors are expensive, costing over several hundreds of pounds. There has been a movement towards lower cost sensors costing around £100. probably because the rise of robotic hoovers.

robot hoover

My team mate Rob sent me a link to a LiDAR sensor on Ebay. The HLS-LFCD2 for about £30. At that price I could get one to play with! As the seller was in the UK, it turned up in a couple of days. Comparing the item I received from ebay, with other examples on the internet and the single data sheet I found. It looked like there was a mount attached to the sensor. I removed the mount, then drilled out the mounting holes to 3mm using a jewellers drill and fitted 2.5mm PCB spacers.

link to datasheet:

Bottom with bracket fitted – Banana for scale
Top with 2.5mm PCB spacers installed after drilling out mounting holes to 3mm
Bottom view with bracket removed and posts fitted

Next steps are replacing the plugs with 2.54 headers, mounting on a plate with a stipbroad interface for power and conectting a usb serial lead for reading data from the sensor. I also need to test that I can actually get some sensor data then convert it to usable data.

See Part 2 for more details.

Bad Pi-dea – The Origin story

Bad Pi-dea was originally a hovercraft. Brian had competed at Pi Wars with a 4 wheeled bot, a 2 wheeled bot so why not do a no wheeled bot

## hover craft are cool ##

Had a good collection of parts

blower fans for lift

brushless ducted fans for thrust & steering

Development was started before the call to arms and more importantly the details of the challenges for Pi Wars 2020 event were released. When the challenges were published, we both independently came to the conclusion that it would not be possible to enter with a hovercraft 🙁 due that a hovercraft would be impossible to control. Rob suggested that we base our robot on the Russian off road vehicle Sherp.

The Sherp is not road legal, can cross rivers and ice fields. cross mud pits that stop after 4 x 4s. For your enjoyment here’s a video.

And here is Sherpie our Pi Wars 2020 test chassis, four wheel drive, 300 rpm motors, big wheels, currently the brains are Raspberry Pi 3 model A.