Catching up

Wow, I haven't posted in a long time. Shortly after my last post I had the flu for a week, then I had a job opportunity come up and I spent half a week flying around for interviews. For two weeks after that I was writing docs and doing more research for OVC and I forgot to blog...

So I have some docs up for OVC now explaining how the code works (. I also added to the readme and made additional comments in the code. Hopefully my additions will help the next team that can pick up OVC.

This week and next I hope to add some unit tests to OVC. I'd like to be able to test to make sure the gstreamer interface is working correctly and that the network connection is working. First thing I need to do is figure out how to launch a sugar activity through a unit testing environment. From there it should be easy enough to mock another activity and have it send fake connections.

Update:

I had a conversation with Cerlyn from OLPC about unit testing. It seems like this will be more difficult than I thought...

<trose> can anyone point me to a good reference or example for unit testing sugar activities? specifically testing video and network interfaces?
<Cerlyn> trose: As far as Sugar goes, there is no activity specific testing framework I am aware of; I've been begging for one to be made.
<Cerlyn> Sascha Silbe has been working on unit tests for the core Sugar environment on occasion, but as far as I know progress on that front has been going slow
<trose> I'd like for just some way to start up an activity and then send it fake signals like another activity is trying to connect. Then I could make sure the activity responds correctly
<Cerlyn> many tests Silbe's been working on require user involvement to report pass/fail as well :/
<trose> Cerlyn, well that is frustrating...
<trose> how exactly does sugar start up an activity? is there a way to emulate that?
<trose> or is there a way to say like sugar.startActivity() and get a pointer back?
<Cerlyn> You can start an activity within sugar by running "sugar-launch {fully qualified name of activity here; like org.person.trose.myActivity}"
<trose> Cerlyn, okay
<Cerlyn> That probably wraps a DBUS interface to do it
<trose> but that's cmd right? can i get a handle to inspect the activity?
<Cerlyn> Historically having one activity directly launch another is something that hasn't been done; I do not recall the reasons offhand (not a developer; rather QA)
<trose> Cerlyn, hmm
<trose> i could see how that would cause problems
<trose> this would be a training script though
<trose> *testing
<Cerlyn> trose: In theory, being GTK3 based, GTK-supporting test frameworks should work
<Cerlyn> but graphical testing is obviously not unit level

So there isn't a good way to start up a sugar activity and maintain a handle on it. I may be able to hack around this somehow though. Stay tuned...

Measure Twice Cut Once

More research today. I've been mucking around with some of Collabora's code. They are releasing Farstream on Fedora 17 soon. I also found out that there will be a version of Sugar on F17 released in July. Farstream comes with python bindings by default and supports a lot of useful things by default including, RTP and ICE. ICE will be useful as it allows the program to navigate around firewalls and NATs. This should be a valid approach so long as I can get a hold of the development build of Sugar. I don't think I'll have any problems with that though.

If that isn't possible I should be able to continue with current Sugar builds by using telepathy-farsight. This should be very similar to farstream except I'll need to manually pull in the ICE library and perhaps a few other things.

Overall I feel like I'm getting a firm grasp of what needs to happen to get everything working properly. Next week I'm going to start hacking on the OVC code to figure out how I can integrate these new libraries.

OVC Research

I dove into the pyGst docs today to try and wrap my head around what exactly is going on. I found the docs to be really confusing at first. Luckily there was an accompanying tutorial that explained things very nicely.

Unfortunately, the tutorial only outlined how to do local streaming. I searched around a little more and discovered that OLPC has a page about gstreamer on the XO's specifically. This page has a lot of information on it. According to that, I need to use a udpsink with an IP to send video to another XO.

At this point I started picking through the code to figure out where the problems might be. I know that somewhere along the way the connection isn't being set up correctly. Either the XO's are failing to get each other's IP's or the video connection isn't establishing.

The part of the code in tube_speak.py that deals with IP's is as such:

@signal(dbus_interface=IFACE, signature='s')
def announce_ip(self, ip):
    self.ip = ip

def announce_ip_cb(self, ip, sender=None):
    if sender != self.tube.get_unique_name():
        self.cb('ip', ip)

This is most likely where the problem is occurring. Basically, the XO's are just spitting out their IP and hoping the other one gets it. If this is the root of the problem, I should be able to solve it with a home spun TCP-like interface where it listens for a return signal.

The other part of the code I've been looking at is here in gst_stack.py:

        # Add udpsink
        udp_sink = gst.element_factory_make("udpsink")
        udp_sink.set_property("host", ip)
        self._out_pipeline.add(udp_sink)
        video_enc.link(udp_sink)

It may be the case that I need to find an alternative to udpsink. Maybe there is something like rtpsink? I'm not sure at this point. Next I think I will start picking at the code to try and determine exactly where it's failing to make the connection.

Migrating OVC

Well I haven't talked about Open Video Chat lately. The project has been pretty stagnant for a while. I'm picking it up again this quarter as part of an independent study. Expect weekly updates about the project.

The first order of business is to migrate the project to github. Fedora Hosted was nice but it simply doesn't compare to github for community involvement and collaboration tools. The new repo can be found here: https://github.com/OpenVideoChat/Open-Video-chat.

This quarter I would like to get OVC working with RTP. The current system uses UDP steaming 100% of the time. This means that more often than not the connection packets are dropped since the XO's have horrible connection reliability. RTP fixes this by using a hybrid of TCP and UDP. It uses TCP to ensure the connection is made, then UDP for fast media streaming.

After I complete the RTP conversion I want to focus on getting some more documentation and unit tests for OVC. Right now there is absolutely nothing. When I graduate in May there will no longer be any of the original collaborators at RIT. Providing docs and unit tests will make it easier for other students to pick this up when I'm gone.

pyBotWar: State of the Code

Tomorrow we are moving into the final hackfest for this class. Before the hackfest I want to outline what we've gotten done so far and what I think we can get done before the project is due.

What We Have

• Working back end code pushing to a memcache
• Working client reading memcache and properly drawing all elements of the game.
• Updated graphics for all the bots

What We Need to Have

• Facebook authentication
• User uploaded bots
• Restricted python
• Starting a game with friends' bots 

Would be Nice

• Better selection of starting bots
• Different weapons/ body types
• Multiple arenas
• Game playback
• Communication protocol
• hacking other bots (mwuhahaha)

At this point I feel comfortable saying we will have a finished, polished product. The remaining necessary features are fairly low hanging fruit. Given the amount of time we are planning on spending  hacking tomorrow I don't think we'll have any problems getting this done.
That means we get to spend most of the hackfest adding cool new features. I'm really excited to implement some new weapons and bodies. Also, I love the idea of hacking other bots through a communication protocol. You could have a bot that could just sit still and use all of it's processor power cracking the encryption of the other bots and telling them to attack each other.

PyBotWar

For the Open Source game design class we're going to try and make an online multiplayer version of the classic RoboCode game. We found a python port on google code http://code.google.com/p/pybotwar/ that we hope to put up on open shift. Robo Code is a game where you actually program a robot that fights other robots in an arena. The robots rely solely on the code you right as you cannot control them once the match starts. Our goals for the project are as follows:

Required:

• Refactor the graphics stack to support a javascript client. Adding json communication between the server and client.
• Upgrade existing sprites and graphics assets
• Prevent users from calling dangerous python packages in their robots
• Facebook authentication

Optional:

• Add new arenas beyond the basic square one
• Add additional weapon
• Add different sensors

Pie in the Sky:

• Communication protocol for teams of robots
• Ability to hack opposing robot's using communication protocol
• stack overflow, false commands, etc.
• RPG elements including leveling up and earning new weapons or stats

At the moment we're still focusing on reverse engineering the graphics stack. We'll then implement a function that exposes the current state of the world using json. From there we simply need to write javascript to draw the game state.

Once our core goals are complete, we'll hopefully have time to focus on adding fun things like new weapons and body types. These would add value to the game play without requiring much time. If we get to this stage of development we should be able to produce several new options.

AJAXING It up!

I learned about ajax this week in class. I knew about it in the past but I haven't had much experience implementing it. Seems like a really good way to send and receive data quickly.

The basics of AJAX is that you create a function that will serve json whenever it is called. This function is tied into a URL that can be called with optional parameters. Then you can have another program, be it a web client or desktop software send a request to this URL. The program then receives back json formatted information it can use.

I will be using AJAX to implement my final project for class. I'll be able to run the python pyBotWar program on a server with a modified AJAX function that sends out the state of the game. The client can then ping this function periodically to get information about robot position, angle, health, etc. and draw the state.

Hola Mundo Turbo Gears

Today in the open source game design class we boot strapped for Turbo Gears. This, combined with open shift will allow us to quickly get web apps online and running.

Open shift works by tying it to a Git repository on your computer. When you push the repo to open shift it automatically turns off the Turbo Gears instance running on the cloud, applies the changes you've pushed, and then restarts the server.

This is incredibly useful for small applications when you don't want to spend a lot of time trying to set up your own server. Updating the server is as simple as git commit && git push openshift.

We'll be using this system to launch our app for the final project.