Archive | February, 2014

What platform next?

20 Feb

What platform next?

In 2013, Adobe completely dropped the ball on the Flash Player and AIR. All further development has been moved to India. This normally means that the software has been put in what is referred to as "Maintenance mode". Any serious bugs will be fixed, but don't expect much in terms of new features. If you take a look at the Release Notes for AIR 4.0, you'll see what I mean.

AIR will exist for many years still, but it's time to look forward and figure out what's next. What I'm looking for is a platform that will let me create both mobile and standalone apps easily, like Adobe AIR was but with a company that is still committed to the technology. Perferably with a solution that can create smaller and faster apps than AIR.

Some alternatives

For many years I wanted to look into Haxe, but I never got really into it. It was just to "techy" to get going. I really want a one-click installer that gives me all I need to get started. Some of my coder friends spent lots of time with Haxe and said really nice things about it. Other friends have looked towards Java. Joa Ebert has a nice thing going with Defrac and the demo video he published recently looks awesome. I don't want to move in the direction of Java though.

I've also looked at Corona. I really like the idea of using Lua as the main language but Corona only outputs for devices. I've played around with Unity a bit and that I really liked. It's very geared towards games though, so while it's fun, it's also not exactly what I'm looking for.

Ever since I started programming as a kid, I've shyed away from C & C++. Memory handling and pointers always seemed like unnecessary complications, but after playing around with microcontrollers with 2Kb ram and less, I've changed my opinion about that. The last two years I've done lot's of it and I'm really enjoying it. Seems like a good direction to go? Everybody said nice things about C# and Microsoft Visual Studio, but Microsoft don't have much of a story in terms of cross platform app publishing.

This autumn I've done a series of lectures at NITH on the topic "Embedded Systems". Great fun! One day during a break, I got a call from a former NITH student and acquaintance asking if I had any plans after my teaching duties. 

Outracks & Uno

Some days later I were in the offices of a company named Outracks. This is a relatively small company with a massive goal. They're building a complete coding ecosystem from scratch, right here in my hometown of Oslo. With this I mean that they are creating a language called Uno that has compilers so that it can output to iOS, Android, desktop and more. That just sounds like an AIR clone, right? Not quite. Uno is the first programming language to unify GPU and CPU pogramming. You write the app and all the shaders in the same language. The end result will run on both GPU and CPU and in many cases you don't even need to think about that part of it. The export is always a native app (no runtime bloat), but Uno also exports to HTML5/JS with 3D done as WebGL. In other words - you can make GPU accelerated apps for pretty much any platform with Uno.

They're also creating an authoring tool called Realtime Studio that is a complete coding environment with integrated preview, a solid code editor, inspectors, node view for code (loving this one!), drag and drop support, gui for various export targets and more. On top of that they're creating a UI FrameWork and exactly this was what they wanted me to help with.

The plan was that I were to develop a desktop app for a (still secret) client using their complete toolkit. Over a 1.5 month period I worked on the app and provided tons of feedback and I have to say this is shaping up to be one hell of a toolkit! The UI framework is completely GPU based and this does wonders when it comes to speed. Imagine having a slightly scaled down version of the Flex framework running completely on the GPU?

Why it's so cool

Uno is closely related to the C# language. If you already have C# experience, you'll be able to jump right into x-platform development. I however had basically no C# experience when I started the project and that was one of the things they wanted to test. How quickly would I pick up the language? What would I miss from other platforms? What would be the big hurdles?

Despite all the tools being under constant development, I would say that it took only 2 weeks to learn the language. After that I was fairly productive and knew where I was going. The next 2 weeks went by trying to understand and use correctly all the new goodness available to me that I never had in Actionscript. Uno has support for overloading, abstract classes, swizzling, lambda expressions, extension methods and much more. The last two weeks were really productive and we did reach a finished product. That said, it is still being actively developed and polished and I can't wait till I get to tell more about it.

The one thing that I still haven't wrapped my head fully around is writing shaders. While Uno makes this much easier, it is still something that I'll need to learn more about. Something also tells me that this is something that'll take quite some time as it's a quite different mindset. GPU's work in paralell and all operations happen on all pixels at the same time. That takes some getting used to from thinking more or less serially. What I can say is that I'm pretty sure that I've found what I'm looking for. This is actually the only platform that I feel comfortable spending my time on. Worst thing that could happen is that I've learned C#.

Uno will launch with lot's of official API's that are supported on all platforms. In addition there will be several APIs that are available for some platforms that you can download support for. Outracks has made a backend that is extendable, so if there is a feature you need in a specific platform, you can just add it yourself. It's like Native Extensions on stereoids. Want MIDI on the desktop? Find a premade library in the form of a DLL, write some interfacing methods and you're ready to go. This is going to be incredibly useful for those special hardware integration projects that I sometimes do for museums and exhibits.

Bottom line

I could transition in just a few weeks to a completely new platform. That's pretty cool in itself. Not only can I target iOS, Android, browsers & desktop, but Outracks are playing around with support for lots of other devices and platforms. In the office there were FireFox phones, Nvidia-boxes and lots of other interesting hardware. The apps I've made play with blazing speed and I've seen things that I've never before seen running on a mobile GPU. I can't say how much better that feels than seeing things like this go unnoticed. Having spent a lot of time in the Adobe Forums lately, I've seen many hundred important questions go completely unnoticed by Adobe. I need a platform with people that care and I feel that Uno is by far the strongest contender.

A public beta will be launched at FITC this coming week, so be sure to sign up for that. If you're actually at the event, make sure you catch one of the two sessions that Simo is presenting. He's been using Uno longer than anybody and he's made some seriously good looking things with it!

 

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!

Apple is not currently accepting applications built with AIR 3.9

03 Feb

Apple is not currently accepting applications built with AIR 3.9

From the 1st of February, you'll get the following error message when trying to submit your Adobe AIR based app to Apple's App Store:

    Apple's web service operation was not successful
    Unable to authenticate the package: somenumber.itmsp
    ERROR ITMS-9000: "This bundle is invalid. Apple is not currently accepting applications built with this version of the SDK." at SoftwareAssets/SoftwareAsset (MZItmspSoftwareAssetPackage)

From February, you'll have to build your AIR apps using the iOS 7 SDK (comes with XCode 5). In other words - if you are using Flash Builder or the Open Source Flex SDK to make iOS apps, you'll need to upgrade a bit. Adobe added support for this in the 4.0 Beta version of the AIR SDK that is now available on Adobe Labs. I do not know how this affects Windows users, but for Mac users you just download Xcode 5.x and use this instead of XCode 4.x. Next you download the AIR 4.0 Beta SDK and install it. Instructions for how to install/upgrade your AIR SDK can be found here.

With the beta and XCode installed, all you have to do is to up the version number to 4.0 in your App XML and maybe update the path to the new iOS simulator for testing.

Note: this only applies to new submissions. All apps that are already approved are still good.

 

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