Multicopter Update

Here's a short update on ideas for the octocopter I'm going to make. I haven't spent too much time thinking of ideas recently as I've been too busy with basic electronics instead.

General update

Well, its been a month or so since my last post. Since my last post, I've had uni exams and now two thirds through my break and thought it was about time to post an update. I've been playing round with a couple of ARM development boards and trying to get some home brew PCBs eteched.

My Journey with the Raspberry Pi

So in an effort to clean my blog up and stop having posts that cover multiple topics which is bad for searching and finding useful information, I'm consolidation topics. This is a consolidation of previous posts on information on the Raspberry Pi.

ARM Startup and Compilation and the Relevant Files on the STM32F4-Discovery

Author: Richard Ballard

Date Created: 30/05/13

Date Modified: 23/06/13

Version: 2.0

I've revised this post to make it easier to understand. The previous version was written during my university exam period so it was a tad rushed.

This tutorial is about understanding how an ARM microcontroller starts its code and what is needed for this to occur. I will very quickly go thorough how the basic process and then get stuck into the key files that are needed. So to make this tutorial too generic, I'm using the STM32F4-Discovery Board as the target, so the file names and code will be geared towards this but should be easily translatable to other microcontrollers.

After I've discussed the startup process in basic form, I'll discuss the compilation process. This includes what the linker does, how the library is connected to our code and then what the make files does. The makefile is equivalent to how IDEs compile everything automatically but are much more flexible.

After I'll then discuss the startup file (startup_stm32f4xx.s) then move onto the linker file (stm32_flash.ld), makefile and some basics of the peripherals library provided by ST. The peripherals library is a set of functions that provide an easy to use interface to manage the registers on the microcontroller. All ARM Cortex-M based microcontrollers should have something similar provided by the manufacturer. If one is not provided, it should be very easy to create a similar library. The files used in this document can all be downloaded as part of Jeremy Herbert's STM32 Template from https://github.com/jeremyherbert/stm32-templates/archive/master.zip. They can also be downloaded from ST (minus the makefile) by downloading the STM32F4-Discovery Firmware Applications Package. The code in Jeremy's templates are from the IO_toggle example program in the application package.

Core Multicopter Designs

So this post should be a very long post. I've compiled it since the last post but I've had a few days of clear thinking where a lot of ideas have come to me. Its mostly on designing of the copter I want to build but there is also a bit on electronics. From this post onwards, I'm going to try and have an introduction paragraph so that the posts are neater. I'll then add breaks so that the entire post is not on the blog home page, making it look messy.

So with the copter design in this post, I've split it up into sections, these are mechanical, electrical and a combination of both (which is actually first) plus some extras. The mechanical section is then further spit up into rotors (and related), centre console, material (carbon fibre/fibre glass), camera mount/gimbal, bearings and then finally the electrical influences of on the mechanical design of the copter.

Multicopter Design ideas and some electronics

So I've finally finished my tutorial on how to setup Eclipse with all the tools needed to program an ARM chip. It took me ages as I kept having issues with things not working as expected. I guess, the reason for this is that, people use propitiatory software and don't use these alternatives. The reverse can also be said though, people use propitiatory software as there are quirks with the free alternative. Anyway, I'll start some coding tutorials soon, but I have uni exams in 4 weeks so may take some time. I'll try to make them a series so are easy to follow. Talking of which, I haven't found any community websites for ARM chips (like AVR freaks is for AVR) so that's a shame. I think without this community, there is not an easy pathway to learning ARM coding without doing specialised courses at university's or learning on the job.

OpenSource ARM Development using Eclipse and OpenOCD

Author: Richard Ballard

Date Created: 15/05/13

Date Modified: 19/06/13

Version: 1.1

This tutorial is about using open source products to create a development environment that can be used to program various embedded systems. I'll be focusing on ARM based chips and in particular the STM32 flavoured cortex chips.
 

I'm doing this, as all the current recommended tools are expensive (unless crippled) and so are inaccessible for students like me. More importantly, these tools don't operate under alternative operating systems such as Linux and Mac OSX. The open source community has built a large range of tools for the individual components and these support a large range of devices but these tools are all developed separately. Some of these don't have very good documentation while others seem overly complicated. I will be using Eclipse with a couple of plug-ins as the IDE, with the tools behind being arm-gcc-embedded toolchain, which is maintained by ARM itself, and has no restrictions. OpenOCD will be the debugger to talk, via adaptors, to the chips (which for this tutorial will be on a development board). I was going to write this with the aid of an Olimex ARM-USB-TINY-H JTAG adaptor and an Olimex H103 development board but these seem to have a long lead time on delivery. So while I'm waiting, I decided I would buy a STM32F4-Discovery Board which incorporates an STLINK adaptor onboard.

To automate the building process I'm going to use make rather than Eclipses internal build system.

To fully use this tutorial, I'll assume you want to be able program ARM based systems and as such willing to stumble your way through the steps to get to the goal. What I mean by this, is that to install some parts and configure them, I will be using a terminal shell. There may be GUI (graphic user interface, such as textedit) tools for these purposes but I won't be using these as they sometime mis-format, try to predict what you want or don't offer the option you want.

The layout for this tutorial is I'll first go through the tools we'll be using in part 1 and how they fit together. In part 2, we'll download and install these on our system. Part 3, we setup Eclipse with these tools using a sample project. By this stage we'll have the basics all laid out. Part 4 is some option extras we can use to enhance our development.

New Toys and more multicopter ideas

This week I got some new toys! These were in the form of a Raspberry Pi and a STM32F4-Discovery development board.

Design Stages for Octocopter

In this post, I'll talk about some design stages for the Octocopter I'll build. Its a fairly small post as I'm researching how to develop with Eclipse and ARM chips.

Multicopter Design Research

Since my last post I've done some research on how to design and build a multi-copter. I couldn't think of any interesting pictures to put aside the text so its all just writing unfortunately.

RepRap Funds and Multicopter

Well University has been pretty busy so I haven't been doing much on any projects at home since the last post. I did though, over Easter, have enough time to think up some more ideas. But a few small things before I start on these.

First week back at uni

So I'm back at uni now and this meant orientation week, so this week I have done next to nothing on the printer as I've been too hungover or catching up with people I haven't seen in a while. There are a few things I have had a look into though.

Frame Design

Over the last few days, I've been having a go in Inventor and doing a mock-up of my designs. (I say mock-up as explained later.) This has helped solved some of the problems I've had and provoked ideas on what needs to be done and changed. None of the pictures have the x slide/axis carriage shown as that is a more detailed feature and so I haven't designed even a basic version yet for the design.

Temperature Sensor, Frame Design and News

Last post I said I would get my thermistor temperature sensor working by the next post (ie this one). I have it working but its not calibrated and thus gives the temperature a few degrees out.

Thermistor Calculations

So this post is more of a maths orientated post. It incorporates maths equations powered by mathjax and so needs a relatively modern browser to work. Mathjax is a tad slow to load as its hosted on their site as I can't add the code to Blogger.

So I've decided I would test out some thermistors that I had bought a while ago. I was looking round and found it hard to find a solid circuit diagram and I couldn't find any equation to get from the ADC value to the temperature. I eventually had the great idea of checking how the RAMPS circuit was done for the RepRap System.

Binary Buttons

This week I managed to get buttons working after lots of research for debouncing buttons. I went with hardware debouncing as was far easier to do. So this is a small circuit that takes input from four buttons and outputs them on a LCD as binary and decimal numbers. Here's a video of what I mean. My fingers are quite big compared to the PCB buttons so you can't really see me pressing the buttons.

Debugging, Buttons, new purchases

Sorry this post isn't going to have any pictures as its all ideas, or what I have done but not finished yet.

So yesterday I realised I hadn't actually done a project that involved buttons on the AVR. I had done so on the TI LaunchPad which I had used before I got the AVR hence why I thought I had done so (I only swapped 3 months ago). Due to this I have decided I'm going to make another test program which will take the state of four buttons and translate them into a 4 bit binary and display the decimal reading on an LCD screen. As I was getting my breadboard ready for the SPI test, I moved another AVR onto the same breadboard and downloaded the LCD code. Worked so I then started tidying up the code to make it more of a library rather than all in one file. I finally got the code to work (the statements for getting printf to work are quite hard to satisfy) and so downloaded to the AVR and the display did nothing. I thought it must be the code as it seemed to be working on the original chip on the board but not the second. So I spent the next hour trying to troubleshoot the code, eventually going back to the original code that I posted last time and it still didn't work. Eventually I found out that one of the crimped pins within the header plug on one end of the LCD cable had come loose and so the LCD wasn't actually receiving the data! Good lesson to remember - check the hardware first, don't assume its all ok, specially cables.

Multiple chip communication and Code documentation

Well once again I've ended up on a forced hiatus. This time its because we're re-roofing part of our house and its taking far longer than thought plus I've ended up with lots of work clumped together so no time to relax in-between. This should finish next week sometime as I'm working constantly until Friday night and then I think I'll be back on the roof again, at least I've ended up with a good tan from it.

Anyway my next goal is to set up SPI communication between two microcontrollers (I just realised I should try three controllers very soon after). In my last post I said I was having trouble with the chip not functioning properly without the programmer attached. I've now fixed that with a 1uF capacitor. What took me so long was that I was unsure about the size as I had previously had a capacitor that was much too big and so didn't do any help. I had a look round and the Atmel documentation seemed to indicate some thing in the range of micro farads but the capacitor used on the Audrino Uno was a 100nF capacitor. As I didn't have any capacitors that size at home I tried a 1uF and it works fine (as in everything functions properly without the programmer attached) so I'll keep that for the time being.

So what I'm aiming for with my test SPI setup is to have a microcontroller with some buttons attached which then communicates to another microcontroller which then drives the stepper motor. In the setup with two microcontrollers, the microcontroller attached to the stepper will then reply with the success or failure as well as some properties of what it did such as how many steps from its original location etc.

I haven't thought about what I will do with the three microcontroller setup as I have only just thought of the idea while writing this post.

There is one problem with SPI other than those mentioned previously (I had a post ages ago when I talked about it) and that is that it is also used to program the device. So to overcome this I'm going to but some detect switches (that is at least what that are called on element14) and connect to some transistors to break the SPI connection when the programmer is plugged in. I won't have this on the final product just for use on the breadboard as the final product should be able to have the SPI disconnected more easily via a cable or similar.

So that is my next step for the electronics side of things. I'm very pleased with how things are going along at the moment other than having to spend so much time not working on the project!

With code, I keep saying I'm going to comment it and make it more readable. I've decided I'm going to use Doxygen for inline commenting and documentation. This is so I use a standard format for commenting but also so I can learn how doxygen works for other programming projects I work on. I've read some basic info online and I've now ordered a book. This is mainly as its easier to have a book to reference than going online all the time and all the information will be in one place. On a side note I've also bought a book on Autotools which means once I get most of the different electrical parts working, I can have the code of the main controller all auto configured and have options when compiling, such as methods of communications for getting the 3D data files to the controller (eg: SD card, USB and ethernet).

Just some quick other things, I'm going to see if I can setup SVN under AVR Studio as this would be a good way of keeping track of revisions of code plus I can use it to sync with code that I've written under OSX. The other thing I wanted to mention was that in the code in the last post, I should have also turned off the start up message on the LCD as when you first turn it on, it doesn't format the text passed too it correctly. The last thing is that I start uni again in just under four weeks so I'll be able to spend more time then thinking about the project.

Stepper Demo and Serial LCD

I have finally got my Stepper motor demo program working. As well as the problems in the last post there were a couple others. The first one of these was that I was trying to add a signed integer to an unsigned one. I fixed this which then made me realise I would have to change the number of steps for reversing from -1 and -2 to 7 and 6 respectively. This wasn't so bad but I then found that the motor was going quite slow compared to the test program. This stumped me for a while until it came to me that unsigned 8bit integer, is just that 8 bit not 8 numbers in total (4bit). So I put in an if statement that stated if the counter position was greater than 7 to remove 8 from it so to get back into the correct range of 0-7. I won't post the code in this post as I still need to tidy it up and comment it. Here is another video of the stepper motor, this time running the demo code. Basically it moves 45 degrees forward, 45 degrees back, then flashes a light (not shown) and then starts alternating going backwards and forwards 360 degrees.

The video is slightly better quality today as I took this on my camera rather than my phone. Same goes with the pictures further down the post.

So after getting the stepper motor finally working, I decided I would start on the LCD display but this time using serial communication. This started fairly well and had a good example in the manual for the chip. There was also a tutorial on AVR Freaks that helped. So I wrote all this up and sent it to the microcontroller and it started writing to the screen, the only problem was that it wasn't writing what it should have. This looked like the next picture, which looks like asian symbols but I think are just normal symbols that are part of the extended ascii sequence.

At I gave up programming and did some research before bed. I found another forum topic on AVR Freaks about UART corruption which is what I thought was happening. These posts indicated that it was most likely to do with the baud prescaller number calculated in the code. The next morning I tried moving around the number given in the manual for 8Mhz but no such luck. I had been seeming to get better results from lower numbers so I decided to try the number for 4Mhz which worked. I have no idea why it is running at 4Mhz as the fuses in AVR Studio say its running from a 8Mhz clock and not divided by 8 but there may be something I'm missing.

After fixing the communication I was finally able to turn on the back light of the LCD03-20x4. Next I managed to get some text written to the screen. With the help of this set of posts, again on AVR Freaks, I set up stdout for C to be the LCD screen and so printf now prints directly to the LCD.

I'll post the code for what I have done with the screen below. I would do a circuit schematic but really its quite obvious for the ATmega88a as there is only one UART module and so there is only one TX and one RX pin on the chip. I'm also quite tired tonight after redoing the roof on part of our house (doing the same tomorrow), so can't think what else I was going to post.

 #define BAUD_PRESCALE 51 // Started at 103 , down to 95, upto 112  
 #define USART_LCD_MAXLINES 4  
 #define USART_LCD_CHARS 20  
   
 #include <avr/io.h>  
 #include <util/delay.h>        // for _delay_ms()  
 #include <stdio.h>  
 #include <stdint.h>  
 #include <ctype.h>  
   
 void USART_Init (unsigned int ubrr)  
 {  
      /* baud rate */  
      UBRR0H = (unsigned char) (ubrr>>8);  
      UBRR0L = (unsigned char)ubrr;  
      /* Enable receiver and transmitter */  
      //UCSR0B = (1<<RXEN0)|(1<<TXEN0);  
      UCSR0B = (1<<TXEN0);  
      /* Set frame format: 8bit data, 2 stop bit */  
      UCSR0C = (1<<USBS0)|(1<<UCSZ00)|(1<<UCSZ01);  
 }  
   
 void USART_Transmit (unsigned char data)  
 {  
      /* Wait for empty transmit buffer */  
      while (!(UCSR0A & (1<<UDRE0)))  
           ;  
      /* Put data into buffer, sends the data */  
      UDR0 = data;  
 }  
 int USART_PrintChar (char character, FILE *stream)  
 {  
      USART_Transmit (character);  
      return 0;  
 }  
 FILE uart_str = FDEV_SETUP_STREAM(USART_PrintChar, NULL, _FDEV_SETUP_RW);   
   
 void USART_Print_Location(uint8_t line, uint8_t pos) {  
      if ((line < 1) || (line > USART_LCD_MAXLINES)) {  
           line = 1;  
      }  
      if ((pos < 1) || (pos > USART_LCD_CHARS)) {  
           pos = 1;  
      }  
      USART_Transmit(3);  
      USART_Transmit(line);  
      USART_Transmit(pos);  
 }  
   
 int main(void)  
 {  
      USART_Init(BAUD_PRESCALE);  
      stdout = &uart_str;  
      unsigned char sendChar = 65;  
      USART_Transmit(19);  
      USART_Transmit(12);  
      USART_Print_Location(1,5);   
      printf("Hello World");  
      USART_Print_Location(2,9);  
      printf("from");  
      USART_Print_Location(3,1);  
      printf("RichRobo on Blogger");  
      while(1)  
   {  
     //TODO:: Please write your application code   
   }  
 }  

The code really should be commented but I'm too tired to do so now and I'll most likely update and clean up the code soon so I can post it after that. Next job I'm thinking I'll do is to get SPI working between two chips. Before I do this though, I need to get the chip to run without the need for the programmer (AVR ISP mkII) being plugged in.

Stepper Motor Setup

Well after getting my stepper motor to work last night with full steps, today I got it to work with half steps and so wrote up the circuit and the major problem I had encountered.

Firstly here is another video of the stepper, this time running at a decent speed, using half steps.

You can't tell from the video, but the motor does run much smoother with half steps as well as being able to run faster (logical if you think about how charging the coils works).

So I'll give the schematic next to show you the circuit layout, then I'll go into the problem I had and finally the code. The schematic does look messy, I would fix this by labelling the wires but I found out tonight that KiCAD doesn't have this functionality so it will have to do.

In the test program shown working in the video, the LEDs in the bottom right seem like they are on all the time but they are actually connected to each coil of the stepper and so turn on when that coil is on in that direction. This was so I could work out what was happening and can easily be removed. I will go into why they were useful in a second. Other things to note are that the switches on the left are attached but not used in this test program as these were for my original demo program which I will get working soon and so can do more tests. In the video there is a SMD chip on a red board. This is not actually attached to the circuit at the moment. This is because it is the other stepper driver chip (A3982SLB-T) which I will test later when I have a better heat sink for it than the tiny one I bought at the time which doesn't fully cover it.

OK, so my problem for why the stepper wasn't working was quite trivial in the end. It turned out that I had connected the stepper in a non standard way and so the guides on programming for a stepper motor didn't work.

Basically the standard order is connecting the coils in alphabetic order as shown in their data sheets. This means that the coils are intertwined as shown on the left of the above picture. This wasn't how I connected them as it seemed more logical to me to attach them so the coils were attached next to each other as shown on the right. As a side note, the letters in the picture are the letters from the data sheet, the numbers are the logical output of the pins on the pins of the microcontroller, and so when in the wrong order do weird things. This meant that instead of moving, the stepper oscillated between two locations while the rest of the time, the potential difference (voltage) over the coil was zero (ie both off or both on). What I realised from testing with the help of the LEDs connected and using a slower clock speed was that I had one coil with both sides on logical 1 and the other coil on logical 0 most of the time hence why it was not working. So once I swapped the two middle columns of the logical states in the table above, it all magically started working. This was something I had not read in any of the tutorials online or in text books to be careful of so I'm quite happy that I managed to solve this for myself.

So here is my code:

 #include <avr/io.h>  
 #include <util/delay.h>        // for _delay_ms()  
   
 int main(void)  
 {  
   DDRC |= 0x0F;  
        
      uint8_t curLED = 1;  
      while (1) {  
           PORTC = curLED;  
           _delay_ms(7); // 18 for full steps, 7 for half steps  
             
           /** Full Steps **  
           if (curLED == 1) {  
                curLED = 4;  
           }  
           else if (curLED == 4) {       
                curLED = 2;  
           }  
           else if (curLED == 2) {  
                curLED = 8;  
           }  
           else {  
                curLED = 1;  
           }  
           **/  
           /** Half Step **  
           if (curLED == 1) {  
                curLED = 5;  
           }  
           else if (curLED == 5) {  
                curLED = 4;  
           }  
           else if (curLED == 4) {  
                curLED = 6;  
           }  
           else if (curLED == 6) {  
                curLED = 2;  
           }  
           else if (curLED == 2) {  
                curLED = 10;  
           }  
           else if (curLED == 10) {  
                curLED = 8;  
           }  
           else if (curLED == 8) {  
                curLED = 9;  
           }  
           else {  
                curLED = 1;  
           }  
           */  
   }  
   return 1;  
 }  

(Note to self, using http://codeformatter.blogspot.com/ with settings 5 spaces per tab, no line numbering, don't remove blank lines, yes to stylesheet, auto height and no to alternative background)

Its fairly rudimentary at the moment and needs tidying up but it shows the gist. I used decimals as it was easier to test and write down than using binary numbers which I had used in my demo which wasn't working. For those interested, binary in GCC and Atmel Studio can be written down using 0b as a prefix to the binary string. The code above won't work straight from copying as I have commented out the method for changing between full steps and half steps. The other thing to note is that my chip is running at 4Mhz so the time would need to be changed if running at a slower speed.

I think that is all about getting the stepper working. Tomorrow I'll either fix it up for use with my demo program which turns certain amounts and then gives control to the buttons, or I'll have a go with serial communication to the LCD screen. I might if I have enough time, have a look at both.

Just to finish off, I was looking around Australian Robotics this afternoon and found there is a ball bearing on there which is 5mm thick with an ID of 5mm and OD of 16mm. This could potentially work for wheels on the carriage but after realising that the motor shaft is also 5mm diameter and is quite large realistically, I think a smaller shaft diameter would make more sense. The same website also has a coupler for converting the 5mm diameter shaft of the motor to 8mm which would work well for M8 threaded rod or an 8mm ball screw.

I'll should have enough stuff to post again by tomorrow night or the night after as will be at home working on it for the next few days. Should be good.

Stepper Motor Full Step

Very quick post, but tonight I decided I would write a small test program to manage the stepper motor now that I can see which coils are on using LEDs. I was successful in getting the motor to turn which is good as it means the wiring is all correct and it must be my original program that does not work. I'll have a better look into this in the next few days.

This test program, as my first test has very large waiting periods between changing step so the motor does go quite slow. The other thing to note for the test program I'm using is that it is using full steps rather than half or smaller. This is simply because I'm testing and was my first go. I'll do a proper write up later about the circuit and setup but for the time being I have a video showing it moving, as I'm quite happy I've managed to get it working even though its a minor achievement.

Major Design Change again...

I've been trying to write this post for the last five days but have been unable to find time due to work and chores round the house. So first things first, I did manage to draw a reasonably accurate illustration of the design. It helped me think of a few things I hadn't thought of yet such as the X slide motor on the I beam would need to be mounted on a plate from the front so it doesn't dragged across the angle material of the Y slide. After this point though I basically abandoned finishing the drawing. This was because I felt the canter-leaver of the X slide would be hard to secure onto the Y slide. This joint is shown with a circle, in the picture below.

To over come this I had a small brainstorming. During this I found there was a new MendelMax (version 2). This gave me some good ideas. I wanted to still use the carriage design as I thought the current design worked quite well (more later on in this post about the carriage), so this would need to be kept in mind.

I then came up with a design fairly similar to the MendelMax version 2 above and mixed with a wharf/cargo crane.

When I first drew this design out I thought it would be great if the whole frame could move above the work as this would save on the footprint of the printer and so save space. (This was sort of one of my aims - to have the printer so it would fit on a desk, with my desk being 600mm deep so hopefully able to fit on that with out encroaching over the edge.) I might have to abandon the frame moving idea but I'm not sure. I can use the aluminium extrusion bars mentioned in relation to the very first design, for tracks for instance but I have not evaluated this yet. The other option is to design it like the MendelMax with the work moving for one of the directions. This might seem like a back flip for my ideas, and in a way it is but all in all, the project is a learning one so its no surprise that I end up with a design similar to others. I could make sure the sliding frame would work if I didn't use aluminium and used steel for example instead but I would prefer it to be light enough to move if needed which steel would parts would not help with.

In this design the slide between the two sides could be the carriage design and the Z slide could be the same again or just use track like the bottom. I had also when first thinking of this design, to not bother with diagonals for the uprights but after looking at the MendelMax2 I thought this would be a better idea.

I then started designing the carriage that I think is a good idea in Inventor. I haven't finished it yet but here are some pictures showing my ideas. I also haven't finalised on dimensions or locations so some parts are out of place. The four wheels that roll along the centre part of the I beam will have holes cut into the rectangular hollow so they have enough room to spin while also allowing the material to protrude in enough that the wheels in the upright position have somewhere to mount on both sides.

The diagrams above also have a very key part missing, that is the mechanism that joins the wheels to the aluminium. I'll attach them as shown in the following image.

This is a change from what I had previously designed. This is due to the previous design only being attached in one place and at 90 degrees so if there managed to be forces in the wrong location is was much more prone to damage.

Recently while trying to think of other uses for the printer I've worked out I could potentially use the printer for CNC drilling which would be great for doing circuit boards. Out of this same idea I thought the extruders could also be used for solder as it runs about the same temperature as PLA.

I've now gone back to having a look at the electronics. I've had a quick look at the stepper motor driver. I've attached some LEDs to each of the leads. This means that if neither LED is on for a coil then its off, same when both are on and if only one of the two for each coil is on then it should be positive or negative 12V. At the moment though it seems to have both on for one coil and both off for the second coil and hence why the motor does not spin. I'll write a test program that turns on each pin separately on the ATMega and see of I can get it to go to each state. If this doesn't work I'll have a look at the wiring and maybe redo it. If this still doesn't work, I managed to solder the SMD stepper controller on Friday with just a normal soldering iron and so can try that out.

With regards to the display, I'm going to try the serial connection which I said before. This looks to be much easier than I2C but does mean I can't use serial for anything else. This isn't such a concern as I can use SPI for connecting the controllers together.

This next week I have more time to work on the project as I'm not at work for two full days so should be able to spend more time on it as it seems like ages since I did anything even though its only been 4 or 5 days.

Frame Ideas

Well, even though I have been at work the last couple of days, I have still managed to to some design work. Before work on Wednesday I did another drawing of the extruder from another angle to help show some of the features a tad better.

This shows the drive gear being directly driven by the motor. This has since changed a number of times. After the direct drive idea, I though a worm drive would be a better idea. This worked until I started designing how to attach the extruder to the frame. The worm drive gear was then thought could be used in combination with helical or bevel gears but I realised these would be too hard to machine at home on our mill and lathe as we don't have a geared dividing head. At this point I better add why I want to use a worm drive. This because I firstly want there to be plenty or torque for pushing the filament and second to that but not as important in this case, accuracy of how much is being pushed down the nozzle. I have finally gone with simply using two gears with a high enough gear and torque ratio. I haven't yet drawn an illustration of this situation. I still reckon I will use a worm drive on the Z slide though as the torque would be very useful for pushing the slides up when gravity is trying to push everything down.

I next sat down, and with a copy of the previous design (as shown in the last post), and drew over it.

With this, I tried to decide on materials for each section of the frame. In the last post I had been thinking of using angular or channel extrusions for the X slide. I realised that this would not work due to the unsymmetrical mass and thus twist of the materials would occur and cause inaccuracies and possibly breakages after a time. That is what all the pictures of beam types are in the top corner. I've written around them why I haven't chosen them. The Y slide I'm going to go with angle regardless as its otherwise too hard to attach the X slide. I'll instead just make this sturdy enough that twist won't be great enough to worry about. This drawing also shows that the bar on top, needs only be a tie bar for strength purposes. It may still not just be used as a tie bar due to aesthetics. The main frame, as in the materials for the Z slide and base will all be square tubing. With the base, I came across a page on the reprap site about calibration and it recommended if there was a heated bed, that it be 110˚C for PLA. With this in mind, I'm going to install insulators between the bed and the frame itself. I don't think I've said anywhere else so may as well state the sort of obvious. The frame at the bottom will also have a bar attaching the two legs of the frame together. This is obviously needed for strength and to tie the frame together.

So the type of material I decided on for the X slide was an I beam. This was due to twist and sturdiness.

I think I will join the X and Y slides similar to the above picture, but I haven't done any analysis on this joint so has potential to change. The green part (the colours are just to show different parts) bends down the back of the red one so it can slip forwards too much. I may be able to put a grove in the back of the red part so the green one latches in and is unable to fall out.

The next day at work, I decided I would have a go trying to think of how to fit an extruder onto this I beam. I came up with a nice carriage idea and a new extruder that had an angled/L shaped nozzle.

I soon realised that an angled nozzle was a bad idea as it had the forces in the wrong direction to get the filament down the other end and would be very hard to clean which would be needed if a change of filament colour was wanted. So I scraped this idea and went back to the original extruder. I'll balance out the weight by moving the motor to the other side of the carriage from the nozzle and the rest of the drive. The carriage shown also has the slide drive above the carriage. I think I will move this to one of the sides so that it takes away height, plus I can have this motor on the top and the motor for the Y slide underneath. This would mean that I can use that space used by the motor on the Y slide more effectively. To make more sense of the image above I also made another image showing one side of the carriage wheel arrangement.

This arrangement works by having wheels in the Z direction pushing against each other and so making the carriage centred in the Z direction while taking out bumps. The wheel in the Y direction is used to centre the carriage in the Y direction and is used by pushing against the wheel on the other side of the I beam. The arrangement of three wheels for the Z direction on each side is so the carriage doesn't rotate.

Hopefully in the next few days, I'll do a proper mechanical sketch which will combine all of these ideas into one image. I was going to do it today but I have had to do some other wood work so to start tidying up dad's shed for his use.

Other ideas I have had for the frame is too have gyroscopes on the head/carriage and one on the bed so corrections can be made automatically for any twist. This idea was always the case, I just needed to write it down. I will put micro switches on the slides so the electronics can work out its maximum travel distances. I'm also going to have to weigh the stepper motor sometime so once I've done the basic design, I can check material strengths and balance out the weight on parts such as the extruder carriage.

One last thing before I finish this post. A while ago I posted an invention that you could use to melt down old plastic bottles and convert to filament. During the week I was thinking about this and I think I will make one of these almost as soon as I've made the printer. This is because its far cheaper to melt down plastic you already have and recycle rather than always buy it. I also had a quick look on the net and found you can buy plastic pigment for colouring so this could be added to get colours. With this machine, if I was to make one, I would try and make it mostly automatic and so it would melt down the plastic given, add the pigment and mix then extruder out through a hot nozzle into a cold nozzle and then automatically roll it up. The cold nozzle is used so the plastic doesn't melt together when rolled up.

Well that is all for this post, hopefully tomorrow I'll have a new image of all the above components together but it may be Tuesday or Wednesday before I get it done.

Extruder Nozzle CAD and materials for Frame

Well today I actually got some CAD done! I modelled the nozzle for the extruder and the insulator, which I posted about yesterday. The designs I had yesterday weren't complete as they had no dimensions and were really just pretty pictures (not even very pretty some of them). I also changed a few things about them along the way. Just of note, I'm going to post my hand drawn designs as well as the CAD ones in this post which I won't do normally as there isn't much point in uploading both except for looking at my effort at drawing and seeing how it fairs to what I actually design. So here is the page of designs.

As you can see from this, I have designed and given numerical values to dimensions except where I'm unsure or I'm going with a standard. Next thing to notice is that I have started to assign part numbers. I wasn't going to do this but I realised when I was drawing these that if I do a parts list on Inventor that it always shows a parts list plus when I save the files it makes it neater to have standardised file names rather than the hodgepodge that I normally do have. I thought for ideas I better have a read about part numbering and found that some company called Arena Solutions had some nice pages about part numbering here and here. I then went with a 11 character (excluding dashes) with an extra 2 digits if needed. There were as follows:
3 characters for the significant (major) location or use of the part
3 characters for the minor location or use of part with the significant one (major)
4 numbers for the revision
and the optional 2 numbers that are used for types of a part such as with the nozzle, there will be at least two versions of the same nozzle, one with a smaller extrusion hole (ie the bit where the plastic comes out) and one with a larger one hole.

While I was looking round for dimensions for the nozzle I also came across a page on the RepRap site that had some variations of the standard nozzles. One of these used PEEK plastic for something and was attached to the nozzle so I checked it out and its melting temperature is 343 degrees according to wikipedia so is another contender along with the ones mentioned in the last post which were polyurethane (no melting point), Kevlar (500˚), Twaron (500˚), Nomex (390˚) and PTFE (330˚).

Another page I found when wondering about the size of filament to use was a forum page talking about the best sizes. This explained that larger nozzles can actually be better for larger prints as sometimes these don't need too much detail and so a larger nozzle will be faster. The page also recommended starting with a 1.75mm filament that although slightly more expensive, would melt quicker and so easier to use and not as much pressure would be required.

The red note (which was partially cut off by the scanner) in the bottom of the page is about the potential of plastic to melt into the crevasse between the end of the nozzle bolt and the nozzle tip. I had thought this would be an issue and have to create a revision that had all the tubes and diameter changes all part of the bolt and just use the tip as metal mass and for using as the storage for the heating element and sensor (with some heat sink fluid between the two parts). After some thought I decided this wouldn't matter as it would fill up and stay there. It could also be fixed using a high temperature sealant such as silicone of which there seemed to be plenty selling online. We shall see how it turns out once we make it. The only reason to be worried is for cleaning and changing the colour of the filament used.

So after all of that, here is my CAD version of the nozzle.

I had to upload it as a PNG rather than PDF so its lost some of the detail and the page size which is supposed to be A3. Here is a link to the PDF version on my Google drive. The only real difference between this and the design I had yesterday are that the locations for the heating element and temperature sensor are now holes that go straight through the nozzle rather than being at a weird angle. There is also one dimension that I've added a numerical value to but will have to be adjusted. This is the length of the thread on the bolt as it depends on the thickness of the casing/wall that holds the nozzle.

So that covers what I've done with the nozzle today. As I said I won't write up everything from the preliminary designs in the future I don't think but we'll see how I feel on the day.

The other thing I did today very briefly was to think about the materials for the frame. I'm still working off the design I posted a while ago.

Apart from I'm going with what I said yesterday which was to use U shaped channel for the X slide. I think I will also use it for the Y slide now too. This is because it is much stronger laterally that just a bar which is what I had drawn in my original design and even today was thinking about. I think the bulk of the main frame will be out of square hollow tube with the sides being either 45 or 50mm. I was also thinking of using a special type of aluminium extrusion for the Y slide and top. It looks similar to the next image which I had seen when I did a tour round a high speed boat builder site. I think though it was specially made and most likely wouldn't be made small enough.

This was the stage were I thought flat bars would be a good idea but as I said above I've reconsidered and think channel will be a better idea.

Well that is all for this post. I'm working the next few days so won't be able to write any more posts but I'm sure I'll be thinking of ideas as I'm working.

Extruders and more!

Its been what seems an age since my last post. This is because, after exams finished, I just sort of switched off from everything and relaxed, specially with extended family coming to visit and Christmas and New Years. For New Years I was away on a trip to Melbourne, and one night decided I would plot some ideas down and so have now got right back into the project.

So since my last post, and before my planning in Melbourne, not a lot has happened. I still haven't managed to get my display to work using I2C, so I may switch to serial unfortunately. I did however manage to get the stepper motor to move... slightly, as in it sort of flicks between two spots. Below I have added my notes of the test program and the driver code. I had to stop progress as the extended family needed to use my room (I was kicked out of my own room!) as well as it being summer here and having great conditions for the beach and other activities to relax. I'll shall get to these soon as I thought of a very loose plan of phases I need to do.

The flow of the stepper test program (left), and the combination of the digital logic for the L293 chip (right)

I'll now go through the things I decided on and thought about while in Melbourne. First up my phases, which I split up into electronics based and mechanical/structural based. This is so I don't get board or annoyed when something is taking too long or is turning out as planned and thus can move to the other stream. I also have some notes on these.

So the electrical phases are:
1) Create and test motor controller (ie what I have been doing with the steppers recently)
2) Test SPI between two ATMegas (get two microcontrollers communicating)
3) Get the display working (I want to do this sooner rather than later as would be great for debugging)
4) SD Card (There are plenty of tutorials on this and would be the easiest way of getting the data from the computer to the chips until I have ethernet working)
5) G Code and related (the syntax used to tell the printer what to do)
6) Combine the above including porting some of the code for use on smaller chips
7) Ethernet (So can print without having to be next to the printer)

The mechanical phases are:
1) Design frame on AutoDesk Inventor
2) Design single based extruder (partly done as I wrote this list without a computer at hand so my mind wandered and started designing an extruder regardless which I obviously wrote down)
3) Review (I say this as I'm sure I will design something and then realise that it won't work or something could be done better. Ie look at it with a different frame of mind.)
4) Add/make sure there are mounts incorporated in the design such as screw holes, types of screws, tolerances etc.
5) Do the cable layouts, this will make the end product neater, more aesthetically appealing but more importantly make sure the cable will actually fit where needed and where sockets and plugs need to go.
6) Build
7) Test
8) Multiple extruder

The notes I have are as follows:
• KiCAD layouts can be exported and thus can be imported into Inventor for use in designing mounts etc
• The SD Card should have higher priority than ethernet as mentioned above
• By using G-Code and related it is easier to use pre existing utilities until we are able to and decide to create a better one - we'll need to at least create a utility that can send via ethernet.
• On the same lines as the above, if the G-Code for 3D printers is different from that of normal CNC machines such as mills, then both will hopefully be implemented with the 3D printer version taking priority as there are more utilities are available.
• Drawings (well the inventor models) should include physics ie, hopefully can simulate motor turning and have slides move.

Now we finally get to the extruders which I designed the last few days. I can't take all credit for the design of this extruder as, like I have previously mentioned, I have been very inspired by the RepRap designs. I also had some ideas from the Ben Heck Show on YouTube as he has made a bunch of 3D printers, one of which (the one I have actually watched as it was uploaded just before Christmas) is a "Double Decker 3D printer". This can print two of the same objects at once. This helped me as it showed how the design from RepRap actually was constructed rather than just a still picture from one or two angles. One of the things I noticed was that Ben was using timber for the frame. I realised this also meant it would also act as an insulator for the extruder to stop excess heat transferring to the rest of the model. Other extruders I have seen pictures of have not had any sort of insulator (well not that I had noticed) and so I think this would be a good improvement. It also allows the casing or structural components to be made of metal too while not having to worry about heat issues. I will if I use metal casing have to make braces and diagonals but I think that is better than having bulky extruders which would mean it is harder to incorporate multiple extruders. I'm also still thinking of trying to use U shaped channel for the slide that the extruder is on. This would mean that a small slot down the middle could be used as a guide and as a hole for the hot tip to be mounted through. The two edges could be easily used for guides too.

 

This was my first sketch and ideas page, hence why its quite messy. Most of the drawings, except for the one in the top left are of ways to try and make a mechanism that would allow multiple extruders to be used with a plate that would allow only one of these extruders to be operational, ie only allow one extruder to have a clear hole/access down to the work below. This is also the reason for the question in the top left, as if the plastic won't drip, we won't need such a mechanism and can just stop pushing the plastic or pull it back a bit to create a vacuum. These mechanisms would be operational with the use of solenoids or motors, both being expensive and hence why its better to try and avoid such mechanisms.

 This image, is a much clearer and better defined version of the illustration in the top left of the previous image. This has everything labelled and so not much explanation is needed. The spring arm is used so the filament is always wedged against the drive/push gear and thus has grip. The note down the bottom about a worm gear is so the motor has more torque against the filament. The other note at the bottom is simply there to remind me that the drive gears should have teeth so to better grip the filament, hopefully with the middle of the teeth curved a little so to have more surface area on the filament rather than just the centre which would be the case if the teeth were flat on top.

 

This drawing is purely about the tip/hot end on the extruder. The insulator bits show a large extrusion for the internal hole, but this need not be so big, just big enough so it sits in the case material. The question which I'm not sure if it will be readable on the uploaded image is asking what the size of the tip itself should be as a larger tip would have a larger heat capacity and thus not need as much energy to keep at the same temperature but its large, so would a smaller one but with less heat capacity be better. The other important thing on this page is the material for this insulator. I short listed a few which all have melting points supposedly higher but I'm not sure about expense, availability or the operating temperatures.

This last image is about the slide, simply showing potential of a U shaped slide.

The next thing I designed, was when I got back. I was looking over the 2012 in review post on the RichRap Blog and re-found the post on his paste extruder. I had originally decided this wasn't for me as it used a syringe which wouldn't hold enough paste to be useful but while having a few mates round for drinks, one of them came up with the idea of just using a syringe and then pumping or sucking more paste into the syringe. So once reminded of this post I had a look at how his syringe extruder worked and quickly realised the design he had used would not work for me as it would only work in one direction and thus would not be able to suck. (I think sucking will be better than pumping as it requires less parts and thus less expensive, plus if it doesn't work is much easier to convert to pump than it is to ignore sucking the first time round and then be stuck if pumping doesn't work.) So while trying to think of how to do this, I checked wikipedia for how to spell actuator (it was almost midnight and I was half asleep so I was trying to spell actuator like auxiliary with the start being aux and so couldn't get spell check to fix it.) One the wikipedia page, I saw screws could be used as a basic actuator (not that I didn't know this, it just wasn't at the forefront of my head at the time) and so realised this would be the best way to implement the actuator so it can move the syringe both up and down.

The reason for two drive gears is to get extra torque as sucking would require quite a lot. The other two notable things I thought about this design is that due to the pipe bringing more paste in, that this pipe would need to be turned on and off so not to have the paste pushed back down it, and so a gate controlled by a solenoid would be needed. When sucking material back, there could also potentially be excess air in the pipe or something so a pressure sensor could be used to detect the pressure and therefore work out if it needs to let some air out. The other way of doing this could be to make the gate over the needle out of material that would let air out (though not in).

That is all of the ideas I have come up with over the last few days, but there were some others that I had written down to type up on the blog. Firstly I found a tutorial for SMD soldering using standard solder, a standard soldering iron and de-soldering wick. I thought it seemed like a good idea but the comments when I just checked now seem to indicate otherwise. It also sort of states the obvious but still something I had not thought about which was to use tweezers when handling SMD parts.

A few posts ago I had thought a camera would be nice to incorporate. I soon realised the camera modules were actually quite hard to find for some reason and seem to have to be ordered direct from the manufacturers. I have since found one from Little Bird Electronics.

Another thing I had thought of was to engrave each slide with the name its known by software, as this would make it far easier to debug and understand what settings were being changed etc. Talking of engraving, I've decided I would love a laser cutter! Within a week I had two completely non related people say I should get one with me having investigated them too that same week before anyone had said anything. They seem great, and would be great for cutting shapes out of wood, flat plastic and metals. This in conjunction with out press that can bend metal into shape would be great for making brackets and things like cases such as for the extruder above. One can only dream though.

And so to finish off this post, I'll say one last thing which I had realised when I was testing the stepper motors back in November. For something that makes mechanical/structural items, it has large amounts of electronics involved!