Category: Node.js
Jul 1, 2015
Update: Elio Tracker has been voluntarily deactivated due to some unexpected effects it could have had regarding Regulation A+. This form of investment is new and comes with some unique issues that a public data tracker like this brought to light. Further updates on the progress of campaigns will not be issued by this tracker, but the tech works!
Elio Motors campaign progress bar

Get out your rulers.

Elio Motors is a company attempting to bring a fascinating little three-wheeled car into production, and while they’ve made some very impressive progress (covered nicely on their blog), these things take money. A lot of it. In an effort to raise a part of the funds necessary to make it to production on time, Elio Motors has made a Regulation A+ crowdfunding offering enabled by the JOBS Act, but what the users at the Elio Owners forum found is that the campaign page itself gives little to no indication of its progress. Only by backing out to the site hosting Elio’s campaign can you see could you have seen a progress bar, and it’s it was tiny. There’s no indication of dollar amount, and no indication of percent completed.

Now I do understand thought I understood the thinking behind not including those things (though the following information doesn’t adequately cover the reasoning). This is a Reg. A+ offering, so no money has been raised, and any dollar amount would be irrelevant because that number only translates (roughly) to “interest.” In other words, no matter what the dollar amount comes out to, Elio Motors may never see a penny of it if the SEC filing doesn’t go through, or if the interested investors become uninterested. Still though, I like data, and so do the people on the forums.

The key point here is that the progress bar is getting its width from a CSS property, and as I’ve covered in a previous post about YQL scraping, I can use Yahoo!’s YQL to pull a copy of the page’s HTML and then filter out everything but that property with increasingly specific regular expressions. Combined with a timestamp of when each scrape occurs and an educated guess as to how much Elio Motors is offering in total, I can estimate percentage complete and dollars raised at any given time. Plot that out on a chart and you’ve got a pretty good campaign tracker.

Elio Motors realtime crowdfunding tracking at eliotracker.com

To implement this as a realtime web application and limit the number of YQL queries I’d need to send, I went with a full-stack JavaScript strategy using Meteor. The server performs the scrape once every thirty minutes, then saves the percentage and timestamp as a record in a MongoDB collection that gets synced with the client. On the client side, a chart from highcharts plots a line using the data found in the collection, then uses label formatters to turn that data into human-readable information. In this way, all heavy lifting is performed by the client while the server focuses only on handling connections and occasionally doing a quick YQL scrape.

The resulting tracker is available until the end of the campaign at www.eliotracker.com.

What I’ve found is that it’s very entertaining to check in on the chart from time to time. There seem to be some general patterns to the times at which people show the most interest. The project should be especially interesting when Elio Motors gets additional publicity that could lead more potential investors to the campaign, such as the Reddit AMA on Thursday, July 2.

Dec 3, 2014

One point that became immediately clear upon running my Raspberry Pi remote control car was that any decent control system needed a way to accommodate new hardware and improved scripting without requiring significant, irreversable modifications to the program. The bot needed a way to accept easily upgradeable bite-size plugins to control things like moving forward or turning left–plugins that could accept a level of customization such that the GPIOs used could be arbitrary and their behavior could be subject to environmental factors like signal quality and altitude. In essence, I wanted a way to throw in a scripted-up steering servo without losing the ability to still steer with a regular hobby motor, and without leaving the unused steering scripts for the hobby motor in there to dirty up the code.

The mill in action

To this end I began working on a component of the car I call “the mill.” The mill’s job is to provide an API to execute “sequences,” which are objects that define how a particular physical action should occur. Each sequence contains, among other possible properties, a run script, a stop script, a list of conflicting sequences (e.g. the bot may not attempt to turn the drive motor forward and backwards at the same time), and a time-to-live value to protect against runaway on signal failure. The mill accepts requests to run sequences, safely kills off conflicting sequences, and handles the refreshing of timeouts of active sequences as control requests arrive from the client (or enforces the TTL if they don’t).

The nice thing about using the mill is that the node server remains clean. Instead of shoving the script to send quartets to a 28BYJ-48 stepper motor in with the main control script, it can be abstracted out as a sequence and included in the main script as a require. Then, calling it is as easy as mill.execute(stepperClockwise); . Is the stepper already turning counter-clockwise? Don’t worry about it–the mill will identify the conflicting action, stop it, and execute the new action. Got a better idea for how to move the stepper? Upgrade the code within the sequence without touching the main program. Switched motors? Delete the require of this sequence and pop in a new require for the new motor’s sequence. Switched GPIOs? Just configure the sequence with goforward.pin(18); after the require.

Beyond the benefits of not shorting out the bot and not having to chase after it when the signal fails and the drive motor doesn’t shut off, using the mill also allows commands to have relationships in the form of soft stops versus hard stops. As an example, if the steering wheels are currently turned left and a new command arrives to turn them right, that command would trigger a hard stop on the left turn sequence (i.e. the left turn sequence would safely turn off, then the right turn sequence would begin); however, if the steering is currently at 20% left and a command arrives for 80% left, performing a hard stop (steering from 20% left to straight, then to 80% left) wouldn’t make sense. In this case, the sequences can be set to have a soft stop relationship with themselves so that two different consecutive left turn commands can occur without a gap in which the steering returns back to zero. Further implications of this would be that sequences can have relationships not just with themselves, but with each other; therefore, a hard stop triggered by an expired TTL on one motor of a flying bot could trigger a hard stop on the other three motors, and that hard stop script could specify that the bot smoothly reduce motor speed over time for a soft, autonomous landing.

Enjoy a video of the mill in action 🙂

Nov 23, 2014

As part of an ongoing series of improvements to a remote control car I bought at a thrift store, I needed a stream of GPS data from a Sierra Wireless Overdrive Pro 3G/4G hotspot (which, coincidentally, I also picked up at a thrift store). After registering the device with my carrier, logging into the admin […]

Continue reading...
Fork me on GitHub