MURVV - Android Robot Controller

Mike B

Sept 25, 2012 - Multi-User Controls - The Sequel

So I've done some more research into this "networking" problem. By now I've established a clear understanding of what doesn't work. Specifically, Android does not have any clear ways of terminating a program, so I can't run my queue the way I wanted to. Instead of simply sending an "I'm done using the Android Controller." signal, I have to send a very long series of:

Server: "Are you still using the Android Controller?" Client: "Yes." Server: "Are you still using the Android Controller?" Client: "Yes." Server: "Are you still using the Android Controller?" Client: "Yes."

And when the client is finally done, the signals will look more like this:

Server: "Are you still using the Android Controller?" Client: "..." Server: "Are you still using the Android Controller?" Client: "..." Server: "Why aren't you talking to me?" Client: "..." Server: "Is it something I said?" Client: "..." Server: "Because if it's something I said, I'm sorry! I didn't meant it!" Client: "..." Server: "Hello?" Client: "..." Server: "*Beep* Advancing queue to next available user. *Beep*" NewClient: "Hey! I want to use the Android Controller." Server: "OK, great! Here you go! You're like, soooo much better than the last guy. By the way, are you still using the Android Controller?"

In simpler terms, my current networking protocol acts like a flaky, overly-dramatic teenage girl. This is why I don't like networking problems. The answer always seems so incredibly inefficient. But this seems like the only feasible way of ensuring two main points: First, that the server recognizes when the client is connected, and second, that the server recognizes when the client has left, regardless of exactly *HOW* he left. (Whether it was by voluntary termination or otherwise.)

Summary

My original networking protocol didn't work properly and I had to resort to using something much more inefficient and annoying.

Mike B

Sept 24, 2012 - Multi-User Controls

Now that the Android Controller works the way we want it to, I'm going to write a queueing program for it. This will allow multiple users to login to the robot without interfering with each other.

I've taken a bunch of notes about the idea, but I think this will end up being almost entirely a "networking" problem. Ah, good old networking problems... I hate them almost as much as that casserole stain in the back of my fridge. You can't ignore it and you can't clean it up properly; the best you can do is try and "deal with it" in the most efficient way possible. In my fridge, I decided to cover up the stain with a jar of mayonnaise. But I can't cover up the networking problems in the Android Controller with a jar of mayonnaise so instead I'm going to use a series of handshakes and periodic acknowledgements to maintain a queue. I plan on working out the finer details tomorrow. And by then, I'll let you know exactly what's going on.

Summary

Now that the Android Controller works the way we want it to, I'm going to write a queueing program for it.

Mike B

Sept 13, 2012 - Completed! (Well, pretty much anyway...)

One day over a week and it's finally done. Well, not completely, there's always more things I could do to improve it, but like everyone else who's ever written software before, you know there comes a point when you just say it's finished, even if it's not really done.

Bright and early in the morning today I moved the robot around in a circle and drove it up and down the hallway. That was pretty cool. When you spend a long time on something it's nice to see it all come together the way you wanted it to. And it's even better when things start to move along as quickly as they did. It seems like only yesterday I was first getting it to move... Well, maybe that's because it was yesterday. It's all a learning process, I know that, and the more you learn the easy things become, but I have to admit, as a first time user of these phidget things, the learning curve isn't very steep. Admittedly, there's a bit of a jump between when you first start and when you actually connect to the devices and get them to do anything, but it is surprisingly easy to make progress after that. And if we improve the Android section of the wiki and fix all the problems I ran into, it should be a reasonably simple task to get started.

Summary

It took me a little over a week of work, but the project is essentially done. If you're sceptical about using phidgets for a project you're working on because you think they'll be too hard to learn, don't be. As the new intern at the company and a first time user, I found it surprisingly easy to learn.

UPDATE

I can't believe I forgot about this, but I haven't implemented the camera controls yet. That's something I definitely need to do to wrap this project up, as it's fairly important to be able to control the camera as well as the actual robot.

Mike B

Sept 12, 2012 - First Movement

So it's been one full week since I started on this project and today was the first day I actually got the robot to do anything. It was quite the experience when I booted up the app this morning and pressed forward to see the robot slowly crash into the table down the hall. It was an equally satisfying and terrifying thing to watch through the webcam. Half of me was thinking “Uh oh... Stop it! It's going to crash you lunatic!” and the other half was thinking “Hahaha! It's alive! It's aliiiiive!” Well anyway, it did manage to stop before it broke anything...

The Android Robot Controller interface

It still needs a little more work, but I've got enough done that I can actually move the robot around now and that's a pretty good feeling. However, I still don't really know anything about the software that's running on that strange metal box. At the current moment, we have to start up some software on the robot itself before we can connect to it. Ideally, it would be nice to be able to start the thing thing up at the same time as the android app. That way we wouldn't have to worry about whether or not the robot is actually on. Both things would boot up concurrently and it would make it a lot easier to deal with. But is that too hard? too impractical? even possible? I don't know.

In the end. I guess what I really want to do with this thing is make it really easy to use. Right now, they've got some kind of joystick strapped to a piece of 2x4 and you have to connect to a bizarre computer interface that doesn't even seem to work on my computer. Is it because I'm using Linux and they're using Windows? Maybe... Or is it because I just have absolutely no clue how that program works? That seems more likely.

Now, with the android app I've almost completed, you'll just be able to start up the app and see everything from the get go. The webcam view will be right there in front of you and the controls will be so easy to use you won't even have to think about. And that's the objective, right? If you have to take time to learn the controls to anything then the controls are probably more complicated than the need to be. (Though it realize this doesn't really apply to everything. Frankly, I'd be horrified if I found out my pilot was controlling the plane form his phone. Intrigued, sure, but horrified nonetheless.)

Anyway, this is the plan: Four buttons in each corner. In the top corners, there's one for clockwise rotation and one for counterclockwise rotation. Then there's a button in the bottom left corner that switches the controls to the camera (so you can pan/rotate/zoom the camera). The last button, in the bottom right corner shows/hides all the controls, so you can make the interface less cluttered and see more of what you're doing. The webcam feed will take up the entire screen so you can see what you're doing and there will be a little red dot in the center of the screen to make it easier for the user to know where to put his finger.

Summary

The robot actually moved today and I made more detailed plans for the user interface. Simplicity and intuition should both play a large part in the design.

Mike B

Sept 11, 2012 - C# to Java

The last two days were spent translating the existing C# code into Java code. I've never actually written anything in C# before, so it was a bit confusing at first, but the two days I spent on it were enough time to figure out everything I needed to figure out and by the need of the second day I had all of it translated into Java so I could use it in my Android app.

One thing that I discovered today is that this is an excellent way to learn how to use all the different phidgets. When you're translating code like this you get an opportunity to learn a bunch of different things. First, you learn how to use the language that you're translating from, in this case, I learned how to use C#. Second, you learn how to use the language you're translating to. Of course, I already knew a lot about Java, but I can't deny that I learned a little bit more about it from the experience. And lastly, you learn how to interact with the phidgets in both languages. I think this is a lot more useful than learning how to interact with the phidgets in just one language because, although you may gain a greater understanding about that one language, you actually learn how the individual functions work and what exactly they all do.

So I really would encourage some of you to try and do this once or twice. It's definitely a difficult thing to do, but you learn so much that it's well worth the time and the effort. Just make sure you use two different languages that you actually want to learn about. There's no sense in translating from Visual Basic to Java if you hate Visual Basic and you never use Java.

Summary

Translating code from one language to another is a time-consuming, but valuable learning experience.

Mike B

Sept 7, 2012 - Complaints and a Barbecue

Friday! and the last day of my first week here at Phidgets.

I didn't accomplish as much as I would have liked to on the Android app, but I did read a bit more into the Android Developer site and tried to figure out how to do different things with the interface. I got some buttons to do interesting things like show and hide other buttons and I played around with the layouts a bit... But as it turns out, setting up the layouts for all the different kinds of Android devices you might use is really difficult. You inevitably have to write several different cases and use different layouts for all the different screen sizes, something I didn't ever think I would have to deal with. I guess I'm just so used to the formatting tools available for web pages, like css where everything is so easy to change, that I'm having a hard time believing that the layouts are so difficult to set up in Android. Perhaps it's something they need to work on or maybe I just need to learn to get used to it.

On another note, we had a barbecue at work today, which was a nice change from the boring sandwiches I usually pack in my lunch. Lately, I've felt like packing a lunch is something I do more because 'I don't want to die of starvation' and less because 'I actually want to eat what I pack in my lunch'. I don't imagine I'm the only one that feels that way, but it's all the more reason I appreciated the barbecue today. However, I did have to wonder why they seemed to think "out back, between two dumpsters" was the best location to hold this event...

Summary

Android doesn't a very good job when it comes to developing applications for multiple devices and if you want your code to work on everything from tiny phones to big tablets, you have to be willing to write a lot of code. Also, the city of Calgary should really put a park next to my workplace.

Mike B

Sept 6, 2012 - The Wiki

Spent most of the day today trying to get Android to work with Phidgets. It's very frustrating when things simply don't work, but I'm sure each and every one of you know exactly what that's like.

The worst of it was that none of the examples in the wiki were working! The code that the guys in the office wrote just wasn't working no matter what I tried to do. Moreover, some of the code the wiki tells you to download code that doesn't exist! Well, that's obviously something we need to work on and I suppose it's all the more reason we need to be doing more stuff like what I'm doing right now. It shouldn't be a challenge to the examples to work.

All ranting aside, I figured out what the problem was by the end of the day. As it turns out, android doesn't seem to recognize your libraries unless they're in the "libs" folder. That's right, even though the examples have the "phidget21.jar" and "PhidgetsUSB.jar" files in the root of the directory, you have to put them in the "libs" folder instead. Otherwise your app will simply crash as soon as it starts up, which is really frustrating. After I did that, all the examples worked and I even got my own application to recognize the phidgets in the robot.

That's one step forward I guess.

Summary

The Android section of the Phidgets wiki needs some work.

Mike B

Sept 5, 2012 - The first day

So the guys in the office came up with a great idea for the robot they've made. They want to make an Android app for it. We could put this app on a smartphone or a tablet and use that as a controller for the robot. Being the new intern here at Phidgets, I was sent to work on it almost as soon as I walked through the door. I wasn't about to complain. At my last internship, my first assignment was to read hundreds of pages of legal agreements and safety manuals. This was a lot more interesting.

Android - An OS for phones and tablets.

I started the day off getting together all the necessary tools for my endeavour. I've never done any programming for Android before, so I really had no idea where to start. Thankfully, Android makes it relatively easy. They've put together a developer training website, as they seem to call it, with a ton of detailed instructions to help you get started. I'm a staunch Linux fan-boy when it comes to any kind of programming work, so I followed the instructions for getting set up on Linux.

The Android website recommends using Eclipse, a program I learned about, and simultaneously learned to hate, in university. It's not that it's a 'bad' program. Eclipse can be very useful sometimes, but I've just found it to be too bulky and awkward to deal with for most of my projects in the past, so I wasn't entirely enthusiastic about their suggestion. But, as I mentioned before, I really had no idea what I was doing at this point, so I just followed along blindly.

One of the great things about Linux is that most of the well-known programs are notoriously easy to install. I use a distribution of Linux called "Linux Mint" and the process of installing Eclipse was as simple as typing "sudo apt-get install eclipse" into a terminal. Ten minutes later Eclipse was installed and I started up the program and frowned unhappily at the familiar, yet still loathed Eclipse environment that popped up in front of me.

But I continued to follow along regardless and advanced on to the next step, installing the "Android Development Kit". And though I still didn't like Eclipse, I couldn't help but smile at how easy it was to install the ADK. A point and a click later and I was done. Great, next step.

The Android website then asks you to install updates; however, I decided that I didn't want to do that and I just went on to the next step, writing my first app. A couple of hours later, I had a very simple Android application working on both my Android emulator and my Android tablet. I was even beginning to like Eclipse. Eclipse does a wonderful job of showing you exactly what you're going to see on screen when you actually run your app. It also helps you find the right libraries and imports them all automatically. Happy with my progress, I thought it was about time to start working on the real thing.

Eclipse - One of my least favourite programs.

But before I went any further, it was time to update eclipse, the one step I had skipped earlier. And despite all my accomplishments today, this is where all my past eclipse experiences came flooding back to me in a torrent of nightmarish flashbacks. The Android website tells you to update eclipse, so that's what I did... Well, that's what I tried to do anyway. When I clicked on the update button, Eclipse popped up a window that showed me all the packages that needed updating. No problem, right? Just click on all of them and say OK. Well, that's not how it went down. Eclipse said, "No. I don't want to update." and crashed. I frowned and tried it again. And again, it crashed. "OK", I thought, "Let's try updating the packages one at a time instead. I'll just skip over the one that won't update." Well, to my surprise, this actually worked and somehow I got all of the updates installed.

But then everything went wrong again. Somehow the updates destroyed the entire ADK and now I couldn't get any of my android apps to work again. After trying to get everything working again and having no success, I simply reinstalled eclipse and skipped over the update step permanently. I supposed it would just be one of the quirks I would have to deal with.

Summary

For the amateur Android programmer, the introduction is an 'almost' painless process. Android's guide is well written and clear, but even they can't accommodate for the failings of programs they have no control over. So if you're new to Android, but fairly familiar with programming, you shouldn't have too much of a problem getting set up.