Thursday, December 25, 2014

BotQueue client updates!

It's been only a couple of months since the last software release, but it feels like it has been far too long. Instead of releasing 0.6, I'm releasing 0.5.1 today. There are two reasons for this, which I'll get to in a minute. But first, features!

Makerbot support

Or at least, mostly Makerbot support. It supports all of the printers that speak s3g/x3g, so no 5th generation (yet). There is also way to slice things. I have a solution for that, it's just somewhat difficult to work with closed source software. For now, you can upload your *3g files and it will run them just fine. It also allows you to upload .makerbot files, but those aren't supported yet.

Automatic updates

This is something I've wanted to do for a long time, and is the first reason why this only jumped up to 0.5.1. I released version 0.5.0, and in the very next commit, released 0.5.1. This was to test the auto update feature. Every 2 minutes, if your bots are either in idle, error, or offline mode, the client will check to see if there's another version. If there is, then it will automatically update itself.

This means that installing the client is now as simple as "pip install bqclient". To run it, simply run "bumblebee" in your command line. No more "python -m bumblebee" or similar schemes. Also, make sure you run it in the same directory that your config.json is the first time. It will automatically detect it, and move it to the correct directory. If it's not there, it assumes this is a new install, and will start to authenticate.

Future plans

Those aren't the only updates at all, but it's the two major points in this release. Many more features are coming soon, but I was having an issue. I needed to know that the client code and server code would work together. The easiest way to do that was make sure the clients take care of updating themselves. The caveat to that is that it might upgrade and break. If it breaks before the point it upgrades, then it will have to be upgraded manually. It also means that all clients would break at the same time, something I'm not exactly happy about.

Nevertheless, this helps with future plans, and moving to the 0.6 release, which will definitely contain some exciting new features. I hope to release much more often. I've been keeping the server within a few commits of the current master branch. There are some changes I can do that would break clients, unless they are up to date. I'd like to get some feedback, but I think I'm going to set a day in the future (some time next year) where the server will reject clients below a certain version. This allows me to make sure that add the cool new features that people want, without constantly asking that you update the clients.

Thank you for using BotQueue!

Friday, October 24, 2014

FTDI: The Clone Wars

I saw an article on Hackaday that talked about an FTDI driver update on windows that purposefully set the PID of the device to 0 on fake or 'cloned' FTDI chips. I've also seen a bit of confusion on this topic, so I'd like to clarify a few points.

First, what is FTDI? Basically, this company makes products that allow micro-controllers to communicate to a USB host, like your computer. The make both drivers, hardware, and most importantly here, chips.

1) Many people aren't aware if they even have a fake

One of the first arguments that I saw was in regards to how users should be punished for using a fake chip. Most of the people using these products are using end products, or products that are made using these chips. It's much easier for someone to include an FTDI chip with their device than to go through all of the trouble and cost of getting their own Vendor and Product ID. So, some devices have these chips in them without their users ever really knowing. This means that if the vendor accidentally or intentionally used a fake chip, then some end consumer could have a device break and have absolutely no idea why. It would literally just stop connecting to the computer.

2) This isn't a user mistake

The second most common argument that I'm seeing is asking why on earth any user would expect FTDI firmware to work on a non-FTDI chip. One person compared it to trying to sue Sony when your Sony TV knockoff stopped working. A user didn't re-flash their chip and mess up by getting the wrong firmware version, or putting it on a device it was never intended to. In fact, what updated silently and without warning was the FTDI driver on the host side. The FTDI driver itself checked if the chip connected to it was fake, and if so, it rendered it useless by changing the Product ID to 0.

3) This was intentional

Many people don't seem to understand how this could be intentional. One commenter on the Hackaday article asked how they could be expected to support all of the clones. It's not that they tried a new feature that only worked on the real ones but not the clones. The essentially initiated a challenge response protocol. The gave the chip some data or some set of data. The official ones would return one thing, the fakes another. After the fakes were identified, they were dealt with with extreme prejudice.

How does it work?

The FTDI device essentially makes a serial port through its driver. A USB device has several layers to go through. The first of which is a device descriptor. The descriptor has a lot of information on how to go through the layers, but most importantly, it has a vendor and product ID. The vendor ID is unique to the vendor, and the product id is unique to the particular product or chip. This attack sets the product id to 0 which makes windows fail to acknowledge its existence. A product or vendor id of 0 is considered invalid, so it will no longer be recognized by the computer much less the drivers.

I hope I've cleared up a little bit regarding this issue. My opinion is that it might have been better to give a small alert to users letting them know that their chips are fake. I don't think it was within their rights to destroy peoples' products, mostly because they were not aware they were using a fake chip. However, even if they did know they were using a fake, I still don't think that they should have morally done that. As far as market share goes, it might be a good decision, it might not be. The answer to that will lie in whether people keep buying their products after this.

Tuesday, September 9, 2014

Setting up Bumblebee to run on boot

BotQueue's client code no longer requires there to be a tty to function. You could simply add a line in your /etc/rc.local file to run bumblebee as your user:
( su -c /home/user/bumblebee user ) &
the /home/user/bumblebee file would just be an executable that runs the python code. An example:
cd ~/Bumblebee/
screen -dR botqueue python -m bumblebee
It's a much simpler process than previously. This should work exactly the same on a raspberry pi too.

Monday, September 8, 2014

BotQueue 0.5 released!

I know it's been quite a long wait since version 0.4 was released on July 4th, 2013. Since that time, Zach Hoeken has moved away from supporting BotQueue in code, but he still believes in the project and has continued to help whenever possible. For that support, I want to thank him. Now on to the fun stuff!

I'm so excited to release this for a couple of reasons. The main one is that this is my first major software release, so I expected it to be a bit rougher. Still, I expect bug reports in the future, so please post those here for the server, and here for the client.

I was originally going to summarize every cool now feature about this release. This release doesn't have too many amazing new features, but it has quite a few bug fixes. I wanted BotQueue to be more solid than ever, because that's what you should be able to expect. This involved fixing everything from UI issues, to a ton of fixes in the background so that everything runs smoothly.

Some of the new features I'd like to introduce are:

Auto Slic3r downloading

It's not perfect yet, but it's definitely pretty awesome. Basically, instead of downloading a bunch of huge binaries, bumblebee has been stripped of any extra weight, making it fast to download, and easy to run. It will automatically download the slic3r version you choose for your OS. This also makes it easier to run other types of slicers like Cura.

Local storage

It's long been a request to support storing files locally on the server instead of having to set up Amazon S3. I'm glad to announce that this support now exists in BotQueue.

Easy server install script

Now, it's pretty easy to run install/ on your debian/ubuntu server. It will ask for some configuration values, and install everything it can for you. If the options are filled out correctly, your site will pop right up, giving you your own BotQueue instance. This is useful if you have a private university and want the students to use a local server.

All in all, I hope you enjoy the new release. If you have any questions at all, feel free to comment here, or ask on the Google groups.

Monday, April 28, 2014

DSLogic unboxing

Today, my DSLogic came in the mail. For those that don't know about it, it's a logic analyzer with the ability to act as an oscilloscope and a DAQ.

Here are the unboxing pictures for those that want to follow along with this review. Note that I haven't actually gone and analyzed anything, so that review will come later.

The first thing I noticed is that the box that the logic comes in looks nice, but isn't going to make a nice case for it at all. I would have rather had a nice case that all of the probes and everything would fit into that I could carry around. It has four phillips screws on the bottom, so if anything goes wrong with it, at least the case is openable. There's a little hole for an LED, that really needs a lightpipe because it's down inside the case. I'm sure it will still be visible, just not diffused as well.

After seeing some other reviews,  I checked the cables to see what they meant by the poor quality. I hate to confirm that they're correct, but they are. The wires are very thin, and seem breakable. I know that eventually some of them are going to break.

I really am not fond of the clips. The first thing I noticed is that the part where the wire attaches isn't only in the center back of the clip, but that the pin was at an odd angle. After bending it back, it hooked on decently well, but not as well as I'd like. I prefer the pin to be off to the side of the clip so that I can press on the clip with my thumb completely. Also, in the last picture, I notices that the probe uses more of a claw mechanism, rather than the hook that I've seen on previous probes, so I don't think it will hold onto the pins as well.

That's all for now, but I'll add more posts once I start using it.

Tuesday, April 8, 2014

BotQueue and Heartbleed

Have no fear, for the system is secure... well... almost. It's currently not vulnerable to Heartbleed, however we need to get new private keys because we have no way of knowing if they were compromised.

Looking at what information I have available, it doesn't seem like anything was really attacked, but then again, it's almost impossible to know with the heartbleed attack.

Zach Smith will have to regenerate keys for the server just in case they were compromised, but it looks like everything updated correctly and no one was affected. If you were affected, please let me know immediately!

 According to SSL Labs, we currently have an A- rating because of 2 issues I'm still working on improving.

Enjoy using BotQueue knowing it's secure!

Monday, January 20, 2014

BotQueue for Windows

A long standing issue is that BotQueue's client bumblebee doesn't work on Windows. I'm going to try to fix that with this blog post.

I started by looking at Portable Python version 2.7. Note, that I'm installing this all on an 8GB flash drive. There's two reasons for this. The first is that I want to test this with multiple computers, and the second is that I don't have admin privileges on any of them. Go ahead and run the installer, it takes a while.

Next thing to download is easy_install so I downloaded onto my flash drive and ran it using the python I had just installed:
It might tell you to run a different command. I ended up having to run:
python.exe -U setuptools 
Next, add the "Scripts" directory under your App folder to your PATH variable.  For me, this was at "E:\Portable Python\App\Scripts". You should also add the App directory so python can be found anywhere. You know it worked if you can run "easy_install" in the prompt and it not completely fail.

Next, install pip and virtualenv:
easy_install pip
Now that pip is installed, open up a command prompt. Run this:
pip install Pygments pyserial requests requests-oauth
pip install pyserial --upgrade
Next, we need to install curses for windows. Go here, and download the win32 2.7 one. I ran this to install curses:
easy_install curses-2.2.win32-py2.7.exe
Now run botqueue's bumblebee client! You'll have to run my version here, instead of the official botqueue (until that branch is merged, so if the branch doesn't exist, it's probably merged in). Any bugs you find, feel free to report them on github on the official issues page, or in the google groups.

There are some issues when you move from one computer to another, so I put the curses exe, and an egg (for pycharm debugging) in the root of the flash drive. Then, I created a batch file that was just these contents:
"%~dp0\Portable Python\App\python.exe" -U setuptools
"%~dp0\Portable Python\App\Scripts\easy_install.exe" pip
"%~dp0\Portable Python\App\Scripts\pip.exe" install virtualenv Pygments pyserial requests requests-oauth --upgrade
"%~dp0\Portable Python\App\Scripts\easy_install.exe" curses-2.2.win32-py2.7.exe
"%~dp0\Portable Python\App\Scripts\easy_install.exe" pycharm-debug.egg

That fixed any issues I had when moving to another computer. The last line is optional and only needed if you're using pycharm's debugging like I am. I will probably do another blog post on how to set up that, because it was definitely interesting to do.

EDIT: Also, not all bugs have been fixed and pushed to the 0.5X-dev branch. I'll update this again when it's ready.

Tuesday, January 7, 2014

A day with Google Chromecast

Today I decided to buy a Google Chromecast. This nice little device plugs into the HDMI port of your TV, and gets its power from either the USB port of your TV (Warning, plugging it into the service port might be dangerous for reasons unknown to me) or from a little wall adapter.


Setup was a little difficult at first, but most things are difficult when you swap two digits in your password. When you first load the device up, it will tell you to go to a URL. I went there on my Galaxy S3, and was greeted with an app link. Once I downloaded the app, it discovered a device was on the network I was on. How did it do this? I'm not actually sure. It didn't know any of the networks authentication at this point, so I'm guessing there's something low level with mac addresses that allows that to work.

After clicking on the device, it puts a code on the TV and one on your device just to make sure you're talking to the right device. It will then ask you what network you want to connect to, and it's credentials. After entering those, you're all set up to go. It was actually fairly easy.

My favorite part of setup was that the android app switched my wifi network from my home wifi to the chromecast acting as an access point for setup until it itself could connect to the home network.


Operating the device could hardly be more intuitive. Clicking the icon on any supported app allows you to transfer the content to that device. I watched a few netflix shows, and it worked well. My only complaint, which is probably more or less unavoidable, is that there is a good lag between doing something like changing volume, or pressing pause and the chromecast actually responding to your request.

Something else that I disliked was how content wouldn't always save its position. If I want to pause a youtube video, switch to streaming a tab, and then go back to the youtube video, the video had to start over. Obviously that's just an issue with the youtube app not saving the position.

How It Works

So how does this magical device work? Well, there's two parts to this: a sender and receiver. The receiver is literally just a webpage with some javascript to handle the API. The sender is the app that handles the content for the receiver. So, if your receiver has a place for a video, your sender tells it what video to play. Fairly easy and intuitive to actually run with. The sender just tells the device its app id, and the chromecast loads your receiver.


Currently, development is very limited. They are in the beta stages of development, and you can't develop for a device unless it's been whitelisted. I'm still waiting on my device to be whitelisted for development.


One security concern I have is that any device on the network can access your chromecast if they want to. I would love it if the chromecast had a password to be able to access it, but would then whitelist those devices' mac address or some uuid for the device. Either way, I'd like it to be a little more secure on public networks.


Overall, I like the device. Should you go out right now and buy one? Probably. I feel like this technology should be worth more than $35, and the price might go up once people get their hands on the official SDK.