In the previous foundry post, we made the foundry hugely more efficient by adding a fan to force air into it using an old hairdryer. Although it made the fire super hot it introduced many problems. It forced the tiny pieces of ash sitting in the foundry into the air, and towards anyone in a 2m radius. Some of the fuel also gets forced out which makes it less efficient. Bad all round, especially for the neighbors clothes on the washing line, which probably smelt smoky after each burn. We came to the conclusion that we needed a lid to hold in that glorious heat.
We went to the internet and found the easiest way to make the lid is to just make it in the same way we made the foundry itself, but with a few modifications. Firstly we made much less, we only want a lid about an inch thick (2.5cm) for a lid. This size was thick enough to be strong, but not so thick that it was unusable. We also used a plastic bucket rather than a metal one. As plastic can be bent it allows some movement to get the set lid out of the bucket without breaking either. You also need something to make the hold in the centre, we used a bottle, but if you can find something with a nice base then use that, the bottle had its drawbacks. Make sure the item you use can be ruined, and has a slight taper, because it needs to come out when the lid is set. Once put together we left the lid for a day to set, just like with the foundry.
The new lid sitting inside the bucket setting, with the bottle in the centre to make the hole.
As you can notice in the above image we added a way to pick up the lid. This is firstly really useful to take out of the bucket, but will also be useful when we are actually using the forge and things get hot. It is much easier if we have something to actually grab on to. We used standard off the shelf D rings from ScrewFix, but anything that has a good ring and plenty of metal for the mixture to mould around then it should work fine. For us, it made the act of picking up the lid much easier.
The first attempt to lift the lift after it had been taken out of the bucket.
So once it was out, we left the lid out of the mould overnight, and then tried it out the next day. For the first burn with it we were gentle, and barely put on the hairdryer. This was to make sure that we didn't damage it, we really wanted to help the curing process. You can see the difference in the below picture though, all the heat is confined inside the forge, and no ash or particulate is coming out the top. To add or remove the lid from the top we used kitchen tongs, as the D rings get very hot. We also hd head gloves to make sure we didn't burn ourselves in the process. Safety is paramount if doing this yourself. It is easy to make a new lid but it isn't easy to fix third degree burns! you have been warned. That being said, from our perspective that is a working forge! Now onto melting things.
The full setup, with the lid on it , the first burn was much gentler to allow the lid to set better, we though an extrer first burn could damage it.
Hope you enjoyed this post, hopefully there will be another update soon, but for now search the rest of the blog, as there are some awesome images of rockets, interesting history about aerospace, and you might learn something about electronics. Thanks for reading.
As part of my degree I had to complete a project as part of the third year in the field of robotics and electronics. I chose to make a robotic platform, a simple idea that could be completed to a high quality with the right amount of effort. What is a robotic platform I hear you ask? well it essentially is a small buggy/rover that that moves around an assigned area completing simple jobs such as transporting goods, picking up parcels or any job that needs a moving vehicle. Usually autonomous, and very expensive, the majority of systems are very application specific. Some simple systems without any sort of control system can cost tens of thousands of pounds, and are not easy for the average employee to operate. Tackling the problem of expensive, application specific robotic platforms was the basis of my project.
Named the Semi Autonomous Robotic Platform, the idea was very simple, make a modular system, with building blocks that could be easily interchanged, and didn't cost the world. These modules were things like motor controllers, sensors and power systems. If a user had a working platform built from this system, it would take minimal effort to swap out any of these modules to bigger motors or better sensors. This means a user can make a robot and only buy the bits they need, and even make their own modules, as long as they fit to the standard written as part of the project.
The initial block diagram of the system, showing how the modules can be controlled in hierarchy structure.
In most robotic systems, mainly to keep costs cheap, there is one controller that controls everything. This idea makes sense for small integrated systems that don't need to change, but doesn't really work when systems need to be dynamic. For instance, say you decide that your DC motors driving your robot aren't giving you the control you want. You source some stepper motors, but this means completely changing the motor controller and therefore the software that controls it. Because one controller is in charge of everything, the software for the whole system needs to be re-written, and re-tested. That small change could have affected any of the other systems that that controller is in charge of. Make a change that breaks something important, you could set back a project weeks. This shows how painful a setup like this can be, especially when it starts to become a complex robot. Add on top of that the potential for computer intensive algorithms being used on the robot, like route planning or SLAM, and that controller suddenly has a lot to do. My system design separates these jobs out to a selection of individual controllers, such as a system specifically for motor control, or power systems. These controllers can deal with the nitty gritty hardware, and leave the master controller to orchestrate a higher level version of control.
My design, near the end of the project, with the mecanum wheels, ultrasonic sensors and multiple controllers.
The added benefit of separating out all these jobs means that multiple engineers can work on the same robot, at the same time on different areas and not be worried about breaking the other person's design. The system specification defines how the modules interact in terms of communication speeds/type, the way to alert other modules and how those communications are scheduled. The master controller (shown in the system block diagram in green) schedules all these communications and decides which modules need specific information. Warnings, control signals and user inputs are all calculated and scheduled, then communicated to and from the required modules. A power system doesn't care that a user has pressed a button to scroll through an LCD screen, and the master controller means it doesn't see it.
The above video shows how the robot moves with its mecanum wheels, and how it can easy move around environments. I will explain the more technical parts of the project in a later post, but this simple idea became a very heavy hardware based project, rather than the software project it started as. I learnt about mechanical design, PCB design and good techniques associated with electronic design. For these reasons, the robot won the "Best Project" award for 2017. Thank you to: Cubik Innovation for help with electronic design, and providing PCBs, VEX Robotics for donating the wheels, and Altium Designer for providing their electronic design software. I would not have been able to produce the robot I did without them.
After creating my 1 bit full adder design found in a previous post, I decided to go for something a little more complicated. I wanted to prove to myself that the ripple carry system worked, so the obvious choice is to make a multi bit device. 4 bits seemed like a good amount, it's a value used in some early ALU's so it can be used in a future project. To make it more interesting I added in the ability to make the device a Subtractor at the same time. When you look at the schematic, it only requires one more device per adder, so it's not even an expensive thing to implement, but adds lots of functionality. As with the 1 bit adder, I have attempted to build this adder using only single logic chips.
The first stage is to know the logic circuit, its widely known and can be found pretty easily all over the web. I'm not going to explain how it's created (I can always make a separate post on that) but I can describe how to use it. The aim is for the device to take two 4 bit inputs (0 – 15), along with a carry from another adder. So the adder needs to be able to output a value between 0 and 31. In binary this can be shown as 5 bits, so we have 2 outputs. This the S output is a 4 bit bus, and the Co output bumps this up to the 5 bits we need to make 31. A truth table can be made for this but it would be 32 lines long, so too much for this post. You could regard it as a personal challenge if you want to attempt it on your own.
So I got onto Altium and made a schematic of this circuit using some of the low voltage 7400 LVC series individual logic gates that I used on the previous adder I made. They come in SOT23-5 packages which are leaded a nice size to solder. Plus they are a size where it's possible to probe the pins fairly easily. Luckily Altium shows the components as their logic symbols. Below I have shown the first two adders, the third and fourth are basically the same as the second one, which is the idea of the ripple carry adder.
I also added a few LEDs to show what parts are on and off. This means the user can see the inputs and outputs. These LEDs run off the 5V input voltage, and have 220Ω current limiting resistors in series with them. Also, I have put in some 0.1 inch header pins so it can be attached into a breadboard and maybe even a micro.
As a base of my circuit, I have decided on a double sided 100mm x 100mm board. This is quite big as you can see for the circuit I have made, but gives plenty of space for a soldering iron to get access. As well as this, it gives a nice amount of space for multimeter probes. I also tried to keep the individual logic chips in a similar arrangement as the schematic. This is meant to be used as a learning device, so it's useful for the chips to line up with the diagram. The header pins for the inputs and outputs are placed on opposite sides of the board to make it more obvious for the user to see it. And the pins have designators written on the board so the user can see what each pin does. The input and output busses are placed in fairly logical places, and grouped together. There is no point having all the A inputs intertwined with the B inputs. The pins for the power and ground are on opposite sides with their own headers, only one needs to be connected for it to work. The LEDs that are directly attached to the pins are placed closer to the logic circuitry, but labeled clearly on the silkscreen. Most of the routing to the LEDs is on the underside of the board, else the top could get confusing. All the designators for components have been made half the normal size due to the small amount of parts used in the project. The below images show the PCB layout I created with the top copper being red, bottom copper being blue, and the silkscreen shown in yellow.
As you might be able to see, I have tried to keep all the power on the bottom side of the board. This leaves lots of space for the logic signals on the top, where the user is more likely to see. As you can see, most of the inputs and outputs of the circuit are also on the bottom side. This is because the way the busses work and input into the adder needs lots of crossing over and would add confusion into the design. This is why labels were used instead.
To make it easier to see, I made a larger image of the first and last adder in the series. As you can see, the only real difference in them is that the first has the add/subtract input shown by an LED, whereas the last shows the carry from the previous adder (C0). This is because the A/D bit is attached to all the adders, but the first bit doesn't have a carry bit input. The carry on that adder is the input for the A/S. It serves the function of inverting the first bit, so that it works like 2's complement when in subtract mode.
The main downside to this type of adder is that is is very slow. Especially when you get to high bit amounts that you are trying to add. This adder will take at least 4 times as long as a single adder to add the two numbers together because the signal has to propage through 4 full adders. This problem is known as propagation delay, each logic chip will take a very short time to compute the output. Although this time is not perceivable by the human eye, if there are 100's of logic gates in a row, then the delays start to add up and be a problem. If this circuit is to be used in a computer, it could need to make calculations thousands, or maybe millions of times a second, and a carry bit adder is not generally good at that. There are other, faster adders that I will show in a future post.
One thing that has always been interesting to me is using logic circuitry in electronics. It's easy to implement something on a microcontroller in just a few lines of code, but the real challenge comes from making a boolean project using real logic gates. It's something we all learn about if you have taken a basic computer science class, or even digital electronics. One of the first circuits you ever learn about is the adder. It's pretty simple, teaches you how to cancel down boolean equations, and only has a few inputs and outputs. I have decided to try and make the circuit using real components, and see if I can get it to work.
The first stage is to know the logic circuit, its widely known and can be found pretty easily all over the web. I'm not going to explain how it's created (I can always make a separate post on that) but I can describe how to use it. The aim is for the device to take two 1 bit inputs, along with a carry from another adder. So the adder needs to be able to output a value between 0 and 3. In binary this can be shown as 2 bits, so we have 2 outputs. The S output represents bit 1, and the Co output represents bit 2. Below is the truth table I used, if you want a little challenge, try and get the above circuit using boolean algebra.
So I got onto Altium and made a schematic of this circuit using some of the low voltage 7400 LVC series individual logic gates. They come in SOT23-5 packages which are leaded and a nice size to solder. Plus they are a size where it's possible to probe the pins fairly easily. Luckily Altium shows the components as their logic symbols.
As a base of my circuit, I have decided on a double sided 50mm x 50mm board. This is quite big as you can see for the circuit I have made, but gives plenty of space for a soldering iron to get access. As well as this, it gives a nice amount of space for multimeter probes. I also tried to keep the individual logic chips in the same arrangement as the schematic. This is meant to be used as a learning device, so it's useful for the chips to line up with the diagram. The header pins for the inputs and outputs are placed on opposite sides of the board to make it more obvious for the user to see it. The pins for the power and ground are on the same side on both headers. The LEDs that are directly attached to the pins are kept close to them, and the track is fairly obvious to show where the signal is from. The silkscreen labels which LED designates which input/output. All the designators have been made half the normal size due to the small amount of parts used in the project. The below images show the PCB layout I created with the top copper being red, bottom copper being blue, and the silkscreen shown in yellow.
As you might be able to see, I have tried to keep all the power on the bottom side of the board. This leaves lots of space for the logic signals on the top, where the user is more likely to see. As you can see, not all signals are on the top side due to circuit constraints, but signals that do swap over are generally short jump, and straight lines, This makes it more obvious where the tracks go without having to flip the board.
So in a recent project I had to implement a 16×2 LCD on a PIC16F1827, but the system will work on most PIC microcontrollers, with slight changes to the code. For this project I am using MPLAB X v3.40, a free development environment, and a PICKIT 3, which can be bought at a number of stores online.
Start off by loading up MPLAB X, if you don't have it already, install it from the Microchip website microchip.com/mplab/mplab-x-ide.
Start a new project, by going to File->New Project… or by pressing Ctrl+Shift+N.
The project we want is a standalone project, it should be chosen by default. Next choose the device we want, write in the box PIC16F1827 there should only be one. We want to use the PicKit 3 for the programmer. I am using XC8 as the compiler, this is available from the Microchip to9 stawebsite. Finally choose the name of the project, and where you want to keep it. Then click finish.
LCDs have what is known as a parallel connection. This means that we send data 8 bits at a time, rather than serial where it is one at a time. The datasheet for the PIC is found on the microchip website here. The pinout is found on page 4.
Register Select (RS) pin, this decides which of the two registers that is getting written to. Either the instruction register (what the screen does) or the data register (what is shown on the screen). This is connected to A4 on the PIC.
Read/Write (RW) pin, this decides whether you are writing to or reading from the LCD. This is connected to pin A3.
Enable (E) pin, is to tell the LCD when data needs to be transferred. Pulsing this pin will write or read to the registers the data on the data pins. This is connected to pin A2.
These pins are defined at the top of the code, to make life easier for us later on.
Data Pins (D0-D7), are the pins that transfer the information between the LCD and the PIC. These are connected to pins B0-B7. So B0 is connected to D0, and so on until B7 is connected to D7.
Vdd and Vss are connected to 5v and GND respectively.
Contrast (Vo) is connected to a 10k pot between the 5v and GND.
If the LCD you are using has connections for a backlight, follow the datasheet for instructions, on mine I connect it t0 5v and GND.
Below is the function I create to send data to the LCD.
Calling this function in the main, like follows will send data to the LCD. Notice the #define at the top, these are declaring LCD_CMD and LCD_TXT. Basically, when the type is LCD_CMD the LCD is sent into command mode, by setting the RS pin. Equally, sending LCD_TXT will clear the RS pin, putting the LCD in character mode.
The information on the data pins will then get written to the LCD, by clearing RW. To actually tell the LCD that it needs to be sent new instructions the enable pin needs to be pulsed. Once this happens, the screen should be updated with the new information.
So after watching this video by Computerphile, I got inspired to make my own PC map solver. In the video they use Python, but I prefer C#, even if it takes a bit longer to set up and make. This Section is basically how I set up the system to import an image, turn it into a Bitmap, and then output the image to a file. Currently it is very rudimentary, and doesn't do any mapping, but in the coming weeks, it will be improving with different algorithms and systems to integrate it into my university final year project.
This will be written similar to a tutorial, but some prior knowledge of Visual Studio and C# would be beneficial. As well as this, it is always good to read around the subject and watch videos. Experience with systems is what makes you a better engineer! For this tutorial I am using Visual Studio 2015.
Open up Visual Studio, and start a new project by going to File->new->Project.
On the left hand side under Visual C# choose Windows. And pick Windows Forms Application. Change the name to Route Planner (or whatever you want to call it) and pick the location you want to save the project to. Then Click OK.
With the nice new form in front of you, drag the bottom left hand corner of the box, until it is about 750 x 450 pixels, this can be changed in the properties tab.
On the left hand side of the screens should be the Toolbox tab. In there find a Label. Drag this onto the form, I placed it in the bottom left corner. This will be the label we use to give us feedback on what is going on in the system.
While the Label is still highlighted, go to the Properties tab, and change the name to lbl1. I also changed the text to lbl1, but this isn't necessary.
As with the label, drag a PictureBox onto the form. Make it as big as you want, it can always be changed later, but this is where the map is going to be shown as an output.
in the top corner of the PictureBox is a small triangle, click on it, and change the size mode to zoom. This means that the image will be zoomed in to fit the box, as some of the images we will be using are small.
While the PictureBox is still highlighted, change the name to pbMap.
This is the basic bit done, now to make it do something, we need an event. To start, we will set it up to do everything as soon as the program loads, in a later tutorial it will be triggered by buttons. But for now double click on the form. This should take you to a new page called form1.cs.
There will now be a function in there called Form_Load() anything put in this function will be triggered as soon as the form loads up.
The code posted below currently loads in an image, converts it to Bitmap, and then converts back to .png to save it again (under a different name).
Firstly a new Bitmap variable is created, named startMap.
An image is loaded from a set filename is loaded into startMap.
The issue with leaving it at this point is that the image, although saved in a Bitmap, it's not really one. The colours of each individual pixel are indexed in the .png format, meaning we cannot directly manipulate them, in the way we would a Bitmap. In Bitmap images, the colours are in ARGB format, meaning each colour has it's own value, and can therefore be accessed.
To get the image in this format, a new Bitmap variable is created called routeMap, with the same width and height as startMap.
Using the Graphics class, the image from startMap is drawn onto routeMap in the new Bitmap format.
The pictureBox we created earlier is now used, by making it the same image as routeMap.
The label we created is also used, by updating the user that the file has been saved.
To prove it is the same image, routeMap is saved a .png file, and can be found in the directory that it is set to.
Notice how the image seems blurred, this is due to the picturebox zooming the image to fit the box. The blurring is anti-aliasing, and although slightly annoying demonstrates the image.