Sunday, March 6, 2016

RGB LEDs/LED Matrix projects

I've decided to take some time to pursue a lot more visual projects, including playing with RGB LEDs and LED matrices. I won't disclose what project this is for at the moment, but here are some demos. Links to github in the video descriptions:


RGB LED color and frequency:


LED Matrix Piano Scroll



LED Matrix of Flowey's Face from Undertale.

Bonus: Megalovania practice at Percussion Ensemble



Sunday, January 3, 2016

Unity Project Sprint 1 review

Over the break I began to pick up working with Unity again.
I had played around a little with it in May, but it took a while for the architecture to sink in.
Now largely avoiding the mistakes I made from my first attempt, I've applied the agile methodology to my work in order to a small and concise sprint jammed full of tasks to complete over the break. Here is the summary of everything I accomplished:

Sprint I:

  • Get working spritesheet for player standing/running
    • Find sheet.
    • Make Unity friendly.
~Player sprite transparency
  • Working character script for player standing/running
    • Create animations from spritesheet.
    • Create organized animation controller.
    • Write C# control script.
~Duplicate Inputs still problematic
  • VR mission tileset
    • Find sheet.
    • Make Unity friendly.
~Moved to Tiled, but these resources can be generated from the GameObject tileset!
  • VR mission scene
    • Make prefabs of all tiles.
    • Investigate combinations of tiles.
    • Create static map scene from
~Artifacts from Tiled2Unity sometimes.
  • Camera Controls
    • Following Camera.
    • Camera Zoom in/out
    • Camera Slide
~Camera Pans are instant, not smooth.


For now, most of that can be summarized in this image. Eventually I will get some video capture for my youtube channel.

Currently the player character correctly idles and moves, and forms appropriate collisions with the training level, created in Tiled. In addition, the camera follows the player, but can be zoomed in and out, also panned in each direction.

In red you can see some of the issues I ran into in each of the tasks. They have been applied to a backlog and polished later, but the priority for now is to continue to add new content until the project resembles a full game.

I'm returning to work shortly so I'll likely save the next sprint for whenever I'm feeling motivated and have more time. It's been a blast working with it so far though!







*These assets were taken from Metal Gear Solid: Ghost Babel, a Game Boy Color title, for lack of any assets of my own. Full credit to Konami and that team for the sprites.

Thursday, December 24, 2015

Steam Link first impressions

My girlfriend made the bold decision of getting me what's currently considered a bit of a "controversial" device-- the Steam Link. While I had more or less directly asked for one, or at least hinted at it with my Amazon wish list in the weeks prior, I'd be lying if I said I wasn't a little nervous about the prospect, especially after watching Super Bunnyhop's very thorough review.



Thankfully though, upon initial setup I'm happy to report that I didn't experience any of the potential hurdles. As a seasoned technologist (or whatever you would call me), I'm very wary of the term "Plug'n'play", knowing fully that anything can go wrong. This was evidenced by the fact that I laughed aloud at the idea of the steam link's "quick start" manual that is literally two images of how everything connects, and a link to link.steampowered.com. Keep in mind that I've never once used "Big Picture Mode", or streamed from any device onto another. Surprisingly though, despite my expectations, within 10 minutes, I was easily playing Metal Gear Rising on my downstairs TV with no lag to report of... What is this wizardry?

It's possible that I faced little impedance because I had the tools for the job-- the recommend wired Xbox 360 controller and a handy wireless touch keyboard that I keep around for my Raspberry Pi projects. I'd particularly recommend scoring a wireless touch keyboard because it allows you to have a mouse and keyboard for interfacing at the cost of only a single USB port. Though I must say, for my experience of playing Rising, Rogue Legacy and then buying two games on sale, I only used it to move my mouse icon out of the way from the screen on Rising (an in-game problem, no fault on the device), and to more conveniently enter my credit card information.

Bunnyhop's review gave me the impression that knowing what games were "out of the box" compatible with the Steam Link would be a gamble each time. However, I can thankfully report that's not the case. The UI has this great system for every game you select that shows the controller type and then a check or arrow depending on whether the game is installed. Most importantly, the UI will only display the controller icon if the game can play with the controller natively, i.e. no configuration needed. For example, Rising and Rogue Legacy show the controller icon, whereas a game that can be configured with a controller just shows a keyboard by default. Some may not care for this non-inclusiveness, but after busting my skull trying to get controllers working for games that brag some kind of controller support (Dead Rising 2), it's nice to know that you're entering at your own risk. In fact, I wish my PC version of steam did this by default!

That being said I've not yet to experiment playing with games that require any configuration, or play with any emulators. I will report back with those inevitable frustrations.

Even when purchasing games via the Link, it was kind enough to inform me that I was purchasing a game that was intended for keyboard and mouse. I feel like this information was contained in Bunnyhop's great review, but it's really something you may not notice until you experience it for yourself-- and it made a big difference for me.

When interfacing menus with the controller, there's a surprising amount of easy to access features, whether you're just navigating within your library/store or from in-game. Particularly appealing to me is the dichotomy of "My Game" for each title, which contains all of the personal stuff, like screenshots, and then below that all of the other community resources. I've not tried chatting or web browsing, but the option is there!

Now, regarding graphic quality. I'm really glad I chose to play Rising first, as I can't think of a game in my library that would be more of a struggle to stream onto a downstairs TV than this one. However, I was immediately impressed by the quality. Much like how the pre-rendered cutscenes in Rising look like real gameplay (in my humble opinion), so does the stream on your TV match the real thing! I think we all know what the artifacts of streaming look and feel like, and while I'm fairly naive in the streaming circuit, I definitely feel like you could fool me with this one! That's so far, but I definitely feel like Rising and Rogue Legacy were good litmus tests for being such different games. I'll continue to update with my findings and frustrations, but for now I'm very satisfied and would highly recommend the steam link to anyone that wants to share some of their PC love downstairs on the couch.


Sunday, December 20, 2015

Developing Neural Network architectures

I've been putting a lot of my outside efforts into studying neural networks. After following along with David Miller's great vimeo tutorial to produce my first neural network in C++, I've began reading primers not only on how neural networks are constructed, and what types of neural networks best fit certain problems. I've been through a few resources, but my best recommendation would be Neural Network Design by Martin Hagan et al. I recommend following along with the book slowly and digest each new piece of information slowly, and, instead of looking at the available files, create your own working examples. You'll see on my github that I've done just that, using Octave. It was my initial intention to follow along in Racket/LISP, but it quickly became a detriment trying to force lists of lists to behave like matrices, especially for the finer things like transposing matrices. I know there's an available library, but it falls back on "arrays", and it all just feels very un-lisp-like! Eventually I will meet this goal. However, for now, check out my github for updates on the ANN stuff I've developing. I'll try to get some solid documentation available so you can just clone and go.

Saturday, December 12, 2015

CSS Parser v0.1

This morning, after putting in some extra hours I got the first iteration of my CSS parser working. Originally I had made seven example selectors that manually placed into my cssSheet API to test out how my "trees of selectors" would work out.  After thoroughly debugging these methods, I went ahead and spent some hours on how the parser's actions behaves. Originally I thought I was in hot water because I would only be passing around one selector, but thanks to the way the grammar behaves, it actually worked, and parsed a test css sheet that contained these same examples! It was very exciting.

Also the fact that this worked with multiple selectors floating around within the grammar gives me hope for implementing things like the wildcard selector and giving multiple selectors the same set of properties in one declaration. Honestly, because ANTLR and grammars are so powerful, these things could possibly work already-- but that's providing my code plays nice. Anyways, the next step will be implementing the parser into the engine, and then I imagine I'll be maintaining it both through our enhancement and in the future. But I don't mind. I think ANTLR is cool, and I like working with it. I really felt the pressure from the deadlines I've been working under, but I'd like to make parsers a regular part of my programming diet. There's this magical moment where you're mentally considering only so many cases, and your completed parser readily handles so many more. It makes you want to attribute some intelligence to the design that isn't there at all-- it's just a beautiful structure.

Sorry for being sappy.

Adding Actions To Your ANTLR Grammar

We established last time that getting antlr to generate code is a huge pain. Even worse, is the fact that it's hard to find good examples of the antlr workflow, i.e. generating code with actions, adding arguments, and etc. Thankfully, in my quest to build a CSS parser in C++, I've managed to track down two invaluable Stack Overflow posts that proved invaluable.
The first is a simple ANTLR3 example. I found this to be a very helpful workflow example for antlr3. While it's aimed towards a Java target, it should be very simple to translate the code actions to any other language. While working on this example I also highly recommend learning what ANTLRWorks has to offer, especially the syntax diagrams and built-in interpreter. These tools should help you better understand your grammar, including what it can handle and what it can't. It's also not a bad idea to follow along in a debugger when running the parsing routine to get a hold of how the grammar actions behave. If you find any tweaks that need to be made, just remember to apply them to the grammar, or they will be wiped away if you ever generate your parser again.

By the end of that example you should have built it all; a Exp parser and lexer from ANTLR3, and added target code to the grammar that works. At this point you should be ready to work with a larger and more sophisticated grammar. However, you may find using the limited rules in the Exp example that you can't accomplish everything you'd like with only returns. Thankfully this other post shows how to pass in arguments.

There are a couple of other things to consider as you fiddle with your grammar. Code actions must go under a rule. Also, don't expect ANTLRworks to know what the hell your code is supposed to. Its job is to understand your grammar. This is both a blessing and a curse. It's a blessing in that you don't really have to show ANTLR the classes and structs you're working with, but at the same time, you can sabotage yourself and write some funked up code-- but your IDE will let you know.


Friday, December 4, 2015

Arduino or Raspberry Pi?

In 2016 I will be instructing some courses at the Kre8now Makerspace in Lexington, introducing people to the Arduino and Raspberry Pi microcontrollers. While I would certainly recommend taking both courses for the full picture, the reality is that you have a project in mind, and would like to decide whether to realize it with the Arduino, or with the Raspberry Pi. The problem is, how do you know which one to use without experience with both?

A lot of different online resources seem to have different measures to help you choose which one to use. Make Magazine, for example endeavors to number the amount of tasks for the project, and if

I personally think that a lot of the measures are bit far-fetched, so the natural thing to do is to add my own far-fetched measures of which board to use. And here's the first:


1) Consider your ports.

Now if you don't have much computer/AV know-how, that may have been a confusing bit of advice, but what I mean to is to carefully consider the inputs and outputs of each board-- they tell you a surprisingly amount about its capabilities and the simplicity in carrying out those capabilities. To make this more apparent, let's consider the ports on both devices:



Raspberry-Pi
  • HDMI output
  • direct 1/4 inch audio jack
  • ~4 USB ports
  • Camera port/display port
  • Ethernet port
  • micro-SD slot
  • ~40 GPIO pins


Arduino
  • ~10 digital I/O pins
  • ~5 Analog input pins









Right now this may sound like a commercial for the Raspberry-Pi, but I assure you it's not!

Sure, the Raspberry Pi has more options, but that's because it's a full-fledged computing system and needs these services! The Raspberry pi runs a version of Linux which is very similar to any desktop/laptop version-- you can install the same programs and more from the same set of commands.

So why not just choose the Raspberry Pi for every project? Well, for applications that are primary electrical and autonomous (self-controlled) I'd choose the Arduino nearly every time, because it is far more idiot-proof when it comes to electricity, and far more flexible. Without going into too much detail, the Arduino is far more foolproof to higher voltages, whereas if you give the RPi anything beyond it's recommend 5v... expect your RPi project to be placed on hold.  Also, the Arduino very simply handles analog input/output, whereas you must "trick" the Raspberry-Pi into doing analog signals, by either simulating them or buying additional equipment. Even when working on Raspberry Pi I often "sketch out" my designs in the Arduino because it's so easy to work with!



My second and last comparison would be this:

2) Appliance vs. Computer System

When I say appliance, you probably have some clear pictures in your mind: A toaster, a refrigerator, and even smaller appliances like a blow dryer, a cat feeder,  or an alarm clock. Whereas with computing systems, more complicated systems should come to mind: video game consoles, robotic systems, and anything with the prefix "smart". From what I've already described you should be able to see more clearly why the two boards paint these distinctions. The Pi allows for easier networking, processing and display, whereas the Arduino is a simple wizard of electricity.

As a last measure of helping you decide, here's a pool of 5 projects each that best suit one board over the other, along with some helpful links!

Arduino:
Guitar Pedal, Small and simple autonomous robot, door-lock system, Plant waterer, motion alarm

Raspberry-Pi:
Media Center, Retro game emulator, Multi-core cluster, security camera,
internet radio

However, if you're dead-set on accomplishing a project with a board in mind, I encourage you to do so! There's truly only a few impossibilities that prevent you from crossing the streams, and often times doing so leads to new discoveries for you about your project and your board. Give it a try!

If you're interested in finding out more about Arduino and Raspberry-Pi projects, I recommend checking out instructables, and the two boards' subreddits. It also doesn't hurt to check out selections at shop sites to see what they offer. Adafruit in particular often has tutorials for both boards.