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/first_boot.sh 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 ez_setup.py onto my flash drive and ran it using the python I had just installed:
python.exe ez_setup.py
It might tell you to run a different command. I ended up having to run:
python.exe ez_setup.py -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" ez_setup.py -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.

Tuesday, February 12, 2013

Forcing Serial device to use the same Serial port

EDIT: Note, that this caused an error that I'm currently trying to work out. I'll remove this once I've figured it out. Basically, it doesn't treat the second device as a serial port.

Note, that I'm currently writing this to use on my Raspberry Pi to make it work better with BotQueue's client software, bumblebee. When you unplug a usb serial device, and plug it back in, the serial port changes.  So, if you have it as /dev/ttyACM0, unplug it and plug it back in, you'll see it's now at /dev/ttyACM1.

Throughout this tutorial, I'm going to use /dev/ttyACM0 since that's the current port of the device I'm trying to get to stay.  Note, that this is a device rename, not a symlink. I'll be using /dev/ttyJasmine for the new port since Jasmine is the name of my printer.

First up, let's find some info about the device:
udevadm info -q property -p $(udevadm info -q path -n /dev/ttyACM0)
It should spit out some info. The line that we need to pay attention to is ID_SERIAL_SHORT.

So in the case of my arduino, (excluding all irrelevant fields):
ID_SERIAL_SHORT=<removed for the blog post>
Now it's time to set up what's called a udev rule.  Run the following command, replacing nano with your editor of choice: (Note, that I chose 45 arbitrarily. Just for fun, you might want to research how the numbering system works)
sudo nano /etc/udev/rules.d/45-serial-devices.rules
Go ahead, and add the following line, replacing the items in < > their appropriate values.  So in my case, I'd replace <SUBSYSTEM> with tty and <ID_SERIAL_SHORT> with the serial device I found earlier. (Note, that this is all one line)
SUBSYSTEMS=="usb", ATTR{serial}=="<ID_SERIAL_SHORT>", NAME="ttyJasmine", GROUP="dialout", MODE="777"
Go ahead and save the file. After a fresh reboot, you should see your device have the name that you assigned to it.  If not, then run the following command to see what the problem might be:
cat /var/log/daemon.log | grep udev
Remember to change your config.json to use the new port if you did this for botqueue.