21 Mar

Installing and configuring Pycupi

There has been some interest in Pycupi from the wider community so I figured an install/configuration guide might be handy.

IMG_7041 (2)

Tank Girl – v-plotter CMY (3 pass) Pycupi spiral arc render A2 Stabilo Point 88 Fineliner

First off this guide assumes you are using a configured Raspberry Pi that is running a recent version of Raspbian Jessie.

Prerequisites

Python should already be installed along with PySerial. However we still need the Pillow library for image processing.

From the command line run:

pip install Pillow

If that completes without error you can move on to the install.

Install

From the command line (and somewhere in your home directory) run

git clone https://github.com/brianinnes/pycupi.git

That will get Pycupi. Inside the Pycupi directory you will find an Arduino/Stepper directory which contains the firmware for the Eggbot/Spherebot/Polargraph controller. A Python directory which contains the core Pycupi program and test scripts. A testImages folder that contains a few images. And a wikiResources dir which contains stuff that lives on the wiki.

cd into the Pycupi/Python directory and run

python test1.py

which will probably throw an error complaining about the serial port. Thats ok, we needed to run this to have Pycupi create the default config. The default config lives in your users dir (/home/some_user/.polargraph/config.cfg). You will need to edit a few settings to match your machine before you can do any drawing.

Note: A semi-colon denotes a comment in the config file. Any line starting with a semi-colon will be ignored.

Under the [Polargraph] section, configure the following (any settings not mentioned here, which are present in the config should be left as default):

  • pensize – not currently implemented – will be ignored.
  • machinewidth – This should be set to the distance in mm between your pulleys.
  • machineheight – The physical height of you machine measured in mm from the centre of your pulleys.
  • mmperrev – The circumference of your pulleys (in mm) or how much chord or chain (in mm) is played out for each whole revolution of a pulley.
  • setsperrev – The number of steps your motors make in each whole revolution.
  • stepmultiplier – The step multiplier applied by your stepper drivers (Pycupi firmware defaults this to 8).
  • serialport – The serial port your stepper control board is attached to (/dev/ttyUSB0 on a RaspberryPi connected to the ‘Arduino Nano dual stepper board v2.1’).
  • motoraccel – A time value in seconds that determines how long it takes the motors to accelerate to their fastest speed.
  • motormaxspeed – The maximum speed the motors are allowed to move in mm/sec (needs confirmation).
  • penup & pendown – not currently implemented. Configuration angles for servo are set in the firmware.
  • homex – The home position in the (horizontal) x axis, measured in mm from the top left pulley. This position can be anywhere you like. Suggested value would be in the middle of your machine.
  • homey – The home position in the (vertical) y axis, measured in mm from the centre line of the pulleys (imaging a line drawn between the centre of the pulleys, homey will be some distance below this). This position can be anywhere you like. Suggested value would be 120mm down from the centre line, but will be dependant on your machine.

For a graphical representation of machine size measurements, see this post.

Under the [Paper] section you can define your paper size and its position.

An example A3 page would be as follows:

  • size = A3 – The name of the paper size.
  • width = 297 – Width in mm.
  • height = 420 – Height in mm.
  • posx = 175 – The position (in mm) from the left edge of your machine to the left edge of the paper.
  • posy = 240 – The position (in mm) from the top edge (centre line) of your machine to the top edge of the paper.
  • margin = 20 – A margin (in mm) around the edge of the paper where the machine will not draw (usually where you tape the paper to the machine). The specified margin will be applied on all sides of the page.
  • pixels = 3000 – The resolution for this paper in pixels.
  • rotate = false – If false the image is not rotated. If true the image will be rotated.

Under the screen section:

  • screenX = 5000 – The resolution the plot simulations will be. When generating simulations (bitmap images of a plot), you can specify a higher resolution that your final plot so you can see more detail to spot potential issues before running a plot.
  • showImage = false – not currently implemented.
  • saveImage = false – not currently implemented.

Now when you run

python test1.py

the machine should spring into life and draw a rectangle filled with smaller rectangles.

19 Mar

New control electronics for Pycupi

Here are two new PCBs for controlling a v-plotter. These were designed with Pycupi in mind but should be adaptable for other drawing machines.

The first is an add-on board for a Raspberry Pi 2 or 3.

pi-2-stepper-board_frontpi-2-stepper-board_back

The second is a kinda mini motherboard for a Pi Zero (the Pi Zero plugs into this board).

pi-zero-stepper-board_frontpi-zero-stepper-board_back

Both boards are currently untested and will require additional software modifications to work (either modifying the Linux install to free up the serial port or to enable comms over I2C).

A caveat with the Pi Zero board… we haven’t yet run Pycupi on a Pi Zero. It should work, but it might be slow rendering jpg representations of plots.

Both boards also supply power to their respective Raspberry Pis via the 12v DC connector using a DC to DC converter module.

Also the Arduinos on these boards are 3.3v and run at 8MHz so there may be timing issues to address.

I’ve included a ‘Master’ power switch that kills power to the Pi/Steppers and Arduino. I’ve also included a single push button that doesn’t have any specific purpose yet other than it might be useful as a shutdown button for the Pi. Or it could potentially be used as a pause button to pause a drawing.

Before getting PCBs made, I need to wait for samples of the additional components, print off a paper copy of the PCB and test for fit. If everything looks good i’ll get some sample boards manufactured and post an update.

13 Mar

Pycupi v-plotter control software

MakeBmth held its regular monthly meeting at Eagle Labs Bournemouth on Thursday 10th March 2016. We plan to meet there once a month (the second regular monthly meeting will be held at the Uni or under the new Hilton Hotel – check the meetup group or forum for details).

IMG_7035

We spent the evening learning about Brians Python port/rewrite of Gocupi, called Pycupi.

Pycupi (and Gocupi) is a cut down firmware that implements a command queue, stepper motor and servo control functions. Along with a control application written in Python (or ‘Go’ in Gocupis case). The who thing is meant to be run on a Raspberry Pi (though you could in theory run it on any computer).

IMG_7028

Pycupi does the image processing on the Raspberry Pi and can (currently) generate simulations (jpeg images) of the expected output or it can plot that using a suitable stepper controller. The firmware in the Pycupi github repository is currently configured to work with my Eggbot/Polargraph electronics.

IMG_7034

We learned about the multiple co-ordinate systems that are working together to produce a drawing.

Native: The co-ordinate system that works in motor steps.

System: The co-ordinate system that Pycupi maps to the native co-ordinates.

Image: The drawing co-ordinates which defines the drawing area.

We looked at how the native co-ordinates are not Polar (Angle and distance) but is a position triangulated based on the length of the two motor strings or chains. To calculate the position we need to know the machine width and how many mm of string or chain each step of the motor represents and finally a we need a reference or starting point (home).

coordinates

A bit of trigonometry gives us the lengths of the strings/chains for a given position.

IMG_7037

We looked at the different renderers currently avilalbe in Pycupi.

Spiral Arc: Renders an image using tiny spirals of varying size & density and the whole thing plots in on an Arc path from a corner (Defaults to top left (NW)).

renderSpiralArc(filename, x, y, image_width, pixel_size, drawing_object)

  • filename = the image to render (jpg/png/bmp)
  • x = the horizontal position of the top left of the image (bottom left if rotated)
  • y = the vertical position of the top left of the image (bottom left if rotated)
  • image_width = how many pixels wide the render should be
  • pixel_size = how big (in pixels) the spiral elements will be (bigger = less detail)
  • drawing_object = the python object you created to represent the machine

Norwegian Spiral: Renders an image using amplitude modulation along a spiral path from the centre of the image.

renderNorwegianSpiral(filename, x, y,image_width, density, maximum_density,pixel_size, drawing_object)

  • filename = the image to render (jpg/png/bmp)
  • x = the horizontal position of the top left of the image (bottom left if rotated)
  • y = the vertical position of the top left of the image (bottom left if rotated)
  • image_width = how many pixels wide the render should be
  • density = how densely packed the pixels will be
  • maximum_density = pixels will never be more densely packed than this (Need clarification on how these relate)
  • pixel_size = how big (in pixels) the spiral elements will be (bigger = less detail)
  • drawing_object = the python object you created to represent the machine

SVG: Draws vector images. Currently implements paths but not stroke or fill. Will cope with most elements of the SVG specification so it will happily draw curved paths.

renderSVG(filename, x, y, image_width, p)

  • filename = the vector image to render (svg)
  • x = the horizontal position of the top left of the image (bottom left if rotated)
  • y = the vertical position of the top left of the image (bottom left if rotated)
  • image_width = how many pixels wide the render should be
  • drawing_object = the python object you created to represent the machine

IMG_7032

A Kandinsky part way through rendering with multiple colour separations.

IMG_7029

The machine on the left is running Pycupi and has an example vector plot bottom right. The vector on the machine on the right was plotted with the Polargraph.co.uk software.

 

08 Mar

Mould Making

messy workshop

Last Wednesday I ran a small ‘Messy Workshop’, where I introduced several students to the processes of moulding and casting. I only had a short amount of time – around 3 hours. Within this I had to squeeze quite a bit in, so I  put on my best motor mouth for the occasion!

I brainstormed what I could include, and got some guidance from the tech in the casting room – I’ll create some basic moulds using the vac former, a silicone mould of the same shape in order to do a comparison of the two processes, and a couple of different resin types;  polyester (clear cast in this case) and Polyurethane (Fast cast).

WP_20160301_15_29_39_Pro

After half an hour of me waffling on about the contents of each canister, types of facilities available, and associated H&S we created some basic alginate moulds and created a plaster cast of our hands / fingers.

WP_20160302_10_52_18_Pro

This was pretty decent and took us to around 11am, when we took a short break – this allowed for us to give the plaster some time to cure. We were all rather hasty in our de-moulding, and lost a few fingers, most people thought this was the most distressing thing they had ever seen, whilst others found the whole thing rather hilarious!

WP_20160302_11_31_25_Pro

Typical art college fayre!

After all that, we continued on to the resin room where we created the reproductions using the vac form moulds. I prepared several, but gave the option for students to create their own if they wanted to make more than one. I also showed the silicone mould off and we poured that one as well. Over the remaining hour, resin was mixed and moulds were poured.

WP_20160302_11_59_17_Pro

Well, onto one of the real reason I made this a forum post, was to show off some nifty mould making processes I had a go at. Not only is the nature of these mid week workshops a way to get some cool stuff (mostly hard skills) introduced to students, but is also a way for me to indulge my nerd and try and create / explore new ways of doing the stuff we do already, which can all be summed up as making.

Tuesday was spent mostly drafting in Rhino 3D some nifty tile pieces, the kind of thing we might look at 3D printing one offs, and then going off to reproduces using a variety of casting mediums. (or maybe in the future, we will simply 3d print the lot?), anyway – I made a bunch of tiles.

Render 2

render 1

a typical process would be to create a plastic / wooden / Lego box to place them in to enable us to pour silicone over.

Well, now we’re in CAD and can 3D print the form, why not add a mould box into the mix, print it all out, and pour strait away.

render 3

The next thing I went on to illustrate was the process of creating a shape from a two part mould.

render 4

The parts for a two piece mould

All the components we went on to make on the Wednesday were simple one piece moulds, with an open back – this enabled us to quickly make some shapes. I created both side A and side B, in Rhino, as if they were made from silicone. The components also included the pour hole and the bleed lines already in place. This is something that you would usually create by submerging the parts 50% on clay and sculpting out the pour and bleed lines.

The next cool thing you add are the ball bearings / marbles, as these create locator pins for both side A and B, ensuring that you don’t miss align the mould and create a miss cast.

In the real world, that’s a days work (sort of ) and is also rather messy, you have to take precautions that you don’t get clay all over your original work. Once you have one side in silicone, you dismantle everything, take it all out – and then re construct the box; this time with the silicone and the part in the bottom, and now you can pour a new batch of silicone on the top (silicone wont stick to silicone) and your on your way to having a two piece mould. Sounds tricky? It is until you do it yourself!

Well – that will all take 2 days what with the cure time, if I’m lucky – and I only have 3 hours. I do have the benefit at this point to a couple of hours to prep for the session however. I think to myself, what if I were to take the workflow of creating the walls for my simple shape and turning it into its own mould box, and creating the mould box for side A and side B of a two piece mould?! Well – here goes. Mouldception.

render 5

This is what the mould will look like, rendered blue to represent the silicone material! note the pour holes, bleeder lines and the positive and negative locators.

Everything went as planned! I created the mould boxes for side A and side B, poured in the silicone, and 12 hrs later, had the silicone in my hands.

render6

The silicone parts visualised next to their respective mould boxes.

A quick pour of the parts and we can see how things turned out. the pour hole could have done with being a little larger – perhaps we can use a syringe to force in the material as the working time is around 1 or 2 minuets.

WP_20160303_14_29_58_Pro

The two parts of the mould taped up and ready to pour

The bleed holes worked really well…. except for perhaps my positioning of them , I was still left with a hole in the first reproduction.

I was able to position the two together, make the pour, and 15 / 20 mins later I got the parts out. The striking thing here was how much they resembled the 3d printed parts!

and

The parts that I printed were done so on the ‘fast print’ setting so contain all the features of a fast 3d print – its really amazing how much detail is carried through the mould / casting process – and how many comments we got thinking the resin part was made by a 3d printer, as it had a similar weight, finish, and surface quality.

I’ll return back with some HQ images of the printed + resin parts later, so into the process I guess I forgot to document the later (more interesting?) steps!

DSC_0293

Collection of moulds, in both PLA and silicone.

DSC_0296

Plaster cast finger mountain

DSC_0309

DSC_0311

DSC_0312

DSC_0314

The two part moulds.

The principle is that you cannot cast material that goes hard (plaster / resin) into a rigid mould. So here you can see we played around and injected silicone into the PLA moulds.

In the silicone moulds of the same shape, you can see we have poured / cast the resin. the reproduction (minus the air bubble) is great! All details captured.

DSC_0319

The two types of mould for the larger tile piece. The ‘Vacform’ moulds and the silicone mould. The silicone moulds (condition cure) are only good for the Polyurethane resins (fast casts) and the vac forms for the polyester resin (clear cast).

DSC_0324

DSC_0284

DSC_0327 DSC_0331

Clear cast with pigments – and loosely mixed inside the vac form!