Wednesday, October 22, 2014

The Tech Inside the Hendo Hoverboard

Today a product was listed on Kickstarter that has the tech world drooling. Since you are reading this post I’ll assume you know all about the Hendo Hoverboard from a PR/marketing standpoint. What is missing from all of these articles is a good explanation of what exactly is powering this amazing device.

As a disclaimer, I have no affiliation with the company and have no real insight into the inner workings of the device. I am also not a physicist, so my explanation of the architecture will be very crude.

The basics

The Kickstarter page gives some basic insight into what makes this magic possible.

Lenz’s law explains how eddy currents are created when magnets are moved relative to a conductive material. These eddy currents in turn create an opposing magnetic field in the conductor. Our core technology, which we call Magnetic Field Architecture (MFA™), focuses this field more efficiently.

I have only recently become aware of this phenomena through MIT ope courseware and some Youtube videos. Here is a demonstration of the effect using spherical neodymium magnets and a copper pipe:

http://mit.tv/yXa6Ym

The basic principle is that when a magnetic field is moved relative to conductor, it induces a current in the conductor. This occurs even if the conductor is non-ferromagnetic (i.e. a magnet won’t stick to it). Since a current flowing through a conductor also produces a magnetic field, the conductor will emit it’s own magnetic field but only while the magnet is moving. The magnet’s field and the conductor’s field now interact in much the same way as two magnets do.

Levioso

So how do you use Lenz’s law to levitate something? Just move high power magnets over the surface of a non-ferromagnetic surface like aluminum, copper, silver, or even gold. I found a great example of this technique from way back in 2009:

http://youtu.be/dw73DcwIX-A

In the video, Scott Stevenson explains that the neodymium magnets are placed with alternating poles. This is responsible for the repulsion felt by the disk.

I understand it this way. As a magnet is rotating over the conductors surface, it induces a sympathetic magnetic field that would attract the magnet. Then the magnet rotates away and the next magnet, with the opposite pole, passes over the surface. This repels the magnet for a brief time, until the movment of the magnet reverses the direction of the current and creates the opposite field, attracting this new magnet. Then the cycle repeats. Again, I am not a physicist, so take this with a grain of salt.

Now make me a hoverboard

In the comments for Scott Stevenson’s video a user quickly recognized the potential of this technique:

comment

Ironically, this comment received only 1 upvote…

I’m not sure if this very public disclosure of a potential use for this technology will interfere with Arx Pax, LLC’s patent endeavors, but it gives me hope that at least some of this technology will remain unpatentable.

So how does the Hendo hover so steadily? I have some experience tinkering with quadcopters, so I immediately recognized the 4 motor configuration.
enter image description here

Even the small “Developer Kit” called the Whitebox has this 4-hover-engine design.
enter image description here

With spinning disks in each motor unit, the board must use counter-rotating engines to negate the torque of the motors.

enter image description here

As with quadcopters, varying the spinning of these disks allows you to rotate the body.

enter image description here

There is also the issue of lateral movement demonstrated in the Kickstarter video by the Roomba-like robots. This could be achieved by slowing the engines on the side of the target direction, but I didn’t notice any tilt as the robots moved and changed direction. So I believe this is actually achieved by rotating the spinning disk slightly and pushing off the surface at an angle.

So it’s not magic?

So there you have it. Its not hard to understand and apparently is not hard to implement.

It seems like the bulk of the work that Gregg Henderson did was to modify the existing quadcopter stabilization algorithms to work inverted. So what does one do with an idea like this? The Kickstarter page tells us:

He labeled this epiphany: Magnetic Field Architecture (MFA™). Then he trademarked and patented the hell out of the idea.

While I love the idea that I will one day finally get my hover car, I can’t help but feel like there won’t be any more innovation in this field until the patents run out (think Segway).

But individuals tinkering with hardware don’t have to worry themselves with patent infringement. So, I hope to see some even more amazing uses of this technology by the maker community very soon.

Tuesday, July 30, 2013

Resurrecting a dead Emotiv EPOC

I pulled out my 2 year old Emotiv EPOC yesterday to use it in a project I'm starting. To my great disappointment it was completely dead. I was googled around and found that a few people have had this same issue. When I saw the specs on the lipo battery (3.7V 800mAh) I was hopeful that I might have a similar one laying around. I spent a few minutes digging around in my spare parts cabinets and boxes and SUCCESS! I found an old lipo 3.7V 850mAh battery I ordered from Sparkfun a while ago for... I don't even remember what. Obviously it was fate, right?
I disassembled the battery housing over the left ear. Really its just one (well hidden) screw so "disassemble is an exaggeration. Thanks to bluetrevian for his pictures on how to do this.



I noticed immediately that the old lipo was swollen so I was confident that this was indeed the problem. The next concern I had was whether the new lipo would fit. Luckily it did with the help of a Dremel. There is a little tab that secures the old battery. I had to grind it flat, which made the new battery fit PERFECTLY!



I just spliced the existing battery wires, soldering them together and covering the join with heat-shrink.



Then I reassembled the unit and turned it on... PRESTO! Beautiful little blue light! I plugged in the headset to make sure it would charge correctly and so far it seems to work like normal.



Hopefully this will help some of you revive your old hardware and prepare you for the next part of my project... more on that next time.

Wednesday, March 6, 2013

Cannot Perform Operations on a Metamorph

I'm working on an Ember.js app and was pulling my hair out for hours trying to figure out what was causing this error:
Cannot perform operations on a Metamorph that is not in the DOM.

It turns out I had commented out a section of HTML with an embedded binding.
<!-- <p>Stage: {{stage}}</p> -->
Ember doesn't deal with this well. It actually generates the metamorph script tags but can't seem to find them when it tries to update the element.
<!-- <p>Stage: <script id='metamorph-3-start' type='text/x-placeholder'></script>0<script id='metamorph-3-end' type='text/x-placeholder'></script></p> -->
What's interesting is that it inserts '0' for the initial value but can't find it later. This may actually be a bug but fir now I'll just have to remember not to use HTML comments with Ember.js elements.

Tuesday, March 5, 2013

Ember.js - Lighting the Fire

I'm attempting to learn Ember for the second time. My first attempt was over six months ago and so much has changed that it might as well be a different framework. It's not going too great so far. I'm finding myself spending more time on StackOverflow than writing code. I believe the questions I have now plague every Ember newbie. I know that I will think these questions are dumb once I have gained more experience with the framework, but I thought I'd list them here in hopes that someone wouldn't have to spend hours googling just to find out that they are doing something in a way that is deprecated or outdated in the latest version of Ember. I better hurry though. Ember.js is evolving so fast that if it takes me more than a few days to write this post everything in it will be outdated.


What is the difference between App.Router.map(function()... and App.Router.map(function(match)...?

I found router examples using both variants and it confused the hell out of me. It seemed like they where both being used in about the same time period so I did not think it was a change in the framework but instead an variation in the use of the router.

One example shows something like:
App.Router.map(function(match) {
  match("/").to("home");
});
https://gist.github.com/tomdale/3981133
App.Router.map(function() {
  this.resource('posts');
});
Documentation

I've found that the RC1 release changed the way the router works and the documentation has it right this time. Here is how I match specific routes:
App.Router.map(function() {
  this.route('home', { path: "/" });
});


What is the difference  between {{template}} {{partial}} {{outlet}} {{render}} {{control}} {{view}}?


I found these articles and they sum up the difference pretty well:
I'll summarize them here based on my understanding of their purpose and the use cases for each. First, here is a basic layout that uses many of them:
<div>
  {{ partial "menu" }}|
  {{ render "account" App.currentUser }}
</div>
<div>{{ outlet sidebar }}</div>
<div>{{ outlet }}</div>
<div>
  {{ control "ad" controlID="left-ad" }}
  {{ control "ad" controlID="right-ad" }}
</div>
<div>{{ view App.FooterView }}</div>

{{template}} and {{partial}}

These two are confusing because the Ember.js documentation does not mention {{partial}}, only {{template}}. However, most of the recent community tutorials use {{partial}} and say that {{template}} is soon to be deprecated.

As far as I can tell they have the same effect; they render a named template without hitting the router/controller/view (none of the helpers hit the router actually). They seem to be geared toward reusable pieces of html that don't need to interact with a controller. They are bound to the current context with no apparent way to pass in the model, so I have started wrapping {{partial}} calls with a {{#with}} block to define the context of the partial.
{{#with foo}}{{partial "foo"}}{{/with}}

In Rails using the Ember-Rails gem, this template will be loaded from _foo.handlebars. For an embedded template it will use the data-template-name attribute to find the template by name. The only real difference between these helpers is that {{partial}} expects the name of the template to begin with an underscore, although it will work without it and give a warning.
<script type="text/x-handlebars" data-template-name="_foo">
    ...
</script>

{{outlet}}

At first I was confused about the point of an outlet and the difference between {{outlet}}, {{render}}, and the new {{control}} helper. The name to me invokes the iOS style outlet that provides a channel for the controller to manipulate the view. It would make since then that the context of the named outlets is set by the controller that invoked this template. My current thought is that outlets define content specific sections of the page like content (obviously), sidebar, details, and sub-menus.

Outlets allow the content from multiple controllers to be displayed. They are the heavy lifters in an Ember app. An outlet is declared in a template like this:
<div>{{ outlet }}</div>
The default outlet is view so this is the same as:
<div>{{ outlet view }}</div>
Specifying a name for an outlet provides an id for the controller to differentiate outlets.
<div>{{ outlet sidebar }}</div>
As far as I can tell there is no automatic mapping of named outlets to controller (only the default one). This is something you have to setup in the router:
App.HomeRoute = Ember.Route.extend({
  renderTemplate: function() {
    this.render('sidebar', {
      view: 'sidebar',
      outlet: 'sidebar',
      into: 'application', // the template name?
      controller: this.controllerFor('sidebar')
    });
  },
...
});
This seems simple so just to confuse us there is also another way to do this using connectOutlets:
App.HomeRoute = Ember.Route.extend({
  connectOutlets: function(router, event) {
    router.get('sidebarController').connectOutlet('sidebar');
  },
...
});
I'm not sure if one of these methods is deprecated but I see current examples using both so I guess its a style issue. I prefer the connectOutlets method because it tells you exactly whats going on. You are connecting outlets.

It would seem that outlets should not require a model to be passed in but would instead hit the router to get data and be directed to a controller to determine what view to render. They actually don't hit the router however. It looks like the loaded route is responsible for setting up all named outlets. Ember.Route has a method called setupController that is used to load the model for the main controller as well as for the various named outlet controllers.
App.HomeRoute = Ember.Route.extend({
  setupController: function(controller) {
    this.controllerFor('sidebar').set('content', Ember.A([...]));
  },
...
});

This seems like it could cause you to duplicate code in each routes setupController. I've seen a few examples of creating generic routes and inheriting from them. So far I have not run into this problem. It seems to me that all this wire-up code could be removed if outlets could hit a route directly. Then I would just create an App.SidebarRoute. That way only the sidebar is ever concerned with it's model.

So my conclusion is that outlets are areas that render their own data and handle their own interaction but are for some reason dependent on the main content. Think of a sidebar that shows information related to the current product being viewed or actions that can be taken on the current post.


{{render}}

Render is just like outlet in that it creates the appropriate controller and view based on the name provided. The only difference is that the model is passed as the third parameter.
<div>{{ render "accountBar" App.currentUser }}</div>

This would create an accountBarController and set the content to App.currentUser. This never needs to be touched again for any route. The account bar will always show the current user.

There is one major problem with {{render}}. It can only be used once. This is very counter-intuitive because most MVC web frameworks have the concept of render and they have no problem being called multiple times.
Rather than fix the problem there seems to be an experimental fix in the works called {{control}}.. up next.

{{control}}

This is just like render but it can be called multiple times. I've tested this and found that while it does not throw an error like render does, it reuses the controller created in the first call. This means that if you call it in a loop like this:
{{#each post in posts}}
   <li>{{control "post" post}}</li>
{{/each}}
only one postController is created. Since passing the post variable sets the content of the postController, the last item in the list will be rendered in every <li>. This bug is being worked on. Supposedly you can pass in a controlID to differentiate them and a new controller will be created for each.
<li>{{control "post" post controlID="uniqueKey"}}</li>
I have not been able to get that to work because you can't easily use a distinct field on the model as the controlID. There is also a way to set a controller as a non-singleton, meaning that a new one will always be created when its resolved.
App.register('controller:post', App.PostController, {singleton: false });
I haven't tried this yet so I can't comment on whether this solves the issue.

Just as a last note, it seems that the {{control}} helper may be replaced by the new itemController in RC1. Since the individual itemController is already created within the #each block you can use a simple {{view}} call to render the template. This is covered next.

{{view}}

{{view}} is between {{render}} and {{template}}. It creates a specific view by class name and that view is responsible for defining the corresponding template. It doesn't create a controller. This lead me to believe that {{render}} should actually be called {{controller}} but thats off topic. Here is the basic use of {{view}}:
{{view App.PostView}}
Many properties can be set here directly. Binding the content would be done like this:
{{view App.PostView contentBinding="post"}}
Here is an example of how the {{view}} helper along with the itemController property helps to eliminate the need for the {{control}} helper:
{{#each post in posts itemController="post"}}
   <li>{{view App.PostView contentBinding="post"}}</li>
{{/each}}
I was able to get this working and it is currently my preference over using {{control}} in an #each loop. I did have to manually set the views template name even though it seemed to follow the naming convention:
App.PostView = Ember.View.extend({templateName:"post"});
I wasn't sure if this was actually hooking up the controller to the view but if I remove just the itemController="post" property it causes the databinding to break. So I guess this is correct.


Who is Metamorph, and what does he do?

Coming Soon!



How do I use Ember without Ember-data?

It's not that I don't want to use Ember-data, but I want to know where Ember stops and Data begins. None of the tutorials, documentation, or examples I have found use vanilla Ember.Objects as their models. Here is what I have found so far:

Coming Soon!


Tuesday, May 8, 2012

Lean Game Development

Lean Startups

I’ve recently been reading about Lean Startups. Audilble has a free 30-day trial with 2 free books, so I was able to listen to Rework and The Lean Startup for free! I’ve resorted to actually READING Running Lean, because there is no audio book available. These concepts have really changed the way I think about software development. I see the opportunity to lean things up everywhere.

SWTOR… /cry

Yesterday I was looking at the latest MMORPG games out there and it got me thinking about how bad SWTOR sucked. After 5 years of development and a ton of hype, the game was released with very serious usability and gameplay issues. Bioware seems to have left out all the core features that made the only other Star Wars MMORPG, Galaxies, so popular (before the combat “upgrade” of course). SWTOR's space combat is a terrible arcade game, and in a universe centered on “STAR” wars this is a critical mistake. I could go on, but I don’t think anyone can seriously argue any other case.

Lean Game Development

It made me think that game development could really benefit from a Lean workflow, MMOs most of all. I think a game like SWTOR could have been great with some early feedback from users, or as Eric Reis would say, at least it wouldn’t have wasted so much of our time.

It would require reworking the way MMO games release updates to players, because releasing 50 experiments as patches daily would be really annoying. Ideally, you would be able to push new content and adjust game mechanics without requiring a patch or forcing a logout.

I searched for a game engine that could support this workflow and ironically my search led to the HeroEngine, the same game engine SWTOR uses. So with a feature like Live Update built into the engine, why does Bioware follow such a waterfall approach? Who knows, and at this point who cares?

Cloud Game Development

While on the HeroEngine website I checked the price of a license and was amazed to find an Apple-like development plan. Only $99 a year for a license and a 30% cut goes to Idea Fabrik. It’s actually better than the iOS development plan because it includes up to 99 developers per license.

Even better, they have a cloud hosting service called HeroCloud that is included in the price. It also includes a way to bill customers, plugin support, and development tools.

This is great!!! it’s like Heroku for game development. Now get out there and show Bioware how to make a killer game!

Saturday, April 21, 2012

MacBook Pro Won't Sleep or Wake

The Problem

A few days ago I began experiencing major issues with my MacBook Pro. I had set my clock manually to 2013 instead of 2012 (I’ll leave it to you to guess why). This caused Chrome to warn that all SSL certificates on every website where expired. I tried to reboot to fix the issue (a real PC thing to do I know). Well either the Mayan calendar is programmed into Macs, or some startup script variable overflowed. My machine started hanging up halfway through loading the startup programs. At first it would start up with no WiFi, no clock and the spotlight pinwheeling when I moused over it.

Great Timing

This sucks for many reasons, the obvious one being that, like most nerds, I NEED my Mac. I need it to work on my iPhone development projects. It also sucked because RailsConf and BohConf are next week and I need it for the workshops. What makes it worse is that I have the money to get a new MacBook, but I’m waiting for the 2012 MacBook Pro to be released.

Shotgun Troubleshooting

I eventually figured out the clock was wrong, so I fixed it and rebooted again. I kept getting the same issue, no clock, no WiFi, and no Spotlight on startup. I tried an SMC reset, and a PRAM reset, with no luck. Somewhere I ran across an article about fixing an AirPort issue by deleting all the /Library/Preferences that say “AirPort” in the filename. I tried that and seemed to make some progress.

No Sleep or Wake

My MacBook seemed to start up fine, I had my clock, WiFi, and Spotlight back. However, when I closed the lid the machine would not sleep properly. The front light remained solid, the Apple logo would light up on the back, and the fan would run at high speed. It also wouldn’t start up when I opened the lid and hit the spacebar. I had to do a hard power off and restart it each time I wanted to use the laptop.

Still Better Than a PC

It’s a 13" 2009 model, and I figured it was probably due for some hardware failures. I bought a Windows laptop around the same time and it started failing to sleep within months of the purchase. I was actually amazed that it took my bottom-of-the-line MacBook 5 years to fall to the level of a mid-range Windows gaming laptop.

The Solution

I had given into the fact that I would be stuck with a dysfunctional MacBook through the conferences and for at least two months waiting for the new MacBook to be released. This morning I had the sudden inspiration to resort to desperate measures. If deleting some of the preferences helped a little, then deleting ALL the preferences should help ALOT. I backed up the /library/Preferences folder, deleted it and restarted (fingers crossed). To my relief, it started up fine, WiFi and all. I hesitantly closed the lid and eagerly watched the little white light for what seemed like an eternity. It started to pulse!!! I quickly popped open the lid and slammed the spacebar (a little harder than I probably should have) and the screen came to life.

Side Effects?

It looks like most of the preferences where regenerated with default values, but I’m not sure if there are going to be unwanted side effects. Let me know if you have any input on this.