Archive for the ‘RepRap’ Category

August 16th, 2013 @ 15:47

Kliment, of Printrun/Sprinter/4pi/… fame, has struck again. Sponsored by Joaz (jglauche@#reprap, who runs RepRapSource), he developed simarrange, a smart STL plater. Basically, you throw it a bunch of STL files or a directory with STL files, and it’ll attempt to fit them into plates of the given size (200x200mm by default, circular plates are also supported).
The algorithmic bits behind this are basically a greedy search, where the software tries to fit the items from biggest to smallest, and attempts to place each item closer to the bottom left corner first (or closer to the center) in any possible rotation. The spatial & angular rotation search granularity can be easily controlled using command line parameters. To decide whether an object can be placed at a given position or not, the object geometry is projected onto the 2D plate surface and bitmap-based logical tests are used to detect overlap.
This methods seems to produce tightly packed plates, as can be seen on these examples (the software outputs both the plate STL and these small visualizations):

plate24 plate19 plate07
plate22 plate18

Example plates produced by simarrange

I quickly jumped in to hack a few speedups, namely to avoid trying to fit objects which we already failed to fit on the current plate (in the case of making copies) and to detect if it is possible to make copies of each produced plate (which can save a lot of time if you’re plating dozens of printer kits for instance), and I contributed part of the code to make centered packing work. Kliment then added multicore parallelism yesterday (using OpenMP for full cross-platform support) to search over rotations in parallel. With all these optimizations, plating jobs which would have initially taken entire days now run in less than 10 minutes :)

Oh, and it’s already integrated to Printrun’s plater :)

Pronterface's integration of simarrange

Pronterface’s integration of simarrange

June 24th, 2013 @ 16:30

For more than one month now, I’ve been working on a daily basis on Printrun, one of the most used 3D printer host softwares (the thing that sends G-Code to your printer and lets your monitor how things are going). I had already given it a bit of love in the past, doing some internationalization and translation work, splitting the GUI code into a more manageable class-based patchwork or reworked the serial connection bits, but this batch of changes has much more influence on the user side.

Just to boast a little bit, let me quote Kliment, of RepRap/Sprinter/4pi/Printrun fame, who created and maintains Printrun:

13:52:12 < Kliment> On the sixth day, Kliment created the pronterface and the pronsole, and saw that it was…pretty crap. Then iXce came and helped out.

So, here are the main changes:

Cleanup of G-Code parsing

I initially came back to hacking Printrun because I thought loading G-code files was really too slow, and I quickly figured out that it was mostly due to the fact that we were parsing the G-code several times (there were at least 6 different G-code parsers in the code, and loaded G-code was parsed at least three times immediately upon loading). By rewriting and merging all those parsers, I was able to reduce the startup plus file loading plus visualization preparation time from about 13 seconds to 4.5 seconds on average, using a 3.8MB G-code file of about 140000 lines, while the new parser is also doing more things than the old ones.

Improvement of the remaining print time estimation

The previous remaining print time estimation was simply doing a cross-multiplication between elapsed time, number of sent G-code lines and number of remaining G-code lines, which happened to be very wrong in many cases: the early estimations were completely biased by the fact that we usually print the first few layers at a much slower speed than the other ones, and average G-code time means pretty much nothing (a long line can be 1 single G-code, while a tiny circle can be 50, while printing the line can take 20 seconds and the tiny circle less than 2, so you can have some G-codes which take 500 more time than some others). Thanks to the fact that we now have a complete understanding of the G-code (or actually just because we store more meta-information), we can now compute a much smarter estimate, based on the estimated total duration (the one you see after loading the file) computed on a per-layer basis, which we correct by incorporating a bias computed between this estimation and the actual print time for the elapsed layers. This way at any time the ETA should be within 10% of the actual ETA (unless you have a very, very weird machine), and should get closer and closer over time.

Optimization of the 2D print visualization

The 2D print visualization was really slow, and was even known for slowing down prints because screen refreshes were taking too much time. The drawing code was indeed redrawing every single line on each refresh, which would happen once for each sent G-code. We now buffer drawings as much as possible: complete redraws only occur when changing layers or resizing the canvas, every other refresh is done by updating a buffered bitmap with the newly added lines and drawing it to the screen. Visually, not much has changed except that the print bed extents should appear in a cleaner way (the yellowish background color does not leak anymore), that the grid should correctly start in the bottom left corner, and that thanks to other interface changes the resizing behavior should be much nicer.

The optimized 2D viewer, with proper resizing behavior, correct grid and different colors for background and build area

The optimized 2D viewer, with proper resizing behavior, correct grid and different colors for background and build area

Addition of a 3D viewer

Even better than optimizing the 2D viewer, we added a proper and very fast 3D viewer, based on tatlin, a standalone G-code and STL viewer originally built on GtkGLExt and PyOpenGL, which we ported to Pyglet so as not to add another dependency, and adapted it to use our already parsed G-code. As it uses the GPU to do most of the drawing (we store the model to display in GPU memory if possible, so that the CPU only has to tell “print from this vertex to this vertex with this color or GPU-stored color array”), it’s super light for the CPU, and as it’s done in 3D we can zoom (and zoom to point of interest), pan and rotate in 3D almost for free.

The new 3D viewer3D viewer (zoomed, panned and rotated)

The new 3D viewer

Addition of a clean, tabbed options dialog

Another nice improvement was the addition of a clean options dialog, with options grouped in different tabs and being displayed with appropriate widgets: checkboxes for boolean options, combo boxes for multiple-choices options, spin buttons for numbers, text fields for text options.

Old options dialogNew options dialog

Old vs. new option dialogs

Addition of a part excluder tool

This is probably the most original addition: a G-code based part extruder. How many times have you had a single part fail on a big build plate and had to stop everything just because the plastic was not being correctly deposited on the failed part and started messing up the whole print? Well, this tool is designed for stopping this kind of situations from happening. Just hit the Excluder entry of the File menu and draw a few rectangles over the area you want to stop printing, and you’re done (you can also do that to exclude parts of already sliced plates you don’t want to fully print nor reslice without the extra objects). It basically avoids going into the defined rectangles, resetting E values if needed instead of extruding, and seems to work fairly well with Slic3r-generated G-codes (I haven’t tested with any other slicing engine, and it could break because layer changes have to happen independently of X/Y moves for now).

Failed part excluder tool (right) and print simulator (left)

Failed part excluder tool (right) and print simulation (left) where I stopped printing two of the four objects after a few layers

Addition of new interface layouts

Based on the GUI code modularization from last year, we added two new interface layouts. The first one differs from the default one by placing the log viewer below the printer controls on the left side of the program, freeing more space for the print visualization:


Default (left) vs. compact (right) interface modes

The second mode is much more different. It splits the interface into two tabs, the first one holding all the printer controls, while the second one holds the print viewer and the log box. This makes it super compact and very well fit for tiny screens (it should fit in 700×600 pixels), especially when using wxWidgets 2.9 where it will use an appropriate widget for the main toolbar which wraps around automatically.


The two tabs of the Tabbed interface mode

Addition of a bigger temperature graph visualization

Last, you can now click on the small temperature graph (which can also optionally be disabled and complemented or replaced by the old temperatures gauges) to open a new window showing a much larger version of the temperatures graph for easier monitoring. Not the biggest thing ever, but still handy :)

Large temperature graph

The new large temperature graph

June 13th, 2013 @ 10:59

Here is one more hacking story, mixing 3D printers with the discovery of an awesome hobby: RC modelling.

TL;DR: Euromodel sucks, HobbyKing sort-of rocks, get an integrated IMU, watch our printed hexacopter teaser video :)

While coming back from the 2011 French Robotics Cup, we were discussing what project we could tackle next, and after making something that runs it quickly appeared that we had to make something that flies. We were willing to make something super stable, which could possibly go autonomously to a given GPS position (so an airplane was not an option) and we knew about Parrot’s AR Drone (a bluetooth-controlled quad-copter), so we decided to make something bigger: a hexacopter, which is a multicopter with 6 propellers.

We thus headed to the closest modelling shop (namely Euromodel near Gare de Lyon in Paris), nicely explained our needs and bought a batch of brushless motors, controllers, 8″ propellers, LiPo batteries and a LiPo charger as advised by the vendor. Using the dimensions of the motors, we designed the first version of our hexacopter, aimed for 3D printing:

Initial hexacopter design

Initial hexacopter design

The whole point of the design was to make something super sturdy, which would protect propellers from crashes. Traditional mutlicopters use a star-shaped design, where thin carbon fiber (or similar) arms stand out of a central frame, but we thought that materializing the hexagon and adding extra shells around the propellers would allow the drone to handle crash forces in a much more uniform way.

However, this design had a bunch of flaws that we hadn’t foreseen. The first one is that each part was fairly big, despite splitting the design quite a lot already (each propeller cylinder is split in two parts, and we could not split it more with the current design). The largest one was barely fitting the print bed of our Mendel printer (the part smallest bounding box was about 21cm*21cm), but was too big for my Prusa’s bed. Indeed, this is the first place where the vendor was not super nice: 8″ props are *huge*, but he claimed it was fairly hard to get smaller ones (and now that I’ve heard of HobbyKing, I definitely know this was a big, big lie). Another flaw is that the propeller protections were placed at the level of the engines, and not around the propeller which would be above the engines.

Given these flaws and given that our Mendel broke 3 days after we started printing this initial design (and that fixing it was beyond our motivation), we had to rework it to significantly shrink it to be able to print it on some other printer. We simply removed most of the outer shells, gaining a couple of centimeters, and removed the inner propeller shells, which were now useless. We also added a proper central electronics block with appropriate connections to the outer frame:

hackEns hexacopter Mark II

hackEns hexacopter Mark II

After pulling a few all-nighters to print the frame, the real issues with the hardware we had bought at Euromodel started to appear. Crap. It was complete crap, especially the speed controllers, which were cheap, now-discontinued models sold with some airplane sometimes in the past. We burnt a couple of them and still don’t know why they burnt, and burnt a few motors. One of the motors died because of another flaw of the original design, coupled with a flaw of the 3D printer: the inner diameter of the tubes holding the motors was a little bit too small (and the 3D printer was printing the circles even smaller than they were meant to be), and on one of them the motor got stuck while trying to spin, which lead to its death, producing a beautiful-yet-frightening orange-ish smoke.

hackENS's hexacopter being assembled

The beast being assembled

Sadly we had invested a bunch of money on this, and buying a whole new set of motors and controllers would have been too expensive (at least we thought so, once again, we did not really know about HobbyKing at the time), so we bought replacements. We bought the last two controllers Euromodel had, and bought replacement brushless motors from the US, and after a few more adjustments, discoveries, and fiddling with the electronics (such as painfully figuring out our ESC were only accepting 50Hz PWM input), we got it to leave the ground !

[vimeo width=”720px” height=”400px”][/vimeo] Flight and in-flight videos !

As you can see on the video, we had mounted a GoPro on the copter, which made really nice looking videos of the Cour Pasteur at ENS :)
Sadly, after just a few days, we broke it again, breaking two of the twelve arms that form the hexagon shape (damn, we knew the outer shells would have been useful, and we knew I’m a very, very unskilled RC flyer). We now need to either reprint new parts or modify the design to make it even sturdier.

Anyway, we also learnt that building such a machine is not all about designing the copter, printing the parts and assembling them. Flying a drone requires a very, very good flight control unit and sensors (and RC skills, but well, you can’t buy that). We initially planned to go super light and use an Arduino Nano plus a Wiimote-based sensor array, namely using the accelerometers from a Nunchuk and the gyroscopes from a Wii Motion Plus extension following the MultiWii models. As the Nano board was really too Nano, providing too few pins to be convenient enough, we ended up flying the MultiWii control software on a Flyduino Mega (an Arduino Mega fitted in a MikroKopter-compliant 5cm*5cm board (with 4.5cm spaced mounting holes)) and these sensors. The MultiWii software is an open source flight control system originally designed for AVR platforms such as Arduino. It’s a really cool piece of software, with an awesome community and a lot of good momentum, a bunch of tutorials and nice graphical tools.

We initially had a lot of stability issues, which were partially fixed by tuning the PID parameters. We could never completely get rid of all the issues, and eventually found out that our they were most likely due to the sensor boards not being properly lined up and stable in their mountings (i.e. the gyroscope board was not perfectly flat and parallel to the accelerometer board). We ended up ordering a FreeIMU board (which combines a 3-axis accelerometer, a 3 axis gyroscope, a barometer and a magnetometer, plus a sensor fusion device which processes all the readings), which seems to provide a much, much better signal than our original assembly according to the tests we made, though we could not field-test it as it arrived after the “final” crash. But we’ll fly it FreeIMU as soon as we repair the mechanical breakages, hopefully for the best :)

To conclude, if I were to conduct another such project, I’d probably directly jump onto using a proper IMU such as FreeIMU (or at least something well integrated on a single board), buy stuff from HobbyKing (they now have two warehouses directly in Europe, and shipping from Hong Kong is just a matter of patience) instead of spending hundreds of euros on crappy hardware (our crappy 15amps ESCs were 40€, HobbyKing has nice 30amps ones for less than 15€ in the German warehouse…) and would definitely reuse a MultiWii-based control platform (open source rocks, and the community is *great*).

May 17th, 2013 @ 14:37

Woha. It’s been such a long time since my last post. More than 2 years have passed since then, I’m now a PhD student in computer vision at Inria and I hacked on quite a bunch of projects.

Weirldy enough I did not do much pure software stuff (probably because I already code quite a lot for my research), but spent a lot (I mean, most) of my spare time on more hardware or hardware-oriented things, mostly in the scope of hackEns, the ENS hacking club we founded in October 2010.

Among other projects, we built a RepRap 3D printer, a Mendel one, in early 2011, with a first successful print on April, 22nd, 2011.

hackEns's Mendel 3D printer

hackEns’s Mendel 3D printer

A friend and I quickly started the replication process, building two Prusa i1 printers in August-September 2011 using plastic parts printed just-in-time with the Mendel. We continued the replication process with Jacques-Henri Jourdan, who slowly built a Prusa i2 starting early 2012, with a first successful print in late 2012, using plastic parts printed with my Prusa i1. That’s a beautiful chain of 3 generation of 3D printers. Over the builds, we have been amazed by the progressive technological improvements and the true capacity of the machine to auto-improve itself. During summer 2012 I almost reprinted all my printer plastic parts (the original ones were a little dirty and had clear defects that affected print quality), progressively transforming my Prusa i1 into a Prusa i2. One of the most striking things is that a 3D printer can produce better parts than the ones it is made of (and I’m not just talking about upgrades, but also about the print quality).

My Prusa 3D printer

My Prusa 3D printer

What’s also amazing is how fast the software side of 3D printing is evolving. Slicing, which is the operation of transforming a 3D object description in a printer-friendly list of commands, is definitely a non trivial task, both on the fundamental algorithmic side and on the engineering side. Indeed, it is done by slicing the object into successive layers along the Z axis and then computing where plastic should be deposited on this 2D layer, which requires a lot of geometrical computations and careful coding to correctly handle edge cases. Skeinforge was the first software I used to slice my objects, which was later improved upon in a fork known as SFACT. However these python-based approaches were quite slow overall (partly because of the language itself, partly because of the design decisions such as a complete modularity which might not be the best for such a software), and a few months later a new candidate appeared, Slic3r, developed from scratch in Perl with speed and efficiency in mind, and is now regularly evolving with better core algorithms and GUI features.

The possibility to print objects and the availability of 3D sensors such as Kinect (and software such as Kinect Fusion) has pushed replication possibilities way further than what we could have dreamed of 10 years ago. And for the hackers, it is now possible to build complex 3D objects from scratch, without having to painfully machine wood or metal by hand or with super-expensive CNC tools. If Thingiverse (or should we call it Makerbot Thingiverse now ?) is full of cute or pretty designs, it has also become a home for DIY hobbyist and hackers. Coming from a pure CS background with little engineering knowledge, we were able to develop a hexacopter (a multirotor unmanned aircraft with 6 engines) frame from scratch, printing it with our 3D printers and flying it (but I’ll tell you more about this project soon).

hackENS's hexacopter being assembled

hackENS’s hexacopter being assembled

The only sad thing overall is that some people are trying to leverage the interest in 3D printing technologies to make a lot of money by selling crappy printers. The number of 3D printer crowdfunding attempts which were started on Kickstarter is just unbelievable, often promising things that cannot be achieved with the technology they are using (like printing super huge objects which are not hollow without a proper heating chamber) or just trying to sell existing designs at crazy prices. It’s also sad how Makerbot is getting all the good press while at the same time they are going further and further away from the open source approach, but that’s another story.