Simple Drone Flying Algorithms

The AR Parrot Drone seems to be all the rage these days, especially here at the Neo Cincinnati office. Two officemates have drones, and they've taken to the office space and the hallways during lunchtime. The drone comes with piloting apps that control it in real time - but they can also be controlled programmatically. Work on drone drivers is progressing (one in Ruby, the other in Clojure) that can send commands to the drone.

A drome command is specified as a 5-tuple: (roll, pitch, yaw, altitude, duration) all relative to it's hover state. Once a command is complete, the drone returns to a hover state at its current location. From this it's relatively straightforward to make a drone fly in a simple pattern. Tilt and pitch define the forward direction, and yaw is used to change it.

To actually plan a pattern however, the command's values must be understood in relation to each other. Each is value specified in [-1, 1] in a drone command, and translated to an angle. Before programmed maneuvers can be created, scaling constants between angles must be determined. For example, consider flying one turn around a circle: the drone must be tilted forward (some combination of pitch and roll) and spun (a yaw value) over the time needed to complete a revolution.

(r_c, p_c, y_c, 0, t_c)

For a given tilt, spinning too fast spirals inward, while spinning too slow spirals outward. Too long or short a time will orbit more or less than one turn. Empirical studies of drone flight and timing must be done to determine these values. Assuming these values have been appropriately factored in then,

figure	roll	pitch	yaw	altitude	duration	notes
Circle	r	p	y	0	t	p&r = y
Spiral in	r	p	y	0	t	p&r < y
Spiral out	r	p	y	0	t	p&r > y
Figure 8	r	p	y	0	t	p&r = y t = one revolution
	r	p	-y	0	t
Tilted circle	r	p	y	a	t	p&r = y t = half revolution
	r	p	y	-a	t
3-leafed Clover	r	p	y1	0	t1	p&r = y1 t1 = two-thirds revolution t2 = half a revolution
	0	0	y2	0	t2
	r	p	y1	0	t1
	0	0	y2	0	t2
	r	p	y1	0	t1

Compound curves are defined as a series of simple pieces.

This is all fine, but to watch a drone move around a room in these sorts of algebraic patterns doesn't feel very aerobatic to me. The flying seems stunted and formulaic... more natural flight is a more complex dance of values. My best reference is a bird flying or fish swimming - when they maneuver, combinations of roll, pitch and yaw are smooth and complex. Changes in roll, pitch and yaw affect altitude. Coordinated moves are made to convert velocity into height. Soaring, diving, swooping - all feel like they should be aerobatic primitives.

Of course, these all will still be formulaic. But they'll look more natural. Somewhere in there is the beginning of the algebra of nature and what constitutes enough of this essence to feel birdish or fishish.

I'll be looking at this as our drones continue to learn to fly.

Laissez les bons temps rouler!

Starting on the day before Mardi Gras, I will be joining EdgeCase working in their Cincinnati office. To me, a much bigger party than they'll be having in the French Quarter!

This is a phenomenal opportunity, working alongside the genius of Jim Weirich and Scott Barron every day, and collocated with the Gaslight Software crew. (Let me tell you, this is a really smart room.)

Many thanks to Joe, Ken, Adam and Leon for taking the time to meet with me and make sure I'd fit there, and to everyone who's supporting me in this transition. To be sure, I'll miss the folks I've been working with, but I'm ready to get cracking on new stuff!

Prototype and Witch's Brew

When things work differently in one part of a package than they do in another - for no apparently good reason - programming indigestion may occur. When you beat your head against the code for too long trying to figure out why things are screwing up, big headaches are sure to come. The cause of my current indigestion and headache? Element.insert in prototype.

I have some javascript code that renders a string containing some HTML to be added to the bottom of the contents of a some target element. I do the necessary incantation,

Element.insert('target',htmlString)

Which quite promptly does nothing. WTF?

It turns out that the htmlString I'm sending either needs a javascript toElement method defined that will convert it into a DOM object or it must be a DOM object already. The first alternative is unpalatable - I just want to create html, not a tree of DOM cruft. The second is just as bad, unless I can get the work done for me. Fortunately, I can.

In the body of my document, I declare a special, invisible div,

<div id="_cauldron_" style="display:none;"/>

and I use it to magically transform my html string into an object that I can insert into the target,

Element.update("_cauldron_",htmlString)
Element.insert(target,$("_cauldron_").firstChild)

The cauldron is where the html must brew to make the magic happen.

You may be asking, "Why does the conversion happen differently in the update? Why doesn't the insert work the same way?" Good question. I have no good answer though. To my way of thinking, The conversion should happen exactly the same way - otherwise kludges like this are forced. Suffice to say that it's all a moving target and everything's always changing. I'm sure this one will get fixed in a future Prototype release (or maybe it is already, my version is not the latest) but it does get frustrating.

Though the indigestion lingers, at least the headache is a little better now.

A little Hash goodness

Some quick refactoring this weekend had me throwing together some tidbits.

module Enumerable

  # return Hash of enumeration to yielded values
  def collect_hash hash={}
    inject(hash) {|h,e| h[e] = block_given? ? yield(e) : nil; h }
  end

  # return Hash of enumeration to non-nil yielded values
  def select_hash hash={}, &block
    collect_hash(hash,&block).compact
  end

end


class Hash

  # return Hash with nil values removed
  def compact
    delete_if {|k,v| !v }
  end
  
  # array-style push of key-values
  def <<(hash={})
    merge! hash
  end

end

Yes, I know they've been done before, but they're quick one-liners and let me eliminate a lot of code. And as we all know, the easy code to maintain is the code you delete.

The Missing Link in RJS Chaining

One of the things that make Ruby and Rails my respective current language and web framework of choice is the collective ingenuity that has made building things easy. These folks have thought of everything, gosh darn it, and I get to use it. A good day is when I get something working, and with Ruby and Rails I have a lot of those days.

Imagine my dismay however, when on a recent project I had the need for something that wasn't already baked into Rails! The problem occurred when chaining partials together - one partial calling another, calling another, and so on down the line. I find myself doing it a lot these days, updating many parts on a page based upon seemingly simple model changes. Chaining partials together is easy, you just set up some context and render, and repeat.

Using Ajax and RJS is now a way of life; I got my baptism in the Javascript waters a long while back, a must for doing esoteric, dynamic rendering. RJS certainly isn't what makes such rendering possible, but it sure makes it easier. Some may think that there are better mechanisms - and maybe in special situations there are - but the simplicity and versatility of generating pieces of web pages using RJS is unparalleled once you understand the subtleties of building Javascript that will be executed in the context of a page.

Context is the issue. Let us say my foo partial renders my bar partial. The context is established as a hash of variables to values that is built by foo and passed into bar as the value of the :locals key in the render call. When bar is rendered, the hash is unraveled behind the scenes and the variables become available.

All except one, that is: the meta-variable that is the locals hash itself!

Unless I'm missing something, when you want foo to pass whatever locals it had received to bar, Rails comes up short! There's no way that foo can know all the variables that got passed in because this information is lost. The hash has been absorbed and is no longer part of the context! The variables in the locals hash that were set up by foo have been unpacked and established as the context of bar, but the containment itself is no longer available.

An argument might be made that making the locals hash available would be wrong; if the code knew it had the locals context, partial-coupling might be considered to be too tight. Perhaps so, but I'd say this really isn't true - assuming context in the form of injected variables is really at the same level of coupling. After all, what Rails is doing for me is just saving me some coding by allowing me to access a variable directly instead of as locals[:variable] if the incoming locals hash were exposed. The way I see it is that permitting a partial to access the incoming locals hash is actually promotes less coupling. A partial could just pass, augment and pass, or create and pass a new hash to the partials it calls - not necessarily knowing to what use the information in the hash might be put, or which partial down the line might be using it.

Chaining is about delegating responsibility - entities at intermediate levels really shouldn't have to be concerned with the details of what's happening above and below them. They should be able to pass information along with the understanding that if they don't need it, that doesn't mean that something further along the chain won't. If there's any doubt about this perspective, consider that partials are simply about rendering a page - the page is the real context and many complex renderings of application state changes may be made upon receipt of a seemingly simple event. That's what RJS is really good for - making multiple coordinated changes to a page. Allowing information to be passed down from on high so chained partials can use it according to need in the context of rendering different parts of a page is exactly why RJS is so sweet. Forcing intermediate partials to know what their subordinates need makes them difficult to write, hard to test, and downright painful to change.

Of course, just because this isn't automatic doesn't mean I can't do it myself. Passing foo a reference to the :locals hash as the value of the :local_assigns variable in the :locals hash it receives itself, for instance, allows me to pass it as the :locals hash to bar. Not a great solution, and it smells a little. Yes, it does mean I have to do some extra work, something Rails has helped me to otherwise avoid, but I can put up with this. Sigh. I sure wish the locals hash was already exposed - it is the missing link for chaining.

Bottom line: not having access to the incoming locals hash in a partial is a bummer, but it isn't the end of the world.