Beta testing for Makeblock

01 Apr

Beta testing for Makeblock

Some weeks ago, I was asked by Makeblock if I wanted to review a kit that they are putting on Kickstarter? I guess they asked my since I've written about some of my other Makeblock experiences and use it for most of my robotic projects, and of course I wouldn't mind testing out something new. But - I got an idea - who better to test it than my 10 year old daughter Vera? They liked the idea and sent the kit off.

Disclaimer: the kit was given to me, but because of Norwegian customs regulations it is impossible to get anything "for review purposes". Due to that, I had to pay both handling fees & vat of the theoretical price, making it a fairly expensive project, but hey - I get some quality time with my daughter & she get's to make another robot!

First day - rough start

The kit came in one of those nice, blue Makeblock boxes that I have a few of already. As soon as the courier arrived with the package, my daughter started asking what day we were building? Due to family plans, the first day of building took a few weeks to work out. 

The kit is quite impressive when you lay out all the parts - stepper motors, beams, wheels, nuts-n-bolts, electronics, sensors.... It's a really solid kit and it is the foundation of no less than 4 different robots. It's quite an ingenius little kit in that it contains all the kinds of drawing robots that you'd want to build - a pantograph arm-style robot (mScara), a Polargraph wall-drawing robot (mSpider), an egg-bot for drawing on round objects (mEggBot) & a PenBot (mCar, same kind as the NITH Penbot I designed some years back). Vera very soon found out that she wanted to build the mScara robot first!

The day arrived and Vera thoroughly liked hanging at Bitraf (my local hackerspace) a whole day while building! The deal was - she would test the kit and I would sit next to her working on something else. If she got a problem, she would ask me for advice. Turns out, she needed a lot of help. The reason? We only had a video of the robot being dis-assembled and no instructions on how to build it. I contacted Makeblock and they said that unfortunately that wasn't finished yet but we could get it very soon. 

Oh well. It was after all Saturday so she had candies while she mounted the electronics and peeled the foil off the plastic parts. We had planned another build-day and this was after all a Beta test, so we could not expect it all to go perfectly smooth.

Second day - success!

About two weeks later, we had another build-day at the hackerspace and this time we had instructions! This day, Vera kept building and only asked me twice for advice so the instructions were rather good! The only things she asked about where "Do I use this length or this length screws" and other simple things. At the end of the day, we got the robot working and she chould start drawing!

We'll keep exploring the kit in the weeks to come, but we really like it already. Vera's reaction to opening it was that of a kid opening a massive box of candies and the software makes it a breeze to change between robot configurations. Vera did not think it was difficult to build the robot at all. She has a little LEGO experience that I think came in handy, but I think this kit would work for all kids that enjoys tinkering and building.

Judging by the Kickstarter campaign, it's not just Vera & I that thinks this is a cool kit! For now they've reached their goal and it's well on it's way to reaching the first stretch goal of $100.000 grin

ESP8266 and stability

24 Mar

ESP8266 and stability

Like many others in the Maker Community I've spent a lot of time playing with the dirt cheap ESP8266 wifi chip. It is the cheapest way to add wifi to your project and it's easy to get hold of. My hope was that it would be solid enough that I couldbuild permanent installations and fun Internet Of Things (IoT) devices with it, but the darn thing keeps crashing. I've been testing it since the 0.91 firmware and all the way up to the current 1.0 version and it's not possible to keep the device running for a prolonged period of time.

I've spent more than a weeks worth of time getting it to not crash at random intervals, so I thought I'd share what I've learned in case others find it useful.

Setting up for development

The best way to hook up these dev boards is to use the ESPlorer software (java) and getting a USB to Serial converter. If you have a version that offers 3.3V on both data and power lines (such as this one), it is the most convenient. If you can't find a 5V USB to Serial, you should know that the Serial pins (RX/TX) are supposedly 5V tolerant, but the power must be 3.3V or you will fry the chip. The ESP modules will pull a couple hundred mA, so powering it from a good 3.3V power source such as a LM1117 / LD33 can be a good idea.

There's many guides to hooking up the various development boards, so I won't detail that part, but lets look at the software side of things! When you buy the ESP-01 breakout boards from ebay, you never know what version of the firmware it comes with. Most likely it will be an old one so you'll probably want to update it. But - what firmware should you use?

NodeMCU

NodeMCU is a firmware that adds a LUA layer on top of the (somewhat stable) official 0.95 Espressif SDK. This seems to be the most stable firmware you can currently use and it is also the one that is the easiest to get started with. It is well documented and offers good tools. Rui Santos has a great guide for hooking up an ESP-01, burn the NodeMCU firmware and setting it up as a webserver.

Briefly said, you hook up the ESP directly to a USB to Serial converter (3.3V!), download the NodeMCU Flasher tool, select the COM port and hit the Flash Button.

When that is done, download the ESPlorer software to talk to it. LUA is a very straightforward language to learn and if you're used to closures like in Javascript, you'll feel right at home. NodeMCU has a nice, documented API and several libraries that you can add for special hardware like LCD's, WS2812/2811 LEDs, sensors and more.

The NodeMCU firmware is based on the original Espressif SDK and thus inherits all the bugs it comes with. This means that the hardware will crash just as often, but since it always restarts after a crash, it will re-run your LUA script on startup. This makes NodeMCU good enough for devices that will just send some sensor data to a webservice such as Thingspeak. It will not work as an access point doubling as a webserver though. It'll crash and hang just as often as with the original firmware, so for me this is a showstopper. I want to make IoT gadgets that serve up a web interface as well as an open API.

Stock firmwares

Updating the firmware is quite easy if you use the NodeMCU Flasher. This has a nice, minimal GUI and everything is point and click. It's Windows only though, so if you like Python, check out the esptool. All the officially Espressif SDK's contain a "bin"-folder that has the precompiled files and a text description of what memory addresses to copy each .bin file into.

My initial idea was to use the UART in the ESP boards with a Microcontroller. Most my projects are based around the Teensy 3.1 and since it has 3 serial ports, so it's a breeze to do UART communications with. However, no matter how hard I tried, I couldn't make it 100% stable. After a few hours, it just crashed and restarted. It could run fine over night, but it would always crash after some usage. If there was a lot of traffic, it would crash more often and my intent was to basically bombard it with data continuously. I tried all the different versions of the firmware and even the official 1.0 version that was released this week is buggy beyond repair. It is actually so buggy that Espressif recently started an official bug-hunt...

That pretty much rules out using the official firmwares. How about making your own then? Espressif provides an SDK and the required code to compile your own version. Building it yourself is quite easy if you have a Ubuntu VM. Just follow the instructions outlined here. This will however not solve all your problems. Some of the codebase is Open Source, but other parts are provided as "binary blobs" so you can't really know what bugs are hiding inside. You can however exclude those parts of the Espressif SDK that you suspect to be causing the problems, so if want to program the ESP8266 directly check this neat guide on Hackaday.

ESP8266-transparent-bridge

This "Transparent Bridge" is the solution I'm currently experimenting with. It's a completely dumbed down firmware that can take a TCP connection on any port and relay it to the Serial port (RX/TX). Just apply power, connect to the WiFi access point that it sets up, Telnet to the default 192.168.4.1 address and you can set it up to join your local network / access point. You can then up the BAUD rate to whatever you want/need and change the Port to for example 80 to make it work easily with browsers.

Anything sent to the ESP will then show up on the Serial connection. When you write back to a connection, you can serve data (like a webpage). Currently, this seems to be the most promising solution, but it requires some more testing. The basic idea is to use as little as possible of the buggy Espressif SDK as possible. To get the ESP Transparent Bridge firmware onto the device, just load the premade .bin files using the NodeMCU Flasher tool like this:

I'll post back here when I have more details & results on this setup.

But why care if it's buggy?

You might ask yourself - why on earth should one care about this chip if it is so buggy the creator has to host a competition to find all the bugs? The thing is - at $2 you can put wifi into ANYTHING! A typical wifi-shield for an Arduino will cost you from $30 and up to $90. Just a plain breakout board from Adafruit will cost you $35 and the CC3000 that it's based on isn't exactly stable either. A $2 chip that works would open up so many possibilities, so that's why I still care after fiddling this much with it.

A little about the hardware

I presume that you already know a bit about the hardware if you're reading this. If not, here's some details. The ESP8266 is a small powerhouse and this is a small 101 on the hardware. It's an ARM processor that runs at 80Mhz and can be overclocked to the double. It has up to 16 GPIO pins available and it does SPI, I2C, UART & more in hardware (fast!). It offers great range and you can get one for as low as $2 on ebay. Physically, it is a tiny 5 x 5 mm Integrated Circuit that needs a little supportive components around it to be useful. There is a series of dev-boards that offers this: ESP-1, ESP-2, ESP-3, ESP-4, ESP-5, ESP-6, ESP-7 and so on, all the way up to ESP-12. They differ with regards to pin spacing, internal/external antenna and the number of GPIO pins broken out. It was hard to locate all the pinout diagrams, so I've gathered them all in a github repository that I'll fill with useful code and resources. The original datasheets has some decent info, but check the ESP8266 wiki for more details.

The ESP-1 is typically the cheapest and most available. It only has 2 I/O pins broken out and uses 2.54mm headers. They are however clumsily combined into a 2x4 arrangement making them impossible to breadboard. It's not hard to make an adapter, but the ESP-2 is more practical for breadboard use. This also has a third I/O pin broken out, but requires an external antenna. The different versions all offer useful features, but the ones to avoid are ESP-5 and ESP-10. These do not have the pins required for updating the firmware exposed.

The version that seems to attract the community is ESP-12. It has FCC certification, RF-shielding, ADC and 9 GPIO's. It is included in the NodeMCU devkit that you can now get from TronixLabs and several other Open Hardware vendors. I'm looking forward to getting a couple of these to play around with. Other devboards that look interesting are the new one's from Olimex.

 

Spark Core shows solid magenta LED

12 Mar

Spark Core shows solid magenta LED

I've been head deep into a great game-project where I'm using UNO & Fuse for the first time on a commercial project. Before this, I spent about two weeks making a nice LED sign that will be used at Bitraf above our mini-hackerspace-shop called Bitmart. I want to be able to control this using any phone so I spent a solid amount of time getting various ESP8266 boards play nice with a Teensy 3.1. That turned out to be a nightmare. I originally intended to make a library around it, but I gave up. They are simply too buggy and running the auto-update makes it corrupt itself, so I now have 4 dead once's that I'll have to flash.

How hard can it be? I tried using the CC3000 from Adafruit with the Teensy instead. It went better, but it did by no means become very stable. Turns out the CC3000 chip is so buggy that even the makers (TI) have given up on it. Too bad that I bought 3 of these boards then... What next? Well, work took over and now that I'm wrapping up the game project, I'm back to this project again. What next?

Spark Core

I've done 45+ Kickstarters and some of them have been for Arduino-like things. One of these is the Spark Core. I never played around with it when I got it, but figured I'd check if that could solve my wifi problems. The Spark Core also has a cc3000 chip, but it's all in one board with an ARM M3 processor to control it. Since the release, the Spark team has put out two new products (Photon + Electron), but since they're making a living from their first product (for now) they've ironed out some of the Wifi problems with the CC3000.

So I followed the instructions and .... nothing. The "smart-app" wasn't smart enough. I updated the Core via USB / terminal so it had my wifi-credentials, but it failed to connect. The LED went from white, green, white and then solid magenta. This state isn't described in the docs so I asked via their forums. Within 15 minutes I got the info that I needed - since my core was an early version, it did not have the required firmware to connect to my WEP2 wifi. A firmware update would solve this.

Updating the Spark Core and DFU mode

To install the command line tools, I had to clean out a very old version of Homebrew from my Mac, but from there it was smooth sailing. First follow the instructions on setting up the development environment (Node.js, npm, homebrew, spark software) then follow the "Deep Update" instructions. To put the Core in DFU-mode (to allow firmware updates) You have to hold both buttons and then release the Reset-button. This will make it blink yellow so you can do the update:

    spark flash --usb deep_update_2014_06 

After running the update, I could then connect it and use it. Thanks to ScruffR for the solution! Posting it here for Google to grab it as I didn't get any good search results solving this.

Nice to have both wifi and MCU on one vs two boards! Teensy 3.1 with an ESP8266 in the back, Spark Core in front.

Unpacking the Titan 1

16 Jan

Unpacking the Titan 1

I just received my fourth 3D printer and the first to use SLA technology. I've followed maybe ten 3D printer projects on Kickstarter, but Titan1 is the first one where I have actually ordered a device. On the other one's I've just been part to follow the project and see if they're posting "the right things" and this was the first vendor to gain my trust. As opposed to most other KS printers, the people from Kudo3D kept posting different reviews of materials and showcased prints.

But without any further ado - here's my unpacking of the printer!

Boxes ahoy!

I received two boxes and for once it was actually true that they didn't fit inside my rather large mailbox. The smaller box contained the printing resin from MakerJuice. The big one contained the printer itself in a nicely packaged box. The upper layer had slots for the Z-stage, two brackets, the RAMPS & some tools.

Beneath this upper layer was the printer-case itself along with a white box containing tools, cables and the red acrylic enclosure:

The printer enclosure was jammed full of other boxes that fit snugly.

I pulled it all out and spread it across the table and here's what the different parts are (click to enlarge):

1. Acer DLP projector
2. Two PSP containers
3. Solid case based on 20mm T-slot extrusion and panels that you just click on/off.
4. MakerJuice! The four bottles of printing resin that I ordered extra.
5. A standard Ramps 1.4 + Arduino Mega controller is used to move the Z-stage.
6. Pre-mounted Z-stage
7. Brush + small air pump for cleaning away dust.
8. Mounting brackets.
9. Starter kit (detailed in next image)

10. 12V/5A power supply
11. Red tape for joining the acrylic pieces
12. American Power cord? Oh well, I have one spare but this one had actually been damaged (pins displaced)
13. Tiny foldable funnel
14. Spare mounting brackets for the T-slot case. One of these + a screw had come loose during transport.
15. Case fan
16. Calibration Ruler
17. Parts for the red, acrylic enclosure
18. "Leveling feet", a fancy plate consisting of a sandwitch of plastic & metal.
19. Hex wrench for case
20. Knob
21. DB9 serial cable extension
22. Feet for the case
23. Flush cutter. Looks good!
24. Tweezers & a stanley knife blade. No knife though?
25. Triangular level
26. Metal spatula
27. Nuts and bolts
28. USB to Serial cable
29. HDMI cable for the projector
30. USB type A cable

I'm really looking forward to get this up and running over the weekend. There should also have been a UV lamp in the package to use when curing the prints as they come put of the printer. I'll email the support dept and check where that one has gone. As usual there's more pictures on my Tumblr page.

Filament review: PlastInk Rubber

05 Jan

Filament review: PlastInk Rubber

This flexible plastic filament from the Italian company PlastInk has been on my desk for a while and it's quite interesting! It's flexible, has massive friction and behaves like Nylon in many ways.

They actually don't call it plastic, but rather rubber. I wouldn't say it behaves like Rubber in any way, but it has some properties that make the comparison valid. The plastic prints with a nice shine and I've not experienced any dimensional deviations (2.85mm).

How Flexible is it?

The Flex is nowhere near as flexible as NinjaFlex. NinjaFlex will typically go back to it's original shape, but while this plastic stretches, it will loose it's shape if pulled really hard. It can stretch to 2-3 times it's own length before breaking, but actually breaking it is really difficult as it's super strong! It is so strong it's hard to cut the 3mm thread with just scissors and in this regard, it is quite comparable to Nylon. It's actually so solid that proper pliers are required!

It bends nicely, so it's not rigid like PLA & ABS, but is also extremely solid. I'd say it behaves something in between PETG and Ninjaflex, but more towards the PETG side. It's very different than PETG though. It has such an extreme friction that you have to spool it so it feeds nicely into the printer. If you don't, the plastic will get stuck in all possible parts of the printer. It simply must be on a spool as it doesn't slide - even on a hard surface. This frictional property is quite unique and makes it a good choice for printing grips and tool handles. This is also how it compares the most to rubber.

How does it print?

When spooled, this filament is very print-friendly. It can be almost as strong as Nylon, but it's more flexible. It can go fairly low in temp and does not warp very much. It is however rather hard to make large prints stick on glass with glue, so you'll have to use the heated bed & print with a brim so that the heat sucks it down.

I've printed this rim with several plastics. It's a good test-object as it has both solid and flexible parts. In PETG it's hard. In Nylon it can flex a bit but is quite hard. In Ninjaflex it is uselessly soft. With Plastink - it's something in between the NinjaFlex and Nylon. Thicker parts are stiff, but thinner parts are rather flexible. I still think Nylon is right for the rim's, but I like how the Plastink plastic feels! Very little stringing overall. It's also interesting to note that this filament does not require you to print slowly like NinjaFlex does. Despite it's frictional properties, it's stiff enough to print with bowden systems as long as the tube is Teflon / PTFE.

Surface finishing

One important thing I found out is that you can actually torch this plastic with a burner to get a smoother surface. You'll need to be careful doing this as it's very easy to apply the flame for too long, but if done carefully you can get some quite smooth results. Applying acetone to it seems to do very little. I put a sample in a small bottle of acetone, and there's no sign of it dissolving in any way. I can't seem to find a datasheet for the material, but it would have been really interesting to see what this is based on given it's resistance to acetone.

Skatefins printed with Plastink's white Rubber - seemed like a great idea for solidity, but the frictional properties really work against it being suitable.

Versions available

I initially got a couple small samples from the vendor, but found it so interesting that I wanted to test some more. I found an extra roll in the Arduino.cc webshop and picked it up with some other original Arduino gear I needed.

The filament from Plastink comes in just 7 basic colors (Black, Blue, Red, Green, White, Yellow & Clear), but the exact same colors exist for Flex, PLA & ABS. This is very interesting when thinking about multi-material objects as you can make parts that look like a solid, single colored part, but has elements that can flex. I especially find the Crystal (transparent) rubber fascinating even though I have not tried it yet.

I was also sent samples of the PLA & ABS. I only tested the PLA and it behaved nicely, just like other high quality PLA I have. They've also just launched a series of metallic colored PLA that looks interesting. Despite a loack of information regarding the origins of the plastic, I just got an email that suggested that the plastic is produced by Aquilacorde.com - a manufacturer of guitar strings. That could explain the nylon-like properties & strength.

BAMM settings for Plastink Rubber

The BAM Makeblock printer has a BulldogXL extruder with a Hexagon nozzle. I use the following settings with this material:

  • Temperature: 220C
  • Speed: 50-70mm/sec (can certainly go faster)
  • Retraction: 2.5mm @ 20mm/sec
  • Extruder tension: screws 2mm out
  • Heated bed: 50C
  • Fan: full

 

Filament review: ColorFabb PLA-PHA variables

23 Dec

Filament review: ColorFabb PLA-PHA variables

This is the filament I have the most experience with, on both good and bad. I purchased my first rolls 1.5 years ago. I had worked really hard for a long time and thought that I would reward myself with some prime quality filament so I stocked up on 10 rolls of all the colors I wanted!

Up until buying from ColorFabb, I had only used filament from high quality vendors like Faberdashery, Diamond Age and Ultimachine. Given all the positive comments I'd seen from others I expected the same (or maybe even better?) from this Dutch vendor. I was wrong. Months of clogged extruders ensued.

The cost of troubleshooting

I purchased spare parts for several hundred Euros from Ultimaker, just so I could exclude that as being the problem. I practically rebuilt the entire extrusion system without being able to solve the clogs. I even went as far to buy a proper Fluke HWAC multimeter so that I could measure temperatures properly. I also incorrectly blamed Ultimaker & Cura for some of the issues hmmm

Tons of tests...

I eventually came down to the conclusion that the clogs came from inconsistent diameters (sometimes above 3mm, far from 2.85mm) and very varying quality of the plastic. For most plugs I'd find some black thing at the nozzle tip while cleaning it out. I should point out that cleaning out an ultimaker isn't very simple as you'll often have to disassemble half the print head. Not a fun task to do several times a day, especially since I also printed 800+ meters of Faberdashery plastic on the same printer without a single filament error...

Replacement rolls

I wrote several polite emails with the support crew at ColorFabb and I have to say their support is really stellar. Nothing to complain about there. They told me that both the formulation & diameter had been off on several of the early rolls, and offered to replace all my rolls with new filament at no cost. That's pretty good service?

Problem was - when I got the rolls, some of them were better but by no means all. Argh... I've paid almost 450 EUR for those rolls, I have to make them work! After a lot of testing & rebuilds of extrusion system on my Ultimaker, I came to the conclusion that the only way I could print with them was going far above the recommended 210C. Even then it would clog now and then if I tried to go too fast. Others at my hackerspace had similar experiences, but a friend using 1.75mm Colorfabb filament never has issues? My Ultimaker Original is equipped with a 100% original extrusion system and the only speciality is the added dual extruder & heated bed. None of these should have any effect on the printing.

New printer, new problems

I solved most my ColorFabb problems by printing really hot and cooling the Ultimaker hotend down with an extra fan as I printed. If I tried to go anywhere near their official recommendation, the printer would clog right away. This worked so well that when I built my new printer, I was completely flabbergasted when I got similar problems here. The new printer had an E3D hotend that I had heard tons of positive feedback on. As soon as I added ColorFabb's PLA/PHA, the printer choked unless I printed at 20-30C above the recommendation.

After a month of trying to solve the problem without using extra heat, I gave up. I then realised that my roll of Ultra Marine Blue didn't have a consistent color? The color varied quite a bit along the roll. I contacted ColorFabb and yet again they replaced the roll. Excellent service, and this time half the roll have printed nicely. Strange?

Tangles! I never had that with any other vendor of plastic on spools hmmm

The PLA / PHA combo has major differences from other vendors. One is the addition of PHA, another bioplastic. It is apparently this that gives this PLA it's shine and makes it less brittle than other PLA. I'm by no means an expert on bioplastics, but there is something that makes this PLA/PHA mix more prone to stick to the inside walls of the extruder. Most often, you'll pull this buildup out with the filament after a blockage, but some will remain and must be removed with the "Atomic pull" method.

I've learned that most industry players use PLA from NatureWorks. ColorFabb buys their PLA from FKuR Kunststoff in Germany. I dunno what to say other than that it has some other (and less desirable) properties than the NatureWorks PLA. ColorFabb did however tell me that they only use NatureWorks PLA in their transparent PLA filaments and sure enough - it performs a lot better.

Colorfabb's response

ColorFabb says that the printer settings may vary (even among the same model) and that their recommendations can't work for everyone. I must say that I find frustrating to hear that from a vendor when all my 3 printers (PrintbotJr, Ultimaker Original, BAMM) as well as friends printers need to go to the same high temperatures to extrude it well. What makes this even more frustrating is that companies like MadeSolid publish guidelines for lots of printers and these worked for me right away?

I am now printing successfully with PETG from MadeSolid, PLA from Faberdashery, some really old ABS from Makerbot (back when they made 3mm filament), ABS from Protoparadigm, Proto-pasta's carbon fibre infused PLA, 2 year old PLA from Diamond Age, NinjaFlex, PLA/ABS/flexible rubber from PlastInk, PLA from Ultimaker and even Taulman 618/645 Nylon. Not a single blockage with any of these, but as soon as I insert the PLA/PHA mix from Colorfabb, my extruder will clog up. How fast this happens will vary, but I can't trust it for longer prints.

I just had to throw away two entire rolls of white PLA/PHA since the quality was so inconsistent that the layer height varied so much it was clearly visible (see below). Printing the same object with the same settings using Silver colored Ultimaker PLA gives me excellent looking results:

They're so different that you'd think it was printed on two different printers? This really is a shame as my two black rolls of PLA/PHA (made the same month!) will produce great looking results, even at fairly low temperatures???

I have completely given up on ColorFabb and it's a shame as they make so many cool things such as WoodFill, CopperFill & BronceFill. I just can't afford to spend more time on it as I've easily spent more than 100 hours cleaning out nozzles, solving clogs and failed prints. That's bad for business and not what I'd call "production quality". It's simply too inconsistent. I have a "trick" of working with it that "sort of" works and that's doing 5-6 atomic pull's with Taulman 645 Nylon before anything more than tiny prints. I'm also printing at speeds far higher than I like (due to the mass of the 30x30cm heated bed). This causes bandings in the prints, but then at least I can use the filament rather than just throw it away. It'll still get me plenty of jammed nozzles though.

Since MadeSolid now sells 15 different colors, so I'll get my PETG from them instead. As for PLA - rumours say that Faberdashery will soon begin shipping their 28 different plastics on spools. I guess I might buy my xmas filament from them instead.

BAMM settings for ColorFabb PLA/PHA

The BAM Makeblock printer has a BulldogXL extruder with a Hexagon nozzle. I use the following settings with PLA/PHA from ColorFabb:

  • Temperature: 220-240C
  • Speed: 70mm/sec (faster = less jams / clogs)
  • Retraction: 1.5mm @ 20mm/sec (less retraction = less deposits)
  • Extruder tension: screws 0.0mm out (solid pressure)
  • Heated bed: 50C
  • Fan: full (to compensate for excessive temp required to prevent plugs)

 

Teaching with robots

20 Oct

Teaching with robots

The last two years I've done a course in at Westerdals Oslo School of Art, Communication and Technology (formerly NITH). The school offers Bachelor & Master studies in informatics and I've been brought in as a teacher on the topic of Embedded Systems. The course (200 hrs total) is a volunteer topic for third year students that covers all the basic use of Microcontrollers as well as some Embedded Linux.

It's been a great experience and I get to play santa - giving students a customised version of this kit. 4Tronix have been very helpful in making me a super Arduino-kit that covers the entire curriculum at a price that the school can live with. The only part of the curriculum that isn't covered by this kit is robotics and motor control. This year I think I've found a near perfect solution that I though I'd share with other educators.

First year - cheap robot kits

The first year I did the typical thing - I looked up various robot kits and grabbed what I thought would be a decent kit. The problem with this approach was that I didn't know what kits were good and not. Price was also an issue. The budget ($150/student) only allowed me to get 4 kits. With 28 students, that wouldn't work too well so I sat down and designed the NITH Penbot. This little Open Source robot uses cheap stepper motors to navigate & a servo to lift a pen. That way you have a robot that can be printed in 40 minutes (body + 2 wheels) and the students could build them with the components they already had in their kits.

It didn't go bad at all, but a lot of time was spent on the assembly. The focus of the course is software for hardware, not soldering/gluing/crafting. Due to the time needed to put the kits together, we didn't do much robot driving the first lesson (4 hours each) and had to postpone it to the week after. This in turn caused other problems as the students needed their Arduino's so as soon as the robot driving was finished, they had to dismantle the whole thing to be able to do other exercises. We also realised that while popsicle sticks are a cheap building material, they're not very solid at all. In other words - my solution worked but was not ideal. I knew I had to find a better solution for next year.

Maker Faire Oslo

While teaching at NITH, I was helping my kids building robots at home based on the kits from MakeBlock. My son got a Robot Starter Kit first, but when my daughter saw how much fun her brother had - she wanted one as well. Perfect! Here I'm getting my daughter to jump head first into STE(A)M education! My son did all of his robot alone (apart from the remote), but I had to help my daughter quite a bit. The building itself went quickly, but her project required custom hardware & software so she couldn't do it all by herself. They had their own stand at MakerFaire and it was a big experience for them both!

Having seen the quality of the Makeblock kits, I instantly bought some kits for myself. Over this last year I've built several robots and even a 3D printer based on this system, so it was obvious to think about using the same robot kit with the students.

Second year - Makeblock

For my second year, I now have 34 students! More students = more kits. I was able to convince the headmaster that since the Makeblock kits could be reused across more years, we should spend the extra money. I split the students into 8 teams & we got started. The teams were split into two - one half focusing on building, the other on software & picking up batteries (not included).

A nice thing about the kits is that they come with instructions for two different robots that each have their merit - a tracked vehicle or a wheel driven robot.

The students could of course have improvised and built other robots if they had more time, but these two are a good starting point. I had deviced a challenge in the form of a labyrinth that the robots had to navigate. A tracked vehicle will usually slip if you drive too fast, so driving slowly is key with this bot. The wheeled robot is easier to contol precisely, but no team selected that design initially. The "tank-design" is just much cooler looking I guess?

I'm very happy with choosing Makeblock over typical Arduino-style kits with plexi and tiny screws. The first team had their robot kit up and running in only an hour! There were practically no questions about how to build the bots and since the robot kits have their own Arduino with builtin motor drivers, there was no need to disassemble the robots in between classes. The only issue we had were a beam that was too short and an Arduino board that didn't work 100%. This was no problem since we had a spare kit, so we used parts from that.

Here's a short video from both the building and the competition (with some cheesy music from the Youtube video editor):

Summing up

As opposed to the previous year, the students quickly understood the difficulty of programming autonomous robots. This caused them to come up with various mechanisms using code to better detect the surroundings. Many tactics were tried and we all had great fun looking at the results. If this was a robotics course, we'd have much more time to dwelve into some proper problem solving. With the 4-5 hours we have available, it's only a small introduction to a much larger topic. The students loved it though and some now even blame me for having given them a new hobby.

I achieved my main goal of getting more time dedicated to coding the robots, rather than building them. Nothing was destroyed and it's now all nicely packaged for next years students to use the kits.

 

Filament review: NinjaFlex rocks!

06 Oct

Filament review: NinjaFlex rocks!

I've been meaning to test the flexible NinjaFlex materials, but having an Ultimaker made that impossible. Flexible filaments and bowden tubes don't play well as the friction of the plastic makes it curl and stop. With the new BAM printer, I have a direct extruder mounted just above the hotend. This is the ideal setup for flexible filaments and with the newly fitted Bulldog XL extruder it's a snap to change materials.

It's incredibly strong!

I can't quite get over how solid objects printed with NinjaFlex are. They're soft in that they can be curled together, but will regain their shape easily. If you print a single wall of NinjaFlex (0.4mm thick) it will take a lot of force to tear it apart. My first print was exactly that - a single wall stretchlet.

My first reaction was how soft it felt? Then I tried to tear it apart and I failed? I gave it to my teenager son, but he also couldn't tear it apart. I then put my foot on it and pulled with full force by two hands... It expanded to 5-8 times the original length and then snapped just like a rubber band. Only when it snapped (main image) could you see any sign of layer separation. Amazing stuff!

Uses for flexible materials

The elasticity offers some very desirable properties. For instance, a 2-perimeter bracelet can also be used as a hair band in a crisis. It is perfect for making noise dampening rubber feet for your Makeblock printer, BMX grips, phone bumpers and RC tyres. Fenner Drives that makes the NinjaFlex filament, recently came out with more colors including silver & gold! I'm really looking forward to play more with this filament. I picked mine up from E3D along with other parts, but you can find it many places.

BAM printer settings

The BAM Makeblock printer has a BulldogXL extruder with a Hexagon nozzle. I use the following settings with Ninjaflex:

  • Temperature: 220C
  • Speed: <= 30mm/sec
  • Retraction: 2.5mm @ 20mm/sec
  • Extruder tension: screws 2mm out (almost none as friction is extremely high)
  • Heated bed: 40C
  • Fan: none

If you go faster than 30mm/sec, the plastic will curl up inside the BulldogXL extruder.

Filament Review: PET+ from MadeSolid

28 Sep

Filament Review: PET+ from MadeSolid

Some time ago I posted some tests done with Colorfabb's XT plastic. I'm guessing that the people from MadeSolid read that and wanted me to test their PET+ filament? I love testing new plastics so of course I said yes to getting some samples!

Just like Colorfabb XT, the PET+ material from MadeSolid is made from PET plastic so I expected the two to be kind of similar. PET is the plastic used in drinking bottles and food containers, so just from that you know it's solid. It's much more solid than PLA as it's not brittle at all. It's stronger than ABS and extrudes at temperatures somewhere between PLA & ABS.

More colors

I had actually looked at the MadeSolid materials just the week before as they could offer both transparent, translucent and opaque PET+ filament with a decent range of colors as well. Just last week, Colorfabb also introduced some opaque colors, but at the same time they upped the required temperature from 220-240C to 240-260C making them harder to use for many.

As opposed to Colorfabb, the MadeSolid guys offer extensive printer profiles for their filaments http://madesolid.com/printers It is quite interesting to see as this highlights how differently the various printers are tuned. A Leapfrog printer should be set to 225C, but a Makerbot should be at all the way up to 255C!

Testing

I really like how the final prints look. They come out glossy and the material is very easy to work with. There is a tiny amount of warp, but a brim is sufficient to hold things down on the build surface.

T-Rex at 0.2mm & UltimakerRobot at 0.005mm. One can clearly see that I need to tune the printer a bit more as I have some "wobbly" somewhere, but the prints look really good despite that.

I received about 5 meters of the clear & 10 meters of the white PET+. With this I printed quite a few tests, but I ran out of sample plastic before I got the settings properly dialled in for my printer. That is - I thought that I had it right, but when exposed to pressure it turned out the layers had not bonded fully?

I did some bonding tests and it seems that on my current Hexagon hotend, I need to go to 235-245C to get proper layer adhesion. Oh well...

The transparent PET+ actually seems a little easier to work with than the XT as I'm not getting these tiny blobs along walls that I do with XT. All the walls of the Raaco resistor-box came out looking perfect and the final print is so solid that I need pliers to damage it. When reflecting a light-source it also appears to be more shiny/reflective than the XT, though the transmissive properties are very similar.

Bridging & supports

Bridging was interesting. I had a model that has a decent bridge. It's 29mm so I didn't expect that to work, but initially it looked to be going well. Then the plastic started smearing onto the nozzle and things became really ugly. I set the print to pause, cleaned it up and kept running at a higher speed. That turned out to be a bummer. After a lot of cleaning, I realised that going slower was the best. Next time I'll use Slic3r instead of Cura so I can tweak the speed for bridges.

The print came out fine in the end and I was really impressed by how easy it was to remove the supports? That was of course related to the poor layer adhesion that I discovered later, but after testing some more it seems to be just as easy to remove PET-based support as it is to remove ABS.

I am really liking this plastic, so I just purchased some rolls with the translucent colors (red + blue) as well as opaque white. I wish that MadeSolid had more colors available (like translucent & opaque yellow, orange, purple & more), but I guess that'll come with time.

Next up for this weekend is testing flexible filaments. I have two rolls of NinjaFlex as well as "transparent rubber" from the Italian company PlastInk. Should be fun!

BAM printer settings

The BAM Makeblock printer has a BulldogXL extruder with a Hexagon nozzle. I use the following settings with PET+:

  • Temperature: 225-235C
  • Speed: 50mm/sec
  • Retraction: 2.5mm @ 20mm/sec
  • Extruder tension: screws 0.5mm out (quite solid pressure)
  • Heated bed: 40C
  • Fan: none

Just days after I sent my order, MadeSolid published a lot of new colors. Now they have 15 different colors to choose from. Pretty good!

Making a custom 3D printer controller

20 Aug

Making a custom 3D printer controller

While working on my new printer, I realised how ugly most reprap controllers are. All those I've seen use large SD cards & bulky oldskool LCD's with really poor contrast and viewing angles. Why not use Micro SD & an OLED screen?

You can actually build your own custom controller using any combination of screen, SD reader and encoder, but I couldn't find a good description of how to do it, so here it is. Setting it up with the Marlin firmware can however be a daunting task, so this article aims to document how I went about doing it.

I should start by saying that this is not "the right way" to do it, but I'm describing two of the many possible ways to do it. This description is for Marlin. If you are using Repetier on your printer, you may pick up some advice but the specifics will be different.

Picking the parts

My biggest annoyance with the typical LCD's used in these controllers is that if you're not standing directly in front of it, you can't really read the display. OLED displays use less energy than traditional LCD displays. They're easily viewed from any angle and have a fantastic contrast. I settled on one from wide.hk that has the required 20 (wide) x 4 (height) character displays. These are less than 4mm (1/64 inch) thick and has good mounting holes. Cost $34.

The SD card reader was something I had picked up from DX a long time ago A straight SD reader based on SPI. I got the encoder from Adafruit and I found a standard buzzer that was fairly small in a drawer. Pretty much any screen, SD reader, encoder and buzzer can be used.

Putting it together

Next is the fun part of figuring out how your controller should look! Grab your components and try to lay them out as smart as possible. Next you'll need a way to connect them together. A standard perfboard cut to 125 x 35 mm (48 x 13 holes) is what I needed. Your needs will probably be different, but using perfboard makes it easier to lay things out and solder it once you know how you want stuff.

Another alternative is to design your own professional PCB using software like Fritzing. It would be a good first project, but it takes time to get the PCB produced. You can also add indicator LED's and other custom components if you want to, but these will require you to add more custom code.

Finding your way around Marlin

I have a somewhat varied programming background, but C++ isn't exactly my native tongue. That's also my reason for doing projects like this - to learn more. I find the Marlin codebase a bit confusing. The root file is Marlin_main.cpp. The Arduino IDE will make a copy with .ino extension of this file when you start up the Arduino IDE.

At the top of this file is a load of #include statements. These are mostly files full of #define statements that are replaced by the compiler every time you hit "compile", but they also contain methods that will reside in a "global/root" namespace. Take the fairly central file "stepper.h". This is the header file for "stepper.cpp" that controls how the printer moves. None of the methods here belong to a class. They're just "there".

Coming from an object oriented programming background, I didn't expect this. I guess there's things/limitations such as dependency on interrupts that can force certain ways of doing things?

As far as I know, the first control panel for Marlin was added by fellow Ultimaker owner Bernhard Kubicek (thanks Bernhard!). After this, many others have hacked in support for their own panels. Over time, the codebase, and especially the config files, have become a little messy so it can be kind of hard to navigate.

Implementing your own screen

More or less any screen can be used, but it will require some modifications to the Marlin codebase. The first you'll need is a small library that can print characters to your screen. Most screens will have standard functionality for this, so if you're lucky you won't need to write more than a little wrapper-code. In my case I received a barely functioning code snippet, so I had to do a little more work. You can find a ZIP-file with my Marlin implementation here.

These are the main functions that your screen class will need:

clear();
setCursor(row,col);
write(uint8_t);
createChar(uint8_t, uint8_t[]); // custom characters such as temp meter
void printChar(char);

The clear() function obviously clears the screen and setCursor tells where the next character is placed on the screen. With these two and a print-command, you'll have all you need. But wait - print() isn't on the list? No, but if you look at my example OLedI2C.h class, almost at the top it says:

class OLedI2C : public Print

This means that the OLedI2C-class inherits all the functions in the print-class (Print.h) and expands on this. Without inheriting these methods, you'd have to write 18 functions to handle printing of all data types (uint8,uint16,char, bool, double and so on). The OLedI2C-class also "overwrites" the write-method. It changes the default behaviour of the Print-class to instead print to the screen we're implementing.

There's also two "special" commands in the list above. One creates custom characters (createChar) and the other prints it (printChar). These allows us the output graphical symbols for folder navigation, temperature, time and more. A standard "Character LCD" will typically have up to 8 slots for creating such symbols. If you're using a "Graphical LCD", you can create all the characters you want as long as you have the memory required. My implementation also has other methods, but you may not need these.

When you have a well working screen-class it's time to make the actual implementation that Marlin will use. You set this up as shown below.

Method 1 - modifying the existing classes

When you're building your own machine, you will need to make modifications to the Marlin firmware. There's two main methods to adding LCD support. The first involves adding it to the existing file "ultralcd_implementation_hitachi_HD44780.h" and use

pins.h - all I did here was to change the SDSS pin for my Megatronics 2.0 hardware (board type 701). Other than that I've kept all the default pins as defined. If you're using Ramps or something else, you'll need to look up what pins to use in the online documentation.

Configuration.h - Here I added a custom section for my screen:

// OLED LCD
#define OLED_SSD1311 // Oled based on the SSD131x chip series character display
#ifdef OLED_SSD1311
  #define ULTIPANEL
  #define NEWPANEL
  #define SDSUPPORT
  #define LCD_WIDTH 20
  #define LCD_HEIGHT 4
  #define LCD_I2C_ADDRESS 0x3c   // I2C Address of the display
#endif

The OLED_SSD1311 define is my main switch. If this is defined, it'll include the things below.

The ULTIPANEL enables encoder support. This is one of the more messier things in the codebase. This also enables other things but it does not cause problems for me. It would however be great if there was a generic define that just enabled just the Encoder and not other things related to SD card, menus & Ultimaker specific features.

NEWPANEL enables lots of LCD-related features, but is also used for Encoder-specific features. SDSUPPORT is really the only include that does exactly as it's name says. Width/height is used for menu scrolling and the I2C address is just there as it's "convenient to have". In my case I could just as well hardcode it in the class as all the screens of this type use the same address.

ultralcd.cpp - This is the main class controlling everything related to the screen and SD card file selection. It has static stub methods that serves as an interface for other implementations. Here I had to add an include-statement for my custom class:

#include "OLedI2C.h"

OLedI2C.h & OLedI2C.cpp - header and implementation of the custom OLED character display. You can also use a non-character display, as long as you provide the same methods mentioned above. Put these files together with your other Marlin files. I created most of this class in a small, separate project since uploading the whole of Marlin takes quite some time. For testing it's better to have a tiny project to test with or you'll be over-caffeinated well before lunch.

ultralcd_implementation_hitachi_HD44780.h - this is where you integrate an instance of your own screen. All that is needed is two edits. The first is to add the instantiation of your screen beneath the section that has the heading "Create LCD class instance and chipset-specific information". I added mine at the end of the if/elif/endif statements:

(other screens)
...
#elif defined(OLED_SSD1311) // OLED
  #include <OLedI2C.h>
  #define LCD_CLASS OLedI2C
  LCD_CLASS lcd;
#else
  // Standard directly connected LCD implementations

These blocks are compiler arguments, so the whole block will be replaced at compile time and only the parts that are #defined will be included in the compiled code. Next is that you add your init-call to the lcd_implementation_init() method:

(other screens)
...
#elif defined(OLED_SSD1311)
      lcd.begin(LCD_I2C_ADDRESS);
#else

This is the method I opted for as I generally like the way the typical Marlin LCD works. To go completely custom - read on…

Method 2 - creating your own implementation

What if you don't want the default contents on the display? What if you want to make a super-fancy, full color with lots of bitmaps-screen? Then you'll do the things above, but omit the changes to "ultralcd_implementation_hitachi_HD44780.h". Instead you'll want to replace the default instance of "ultralcd_implementation_hitachi_HD44780.h" and use your own file instead:

ultralcd.cpp - Remove the include at the top and instead add a toggle at the top of this file for the specific screen that included the right class if the OLED_SSD1311 was set:

#if defined(DOGLCD)
    #include "dogm_lcd_implementation.h"
#elif defined(OLED_SSD1311)
    #include "oled_1311.h"
#else
    #include "ultralcd_implementation_hitachi_HD44780.h"
#endif

myCustomOled.h - In this file (can have any name) you need to implement your own version of all the methods in ultralcd.cpp. The class holds an instance of the custom screen and handles all the actual hardware.

Be advised that this approach is more time consuming, but you could of course just copy the contents of "ultralcd_implementation_hitachi_HD44780.h" and modify only the things you need.

Things learned

There's always something to learn when doing a new project that you can carry over to coding in general. For instance - when you get the Arduino/C++ error "someClassName does not name a type" this basically means that the compiler can't find the definition of the class "someClassName". If you look closely at the error message it will usually tell you where you need to add an #include statement so that the compiler knows what to do. Probably obvious to seasoned C coders, important info for me grin

By doing this I've now implemented a full library for a custom piece of hardware with only a little to start from. I had to read the datasheet carefully and there were several things I could have added. This is how I hooked it up to my Megatronics 2 board:

End result

Size, readability and looks was my main reason to do this project. I'm quite happy with the results when I'm comparing it to the two most common Reprap Controllers:

Not only is my custom controller smaller - it's also thinner despite using standard components on a perfboard:

Is it worth it? I think so, but it could certainly be a good product just to sell a super-thin controller like this. I only need a single one, so it's not for me , but someone should make a standard reprap controller that looks as good as the Panucatt Viki LCD, but with an OLED grin
Next up: printing a nice enclosure for it!

Useful reading

Here's some links that I found useful when solving this project:

Partial description on how to do this http://www.justblair.co.uk/attaching-a-lcd-display-and-rotary-encoder-to-a-ramps-controlled-reprap-printer.html
#define's & pre-processing http://www.cplusplus.com/doc/tutorial/preprocessor/
Schematics for UltiPanel with rotary encoder http://www.thingiverse.com/thing:15081

This also gave me a chance to do some extra documentation around the Megatronics 2.0 electronics that I use for the printer.