Archive | November, 2016

Makeblock mBot review

02 Sep

Makeblock mBot review

One of my favorite tools is the Makeblock Robot contruction system. I've actually spent more than $7000 on parts, so you can certainly call me a fan! This weekend I'm hosting a robot workshop for kids and based on former experience, I suggested that we'd use the mBot robot kits. That suggestion has cost me quite a bit of time, so I'll take this oppourtunity to review of the kit to tell what's good & bad.

I sincerely hope that Jasen Wang (Makeblock CEO) and others will read this review and find it a useful tool to improve the product. At it's current state the mBot offering is unprofessional and not a good product.

What's good and not

Let me get that out of the way - the hardware and the entire kit itself is great! The build quality is solid and the electronics works like a charm. The mCore electronics board is compatible with Arduino Uno so it's easy to use. The instruction booklet is solid & all that is needed (apart from batteries) is included. What is lacking is two things: documentation and software. In the case of Makeblock, they are targeting the Maker Community and especially kids.

When you unbox the robot and build it the first time, it is pre-programmed with three nice modes: Line follower, obstacle avoidance & IR remote. These all work as they should - until the kid tries to do what is the whole intention with the kit - program the robot. When a kit like this is purchased by a non-technical person and it does not work, it's basically just a piece of trash?

Terrible software and documentation

The accompanying booklet is solid, so assembling is easy but then it's time to download software. Following the link to http://learn.makeblock.com/mbot-get-started/ will let you download either the Mac or Windows version of mBlock. This is based on the now abandoned offline version of Scratch and it really shows that the person that made this does not care very much about user friendliness. The main problem here is that mBot will NOT work in cojunction with the original Scratch commands such as "when Flag clicked". It will only work if you pull out the brick marked with "mBot Program" and stack commands beneath this. All other things will fail silently and you will have a kid sitting there thinking that both the robot and programming is stupid.

Most of the examples on the learning site will not work at all since they are based on non-working parts of Scratch. They do more or less also hint at this since if you check the "Arduino mode" menu item, you can see that other commands are being greyed out so why even have them there? They do after all have the entire source code for the Scratch program available, so it would be super easy to remove all the things that does not work. One such thing is that if you by accident check some of the menu items, your entire code will be corrupt since unsupported code blocks are just set to Undefined and are made red. I bet it's less than an hours job to make this program user friendly for someone that knew the codebase. All they need to do is to remove what does not work.

The Getting Started tutorial is also mixing in the Orion board (the larger Arduino-compatible from Makeblock) and that will confuse the users even more. It's just a mess. The Arduino code preview could have been really useful, but since nobody ever cared how it looked like (code formatting wise) it has very limited educational value. Placing a block of Motor control code at the top of all projects (even if it's not using a motor) just makes it messy, but I found the preview very useful when trying to figure out all the bugs in the software. If you've done something and it does not generate Arduino code, it won't work at all.

Oh - this is based on the Mac OSX version of the latest mBlock software (3.3.7). According to Avast Antivirus the PC version of mBlock is infected with malware so I don't feel like testing that just now… It could be fine though, but there’s room for improvement.

Poorly used support resources

The mBlock website also says that if you go to the Makeblock Forum, you will "Learn advanced techniques and get questions answered". This is very far from the truth. Makeblock used to have people employed for helping people on the forums, but for more than a year, practically all questions go unanswered unless they are answered by other community members (not affiliated with Makeblock). Unless they have fired all in their support team, someone is really not doing their job at all. They do however have a support-chat, but imagine how much more effective it was if these people just helped people in the forums? Then they could save maybe 90% of the requests?

There are lots of long Forum threads with unhappy customers that go completely unanswered and nothing happens when it comes to improving the software. This ensures that absolutely none of the customers will recommend Makeblock to their friends. Here's a great example, a user is so frustrated that he creates his own software that is much better than the original. Another example, a user asks how to blink a LED and is sent to an Instructable with incorrect info and defunkt video links. If the person asking tried to use this example with either his mBot or an Arduino, it wouldn't work.

Pin mapping for Makeblock mCore (mBot main board)

What does work is using the mBot with Arduino, but only if you fix some obvious mistakes in the Makeblock library (see below). It is however impossible to figure out HOW to use the RGB LEDs, light sensor, buzzer, button, IR input and other integrated pheripherals in the mCore board. It's just not documented either on the Wiki or in downloadable documents.

The first four ports are well marked on the mCore board itself: PORT_1, PORT_2, PORT_3, PORT_4. These are where you plug in sensors such as the accompanying Ultrasonic & LineFinder module. The remaining pheripherals is a different story. In a classical Chinese fashion, they are not documented at all. If you have been trying to access any of these, here is my unofficial documentation of how to use these:

PORT_6 Maps to the onboard Light sensor (LDR). Use with the MeLightSensor class.
PORT_7 Maps to the two onboard RGB LEDs. Use with the MeRGBLed class.
PORT_8 Is mapped to the Buzzer, but isn't used in any example. Instead you should just use pin 8 to access the buzzer (as in the default Arduino examples)
PORT_9 Is the same as motor 1. This will work with most sketches since it maps to M1. Use with MeDCMotor.
PORT_10 Is the same as motor 2. This will work with most sketches since it maps to M2. Use with MeDCMotor.

The IR receiver looks to be mapped to pin 3 from the schematics, but if you use the MeIR class like this you don't need to think about it.

To use any of the examples in the Makeblock library with mBot, use the PORT values above + replace the include for "MeOrion.h" with:

#include "MeMCore.h"

That should make most things work, but this should of course either be as comments in the code or be documented in the Makeblock Wiki. Sadly, it is not. The way I figured this out was by reading the schematic (that luckily is public) and some testing. Most people would have given up long before that.

It's not getting better

Code quality has gotten much worse over time with regards to Makeblock. I know they are growing, but their team has lost many talented people that actually had decent English skills. Their current support department is an insult. Language is always a problem, but they also lack basic knowledge about their own products. In terms of software, they regularily steal other peoples code and pass it off as their own by removing license information.

Just to name a single class, the MeStepper class is directly stolen from Mike McCauley's excellent AccelStepper library. They have deleted his version history as well as his copyright notice and replaced it with "Copyright (C), 2012-2016, MakeBlock". Unless they have signed an commercial agreement to use his library, this is just incredibly rude and also downright theft?

It's not just his library that have been stolen. Makeblock have a bad habit of republishing other people's code without following the original license that came with it. Not just that - they will also often make it worse than the original. A good example is that if you download and install the current Makeblock libraries according to their instructions, you'll get nothing but troubles. They've included their own versions of several standard libraries such as the Servo library and they didn't even check to see if it compiled. You can get around this problem by deleting the entire "utilities" folder that they include. This folder holds duplicate versions of files that already come with Arduino and they are not meant to be duplicated like this. You must also update the references to these files in some of the other source files:

#include "utilities/servo.h"

to the correct:

#include "servo.h"

The above change will remove errors & ensure things work like they should.

Conclusion

I'll manage to make a good workshop with mBot, but this is DESPITE and not BECAUSE of the quality of the Makeblock's software and documentation. I had to give up on mBlock, fix their library, research to find the missing documentation and I ended up using the Arduino IDE since mBlock is in such a sorry state. I'm amazed that they still have not solved these extremely basic problems within their organisation, so I hope this review can put some fire under somebodys butt before they ruin the last remains of credibility they have. Their last Kickstarter Codeybot was a pure consumer product and if they deliver similar quality - the consumers will completely ruin their entire business with bad reviews. They really need to brighten up!


Update 2 November 2016

I just realised that installing mBot screws up your Arduino IDE installation. It distributes a full Arduino IDE inside their app that will be outdated. This may then cause compilation errors. Not the best way to do this either.

 

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

Project: Makeblock 3D printer

13 Jul

Project: Makeblock 3D printer

Up until now I've had two 3D printers. My first one was the Ultimaker Original and it now has more than 4000 hours of printing behind it. An incredibly solid machine! The next printer was the Printerbot Jr that my son put together. I haven't seen much of it as he's more or less confiscated it, but it's been a great investment into making him try out some real engineering.

The Ultimaker Original is probably the best Open Source 3D printer available today. Now I've built a third printer from scratch, using the Makeblock aluminium extrusions that I've become quite fond of. You can find the build log here, but why did I want to make a new printer?

Makeblock advantage

When you are making a printer based on Makeblock it is really easy to adjust the design as you go. It's also easy to add new elements when you need it. Not only that. When I at some point retire the printer, I can re-use all the Makeblock parts for something else! Makeblock was started as a Kickstarter and they really listen to their customers.

Less hassle!

The single thing that takes the most time for Ultimaker owners is clearing out blockages. They don't happen if you're careful, but every now and then you'll forget turning off the extruder and the heat'll sneak up the pipe to cause a block. When blocks happen this far up in the extruder, it'll take 10-15 minutes to clean it out. The new all-metal hotend from e3d & extruder design solves this completely and changing filament is done in a snap. Over all, I'm REALLY happy with this!

Polulu DRV8825 FTW!

I'm using original Polulu DRV8825 stepper drivers. This gives me 1/32 stepping that is noticeably more silent than the typical A4988 drivers with 1/16 stepping. These are also more powerful, but in reality I'm not using that advantage. If you have a noisy printer, be sure to check this video for a comparison. They're a direct replacement for 4988's on most Reprap hardware, so odd are they'll make your printer more silent too.

More space

The new printer has a bigger print area (31 x 31 x 34 cm). This was one of the goals of the printer and I'm very happy that I managed to go even a little bigger than anticipated. For comparison - it's 32600 cm2 are more than 4 times the volume of the Ultimaker (7700 cm2). It makes levelling the bed a little harder, but it's totally worth it just to have the ability to print larger objects.

More materials

I've changed the design to a Direct Drive Extruder that takes up less space than the original design. This allows a second extruder to be added at a later time. A Direct Drive Extruder it has one major advantage over Bowden-based systems: it supports virtually all the materials I want to experiment with. Flexible plastics, nylon, wood, clay, bronzefill and more. The current setup allows the extruder to go to 300C. With modifications, I can go all the way up to 400C if I want to.

Flexible

Using Makeblock makes the entire design flexible, but the compact extruder design itself is also quite flexible. One addition I'm working on is adding Dual extrusion as in this video. It's the best approach to dual extruders I've seen to date, so expect an update when I get this working! The design allows me to easily swap out the print head fairly easily so I can play around with extruding chocolate and other fun materials.

So - all in all I'm very happy with the printer! All issues are now resolved, so the design phase is complete. Only minor tweaks remain & the BOM is now online at reprap.org. For now the page contains links to resources & the bill of materials, but I'll also add build instructions to it later.

But - I've got more plans! My Ultimaker with 4000 hours of printing on it's back will soon move to Bitraf and in November I'll (hopefully) receive my first SLA-printer - the Titan 1!

X/Y robot with MakeBlock (Part 4)

17 Feb

X/Y robot with MakeBlock (Part 4)

Have spent a couple evenings on getting GRBL up and running now. Here's my notes from setting it up.

Compiling GRBL on OSX

At Oslo Maker Faire, I finally met Simen Svale Skogsrud from the Oslo firm Bengler. One of their/his many cool side-projects is GRBL - a machine control software used for CNC, laser and 3D printers. As soon as I saw the Makeblock X/Y gantry, I knew that I had to make it run GRBL. Since most of the guides available seem to think that getting GRBL onto an Arduino is difficult, I thought that I'd write a small guide/tutorial for how I did this.

Start by copying / clone the source files from the Github repository to your machine. The precompiled versions could work, but I'll need access to the source later.

Download what we'll need

If you don't have the Arduino IDE installed, go get it from arduino.cc. This contains all the command line tools we'll need, including avrdude (used for uploading code to the Arduino) and the avr-gcc compiler (converts source code to something the Arduino can use). The Terminal application is in the Utilities subfolder on your Mac /Applications/Utilities/Terminal. Open the app and type avrdude. If you get an error message along the lines of "command not found", we will need to setup the Mac to know where the AVR software are.

Adding the AVR tools to PATH

My original intent was to use LadyAda's tutorial (http://www.ladyada.net/learn/avr/setup-mac.html) for setting up AVR, but it's unfortunately quite outdated. Some of the external links are dead and I think it's possible to do this a little easier given that all the required tools are in the Arduino download.

Add your AVR-dude to the OSX path according to this tutorial. The AVR tool location on your machine will vary, but it will probably be somewhere inside your Arduino app folder like this:

/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/

After adding to the path, you'll need to close that terminal window and open a new one for the PATH to refresh. Typing "avrdude" in this new terminal window should now list all the options instead of "command not found". If not, go back to the tutorial above and try again.

Compiling the source

Now that we have the AVR tools in our path, we can go to the GRBL folder. I placed mine along with other Arduino code at /Users/jensa/Documents/Arduino/grbl/. Open open a terminal window and go to that folder:

cd /Users/jensa/Documents/Arduino/grbl/

To generate a .HEX file from the source code, simply type "make" and hit Enter.

If all goes well, you will now get a compiled program that you can upload to your Arduino. If something goes wrong, type "make clean" to remove the generated files. To see what other options are available, have a look at the "makefile" in the grbl folder. this is also where you'll adjust the compilation options if you're compiling for something other than an Arduino UNO (or other Atmega 328p-based devices).

AVR adjustments

To upload the hex file to the Arduino, you'll use "make flash". As long as the path has been set properly, that will compile just fine, but uploading it didn't go as planned. After figuring this one out, I found this official guide that could have helped me. To help others in the same situation, I'll leave how I got it working without this guide and the errors I got:

avrdude -c avrisp2 -P usb -p atmega328p -B 10 -F -U flash:w:grbl.hex:i
avrdude: can't open config file "/usr/local/etc/avrdude.conf": No such file or directory
avrdude: error reading system wide configuration file "/usr/local/etc/avrdude.conf"
make: *** [flash] Error 1

Looks like avrdude needs some custom configuration. Let's have a look at what's required. By typing "avrdude" on the command line, you'll get an overview of what's possible. From this, we can see that the "-C" flag allows us to set a custom configuration file. Since we are using the Arduino supplied version of AVR, we should probably use that config file as well. I found this file by using the find command in the terminal window:

sudo find / -name "avrdude.conf"

In my case, the path was:

/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf

so you're will probably be something similar. I added this to "makefile" after the other parameters for "PROGRAMMER" so that the line was now:

PROGRAMMER ?= -c avrisp2 -P usb -C /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf

Running "make flash" now returned a different error message:

avrdude: usbdev_open(): did not find any USB device "usb"

Right... That makes sense. In the Arduino IDE you're always specifying paths that start with /dev/ and such. You can find the correct port using the command

ls -l /dev/cu.*

This returns a list of possible devices and it's the same you'll find in the Arduino IDE. In my case it was /dev/cu.usbmodem411. Note: do not have the Arduino IDE open while doing this as it can cause trouble.

My "PROGRAMMER"-line in the makefile was now like this:

PROGRAMMER ?= -c avrisp2 -P /dev/cu.usbmodem411 -C /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf

I still got errors though:

avrdude: stk500v2_ReceiveMessage(): timeout

Ok. I've seen this one before. It basically means that your config is correct, but something is incorrect with the programmer. The programmer is set with the "-c" flag and here it's set to "avrisp2". That's the same as using "AVRISP mkII" in the Arduino IDE and that won't work with an Arduino UNO board. How about removing the number 2 so we get this:

PROGRAMMER ?= -c avrisp -P /dev/cu.usbmodem411 -C /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -carduino

Note the addition of -carduino at the end there? It helps with defining the right board. Ohhh! It's uploading! Now let's see if this works. We should be able to log onto the GRBL installation using the Arduino serial monitor. Bingo.

For figuring out the rest, I looked a lot at this tutorial that details how to use GRBL for a laser engraver. It's a little outdated, but has tons of good info!

For some defaults, I tried what is found on the GRBL wiki. That didn't work too well with the MakeBlock setup I have. Instead I ended up on using something like this:

$0=12.650 (x, step/mm)
$1=9.000 (y, step/mm)
$2=25.000 (z, step/mm)
$3=5000.000 (x v_max, mm/min)
$4=5000.000 (y v_max, mm/min)
$5=500.000 (z v_max, mm/min)
$6=500.000 (x accel, mm/sec^2)
$7=500.000 (y accel, mm/sec^2)
$8=10.000 (z accel, mm/sec^2)
$9=200.000 (x max travel, mm)
$10=200.000 (y max travel, mm)
$11=200.000 (z max travel, mm)
$12=10 (step pulse, usec)
$13=2500.000 (default feed, mm/min)
$14=192 (step port invert mask, int:11000000)
$15=25 (step idle delay, msec)
$16=0.050 (junction deviation, mm)
$17=0.005 (arc tolerance, mm)
$18=3 (n-decimals, int)
$19=0 (report inches, bool)
$20=1 (auto start, bool)
$21=1 (invert step enable, bool)
$22=1 (soft limits, bool)
$23=0 (hard limits, bool)
$24=1 (homing cycle, bool)
$25=224 (homing dir invert mask, int:11100000)
$26=100.000 (homing feed, mm/min)
$27=500.000 (homing seek, mm/min)
$28=100 (homing debounce, msec)
$29=2.000 (homing pull-off, mm)

An error that had me stumped for a long time was that the limit switches would be hit all the time causing the GRBL error:

ALARM: Hard/soft limit. MPos?

I searched and searched until I found this post https://github.com/grbl/grbl/issues/226 regarding testing of homing in 0.9. Oh my... GRBL wan't to work with a 3 axis setup? How on earth could I know that... Well. I guess I could change the Z-axis a bit. That way I could even fit a Dremel on there? Hmmm! That sounds interesting...

X/Y robot with MakeBlock (Part 3)

13 Feb

X/Y robot with MakeBlock (Part 3)

Servo arm now works, but I'll need a few iterations until it's perfect. I''ve used this CC'ed design by jjshortcut as a basis. I'll publish the design on my YouMagine page when I have something good, but this isn't too bad. Oh wait... I'll need to not only grab the pen, but also lift it up...

Back to the drawing board. Take two is below. A two-servo setup and a slimmer servo-mount. These MakeBlock servos are almost a little scary in how fast and strong they are so I'll need to code some speed regulation for them.

I put the design iterations in front so you can see how it went from wide to narrow. No need to go that big.

I also found that the placement of the stepper drivers and other electronics were far from perfectly placed, so I did another rebuild of that entire part of the gantry. The idea is to mount all the stepper drivers with the back towards the far back of the machine. The black backside of these make up a nice "wall" that protects the other electronics. I'll eventually use four of these drivers: two for the Y-axis (pulls the X-axis), one for the X-axis (pulling the toolhead) and one for the Z-axis (moves the tool up/down).

Why two steppers on the Y-axis? The weight of the servo/toolhead makes the side that is not being pulled by the belt lag behind. This reduces precision quite a bit, so I'll solve this by driving this axis with a motor on each side, just like many 3D printers do. The pens will also be placed at the front of the printer, making it easier to see changing of pens and also what is being drawn. This new placement makes it much easier to work on the machine as well, since I can just tip the machine over and rest it on the back of the steppers. Works well and this is how it looks now:

 

X/Y robot with MakeBlock (Part 2)

04 Feb

X/Y robot with MakeBlock (Part 2)

Looks like I won't be able to progress as fast as I want on this project. Being a father, husband, freelancer and more takes away the hours, but I'll document the process here anyway in case others want to try something similar. Today I re-did the X-axis completely and also modified the Y axis a bit. In addition, I printed a cable chain so the wiring don't cause any problems as well as some endstop-mounts for Sainsmart/MakeBlock. Look mom - it moves!

This is starting too look like something. This is just a few lines of code with the AccelStepper library. Servo-arm up next!

X/Y robot with MakeBlock (Part 1)

02 Feb

X/Y robot with MakeBlock (Part 1)

I didn't take part in their Kickstarter but I kept an eye on MakeBlock since I discovered them. MakeBlock is a contruction platform just like LEGO, just much more solid. It's based on aluminium extrusions with 8/16mm hole pattern so it also works perfectly with LEGO Technic parts. After giving the kids one kit each for their Maker Faire robots, I got envious and ordered the huge Lab Kit for myself. Watching the kids robots progressing, I got really impressed with the build quality so I got the desire to create a robot project for myself .

The X/Y Gantry kit looked like a great starting point for a drawing robot. OK. I'll order that one as well as some parts. Seven MakeBlock orders later, I now have a basic gantry running. The original kit is so flimsy that I wouldn't want to move it, so I used the new 24x24mm extrusions as a frame to get stability. This means that the robot is fairly big and takes up a huge portion of my desk, but hey - it'll be cool.

Next up is building a servo gripper that can go pick up different pens. My current idea is to be able to encode images as RGB and then have the rbot draw that using Red, Green and Blue pens. We'll see how it goes smile