import twitter import urllib from getpass import getpass def isitgoingtorain(): answerPage = urllib.urlopen("http://www.goingtorain.com") while answerPage.readline().find("<div id=\"answer\">") is -1: pass tmpLine = answerPage.readline() if tmpLine.find("yes") is not -1: return "yes." elif tmpLine.find("no") is not -1: return "no." else: return "FAILED" def createApp(username, password): twitterSystem = twitter.Api(username, password) return twitterSystem user = raw_input("Enter your username - ") pword = getpass("Enter your password - ") twitterSystem = createApp(user, pword) tmp = isitgoingtorain() if tmp is not "FAILED": print "Posting..." twitterSystem.PostUpdate("APERTURE SCIENCE AUTOMATIC FUTURE RAIN STATUS PREDICTION SCRIPT RESULT: " + tmp) else: print "Failed... could not get rain update."
Showing posts with label python. Show all posts
Showing posts with label python. Show all posts
Wednesday, March 10, 2010
March Madness Entry 10
A common theme, to be sure. I'll leave it at that. But when you throw a dying router into the mix with five laptops on it, and suddenly testing your IRC bot becomes a slow, arduous, and sometimes fruitless task. Tonight's code? A rehash of last nights with an added twist.
Tuesday, March 9, 2010
March Madness Entry 9
With an ever shrinking budget of time, a slew of stomach cramps, several sub 5 hour slumber nights, a new project at work, and the ever present long meeting for FUBAR's future tonight, I knew I had to make it short. At least I kept it useful.
Ladies and gentlemen, the daily morning Python script (in function form for future porting to other applications) - Is it going to rain? Powered by Going To Rain?.
Very simple. Use urllib (1, not 2. Yes, there is a difference, it isn't just versioning differences...) to grab a url as a page we can step through, and look until we find a segment of HTML where I know the answer is stored. Once I find that marker, I know the answer is on the very next line, so just check to see if it says "yes".
Ladies and gentlemen, the daily morning Python script (in function form for future porting to other applications) - Is it going to rain? Powered by Going To Rain?.
Very simple. Use urllib (1, not 2. Yes, there is a difference, it isn't just versioning differences...) to grab a url as a page we can step through, and look until we find a segment of HTML where I know the answer is stored. Once I find that marker, I know the answer is on the very next line, so just check to see if it says "yes".
def isitgoingtorain(): answerPage = urllib.urlopen("http://www.goingtorain.com") tmpLine = "" while answerPage.readline().find("<div id=\"answer\">") is -1: pass if answerPage.readline().find("yes") is not -1: return "yes." else: return "no."
Monday, March 8, 2010
March Madness Entry 8
As exhaustion sets in from spreading myself a bit thin, I offer up this morsel of python programming to pass yet another day in the challenge. Some of you may notice that yesterday's is missing - the code is done, but the video required for such a project is late coming for various reasons. When I get video and can offer up the code, I will post it.
For now? A touch of getopts.
For now? A touch of getopts.
Saturday, March 6, 2010
March Madness - Entry 6
Couldn't finish the IRC bot (with responses) so I did a Project Euler problem to fill the time. Hmph!
Really simple. The result? 25,164,150.
The sum of the squares of the first ten natural numbers is,
12 + 22 + ... + 102 = 385
The square of the sum of the first ten natural numbers is,
(1 + 2 + ... + 10)2 = 552 = 3025
Hence the difference between the sum of the squares of the first ten natural numbers and the square of the sum is 3025385 = 2640.
Find the difference between the sum of the squares of the first one hundred natural numbers and the square of the sum.
values = range(1, 100 + 1, 1) sumSquares = 0 for i in range(0, 100, 1): sumSquares += values[i]**2 squareSums = sum(values)**2 print squareSums - sumSquares
Really simple. The result? 25,164,150.
Friday, March 5, 2010
IRC Bot Template - March Madness Entry 5
For the upcoming Python study group for FUBAR, I decided to focus the group onto a sole project or Python module that we can all learn together, and then work on to expand in different directions with our own creativity. To try out this new model of handling the study group, I decided to have the group create their own respective IRC bot. Together we would figure out how to get them online, parse data, and talk back in the chat. After that, we can have each member implement their own cool bot features - the options really are limitless.
Thursday, March 4, 2010
March Madness Entry 4
A little shy on time today, with a combination of a suddenly changing work schedule due to unforseen circumstances and an unusual bout of exhaustion and nap taking. The result? A project Euler problem to fill the time!
A palindromic number reads the same both ways. The largest palindrome made from the product of two 2-digit numbers is 9009 = 91 x 99.
Find the largest palindrome made from the product of two 3-digit numbers.
Tuesday, March 2, 2010
March Madness Entry 2
A bit squeezed on time between work and FUBAR Lab's social and administrative meeting, I decided to do something simple tonight - Project Euler! Some of those problems can get ridiculous, so I chose one I happened to know the answer that I've solved in the past, but didn't have the code laying around.
Note - if you want to solve project Euler yourself, don't cheat and peek at the rest of the post. Take this as a warning - the answer is at the end.
Note - if you want to solve project Euler yourself, don't cheat and peek at the rest of the post. Take this as a warning - the answer is at the end.
Thursday, November 12, 2009
From the lessons of peers
FUBARLabs has twice a month a Python study group, where we teach other various tricks of the trade in Python and cover many of the all-too-cool Python modules out there. All skill levels are welcome, but those of us that regularly attend tend to be regular code monkeys. Here's some of the things we've covered (so you don't think I've been lazy - ha!):
Tuesday, September 29, 2009
On PAC in application
There has been a slight change in the manner of how PAC will work. While coding it I realized a weird thing - when the slave (MCU) can't talk until the Master (PC) requests something, there is little to no difference between sending a message and receiving one.
Thursday, September 24, 2009
PAC Quick Update
A little bit sleepless (particularly bad due to my weekend trip to Conneticut from New Jersey tomorrow), so a quick PAC update to try and tire myself out.
I finally got around to doing more work on PAC, mostly through the downtime from helping out others at a Python study group at a local hackerspace (of which I'll go more into detail in a later post). My original whiteboard drawing has been kind enough to act as a guiding force, albeit not the actual outline for the full implementation.
I finally got around to doing more work on PAC, mostly through the downtime from helping out others at a Python study group at a local hackerspace (of which I'll go more into detail in a later post). My original whiteboard drawing has been kind enough to act as a guiding force, albeit not the actual outline for the full implementation.
Wednesday, September 16, 2009
PAC - Python / AVR Communication Library
Tuesday, April 7, 2009
Client/Robot Control
Particularly when dealing with smaller, light weight robots, the issue of processing power in such a small package becomes problematic - particularly with budget in mind. Recently, netbooks (such as my beloved EEE PC, the original one with 7 inch screen) became a relatively cheap solution. Capable of being mounted on robots at least the size of a remote control car, they can provide a full OS of built in control and up to 2 gigahertz of processing power. Never mind that the "reduced" and "cheap" cost I'm talking about is still in the $200-$400 range.
Still, small development boards with tremendous processing power are becoming more popular, particularly with the dropping price and rising power of the ARM architecture. My own experience with the TS-7800 during my senior project provided a low cost, and surprisingly capable board that controlled my robot. Recent discoveries, such as Tin Can Tool's sexy, sexy 40-pin DIP Linux Board provide still more packaged processing power, even lower at $150 dollars a pop. Gumstix provides even more solutions starting as low as around $100.
But there is still a size limit, and the omnipresent requirement of a limited budget as well. The requirement becomes necessary, then, to off-load the processing from the robot to a networked "client". This client, typically another computer, has more processing power and can control the robot from afar, much like a human controls a remote control car.
My current and final robotics engineering class (Unified Robotics IV) at WPI is an excellent example of this. In order to produce affordable platforms for student use for the course, without sacrificing significant capabilities, we are using a serial-to-wifi bridge that goes from an Atmel Atmega644p micro controller to our computers via a LAN. (It is worth noting, however, I took a different route and merely used my bluetooth DIP module to connect to my robot, mostly due to my own impatience for the finished platform.)
Using this, the students can use a Client Framework with the unleashed power of our workstation computers (all 2.4gHz PCs) for our robots. This includes the integration of programs such as MATLAB and video processing programs for use in the lab.
Why do I bring this up?
The Framework has been the problem of late. The original provided Client Framework - made in C++ - was disorganized and unfinished. Several students, myself included, selected our favorite languages and began designing our own. I chose to create an object oriented Framework in Python. Initially I wrote the client framework out of haste and necessity. I have had a blast designing the framework, taking in all the implications of having an object oriented modular approach to designing robots. The possibilities of future projects seem almost endless, and I plan on exploring this side project after I graduate from here.
The Pitch
My goal is to create a simple object oriented python robot framework in which it is easy to develop a Robot-side framework to match it. Case in point - my current C robot-framework developed for the Atmega644p. A very probable future-case-in-point - my iRobot Create and its Python interface.
"Aren't there already projects like that," you ask? Yes, I am well aware of Pyro and Pyrobot, and will discuss those in some other post. I believe I am still bringing something new to the table.
The Framework will have three primary goals.
1. Create an object oriented approach to a viewing a Robot. This framework itself has need of accomplishing the following goals:
3. Allow creation of an AI object - each with their own set of goals, behaviors, and reactions to situations. The AI object is given a robot or set of robots to control.
With the Framework having a standardized approach, this can allow AI research (or simple games, since whatever work I do will be trivial to current AI research) to be easily explored with little to no work holding back the initial exploration.
For now?
I will be focusing on my coursework, of course. The framework will be put together primarily to accomplish the goals of laboratory exercises in Unified Robotics IV. The work I do, however, can be expanded upon and be used as a launching point. There are already numerous pieces of code to control the iRobot Create - some I wrote for the TEPRA Autonomous Robot Challenge (which I did well in) and - and more from projects such as pycreate. I can easily adapt this to the Robot Framework and use the Create as an easy low-maintenance platform for learning navigation and AI.
As always, more to come...
Still, small development boards with tremendous processing power are becoming more popular, particularly with the dropping price and rising power of the ARM architecture. My own experience with the TS-7800 during my senior project provided a low cost, and surprisingly capable board that controlled my robot. Recent discoveries, such as Tin Can Tool's sexy, sexy 40-pin DIP Linux Board provide still more packaged processing power, even lower at $150 dollars a pop. Gumstix provides even more solutions starting as low as around $100.
But there is still a size limit, and the omnipresent requirement of a limited budget as well. The requirement becomes necessary, then, to off-load the processing from the robot to a networked "client". This client, typically another computer, has more processing power and can control the robot from afar, much like a human controls a remote control car.
My current and final robotics engineering class (Unified Robotics IV) at WPI is an excellent example of this. In order to produce affordable platforms for student use for the course, without sacrificing significant capabilities, we are using a serial-to-wifi bridge that goes from an Atmel Atmega644p micro controller to our computers via a LAN. (It is worth noting, however, I took a different route and merely used my bluetooth DIP module to connect to my robot, mostly due to my own impatience for the finished platform.)
Using this, the students can use a Client Framework with the unleashed power of our workstation computers (all 2.4gHz PCs) for our robots. This includes the integration of programs such as MATLAB and video processing programs for use in the lab.
Why do I bring this up?
The Framework has been the problem of late. The original provided Client Framework - made in C++ - was disorganized and unfinished. Several students, myself included, selected our favorite languages and began designing our own. I chose to create an object oriented Framework in Python. Initially I wrote the client framework out of haste and necessity. I have had a blast designing the framework, taking in all the implications of having an object oriented modular approach to designing robots. The possibilities of future projects seem almost endless, and I plan on exploring this side project after I graduate from here.
The Pitch
My goal is to create a simple object oriented python robot framework in which it is easy to develop a Robot-side framework to match it. Case in point - my current C robot-framework developed for the Atmega644p. A very probable future-case-in-point - my iRobot Create and its Python interface.
"Aren't there already projects like that," you ask? Yes, I am well aware of Pyro and Pyrobot, and will discuss those in some other post. I believe I am still bringing something new to the table.
The Framework will have three primary goals.
1. Create an object oriented approach to a viewing a Robot. This framework itself has need of accomplishing the following goals:
- Provide simple, one-command interface for simple functions of the Robot. Turning, going straight, etc.
- Allow the robot to determine where it is from sensors.
- Develop and expand Map.
- Simple responses such as bumper response.
3. Allow creation of an AI object - each with their own set of goals, behaviors, and reactions to situations. The AI object is given a robot or set of robots to control.
With the Framework having a standardized approach, this can allow AI research (or simple games, since whatever work I do will be trivial to current AI research) to be easily explored with little to no work holding back the initial exploration.
For now?
I will be focusing on my coursework, of course. The framework will be put together primarily to accomplish the goals of laboratory exercises in Unified Robotics IV. The work I do, however, can be expanded upon and be used as a launching point. There are already numerous pieces of code to control the iRobot Create - some I wrote for the TEPRA Autonomous Robot Challenge (which I did well in) and - and more from projects such as pycreate. I can easily adapt this to the Robot Framework and use the Create as an easy low-maintenance platform for learning navigation and AI.
As always, more to come...
Subscribe to:
Posts (Atom)


