the quest for robots

Got the ports all figured out, and after thinking about how to mount the servo + devices to the intercom, I decided that it would be best to attach only the servo and make wires long enough to keep the Raspberry Pi on the ground. I really wanted a nuts-and-bolts kind of configuration to mount the servo, but mounting squares (sponge-y tapes) were inevitably the simplest and most readily available solution. Currently, the servo would stall and stop pushing after around 3 seconds of pressing, but that should be fixed with some calibration of servo positions. Will continue to clean the project up until I get an idea for the next project, but for now, Success!

Had a busy weekend and had no time to work on this. Trying to figure out the ports/SSL issue before thinking about mounting it to the intercom. On a side note, went back to Michigan the other night for business and tried to move the servo from there, but the target client had crashed for some reason. Home router had ports blocked so I couldn't ssh into the Raspberry Pi. Oh well.

Gahhh. Just going to ramble on this one: Websockets is unstable going through cellular networks Searched Google and solution seems to be SSL connections Tried to implement, and it works to some extent,  but realized that I'll have to have both Apache, which was running my web front end, and Tornado both listen to 443 which cannot happen Realize finally that Tornado is a SERVER just like Apache Try to implement web client through Tornado It works but Websocket server and the web client still different instances so still can't have both listen, or that's what I'm thinking but I don't have time to think about it at present. Gotta sleep.

Didn't have too much time to work on it, so spent the time making the web client more mobile-friendly, as it would get most used through a mobile browser. Still thinking of the best way to attach the servo to the intercom. Did look through some implementations of servos that pressed camera buttons and though they were neat, but I should keep looking around for inspiration.

Took a good 2 hours to change all the messages into JSON format and make it work. But it is done. All is JSON. Using it like a map, currently with three key-value pairs: "id" : for entering a session ID of another session if needed. Currently used for the web client to receive a acknowledge response to confirm that the target received the message (mainly for testing purposes). "type" : probably the most functional data going through all this. Current types are STARTUP_TYPE - for when the target sends its initial message, the server uses this to mark which session is the target. REQUEST_TYPE - for when the web client sends a request to the target. Server uses this to send request to target. ACK_TYPE - for when the target finishes carrying out the requests and sends an acknowledgement of the completion of the request to the server. Server uses this to send confirmation to the web client  MISC_MSG_TYPE - for anything else. DEBUG_TYPE - current...

The servos were delivered today, and I started working on them once I came back home from work.  The initial set up I had with RPi.GPIO was... a failure.  When connected, the servo would just twitch and continue to groan with uncertainty about where it should position itself.  Wanting to see what it should actually do, I fired up my Arduino that's been inactive for quite some time, connected the servo and loaded up the Servo library. It worked like a charm. The difference between a real-time PWM and a soft PWM was very visible.  For a while, I was thinking about maybe using the Arduino as the servo controller and have the Raspberry Pi just send a single high signal that would trigger the Arduino to move the servo. However, the extra size and power that would be required put me back to my senses. I have to say I was pretty discouraged. It was probably because I was really expecting whatever I had implemented to work right off the bat. After eati...

Ironically, I am more busy during the weekends than the weekdays. Spent all weekend getting a wireless adapter settings issue solved for the raspberry pi.

There's always an obstacle.. I implemented the pwm module as described in the link in the previous post, but oddly enough, it didn't work. The error I received: AttributeError: 'module' object has no attribute 'PWM' After some time scratching my head, I came to the realization that somehow my python was running an older version of the RPi.GPIO library, as PWM control was a pretty recent addition to the library.  And indeed it was.  Not really sure what's happening in detail, but it seems that there are two different... entities? that manage libraries for Python. One is through the usual "apt-get" command and the other is "pip." It appears that Python looks at "pip" first, and it currently linked RPi.GPIO to a really old version of the library.  Uninstalling that older version ("pip uninstall RPi.GPIO") and using the version I obtained through apt-get ("apt-get install python-rpi.gpio...

I just realized that the RPi.GPIO library (for programming the Raspberry Pi's input/output) already has PWM control, giving me a much more efficient control of duty cycles... At least the previous exercise ("duty cycle testing") refreshed me on it. PWM control on RPi.GPIO: http://code.google.com/p/raspberry-gpio-python/wiki/PWM

Currently, the messages that the clients and the server are sending each other is just a mess. They're pretty much just string dumps of whatever textual information I can add to describe what the message should do.  I pretty much have on_message methods regexing to find certain words for key commands...  Hence I had a big TODO that reminded me that I have to give structure to these messages, and JSON seems like the best fit for that. Since the ETA of the servo is set on Monday, I should get this "house cleaning" done for now. Didn't have much time after I got home today, so I just started reading on JSON for Python.  Nothing complicated: json.dumps and json.loads. Done?  As expected, the hard (well, not hard, but requires effor?) part will be organizing the current message structure and not implementation.

Now that I saw a physical response, I should try to make it similar to how a servo should be controlled. Servos are actuators that receive (expect) position input (as opposed to motors, which receive speed/intensity input). Simply put, it registers input as pulses, decoding the ratio of high (a "on" signal) to low in a given period as a position value.  A better explanation :  http://learn.adafruit.com/adafruits-raspberry-pi-lesson-8-using-a-servo-motor/servo-motors As I am waiting for my servo to be shipped, I will continue to work with the LED light.  As opposed to my previous setup of having the light turn on every time the request is given, I will have the light turn on and off in a regular pattern until a request is given, upon which the pattern will change for one "cycle" (on-and-off pair). The on-and-off logic (previously the LED control logic) will be run in a separate thread: def dCycle(*args):    global dCVal   ...

Since the environment of the client-server-target is currently quite functional in the messaging standpoint, I decided to try connecting a simple LED light to the Raspberry Pi to see if it could "open" a door when the command is received. Installed the RPi.GPIO module (a Python module that gives the user command of the GPIO--General-Purpose Input/Output--ports in the Raspberry Pi) and connected the LED light to a GPIO pin. When the target received a request message, it would signal the GPIO pin to drive a current to the LED to light it up for 2 seconds. in main: if __name__ == "__main__":   GPIO.setmode(GPIO.BCM)   GPIO.setup(17, GPIO.OUT) in the on_message's request-received logic:      GPIO.output(17, True)      time.sleep(2)      GPIO.output(17, False) The video is a weak visual result. You can a click when the LED lights up; that was the sound of the key being pressed that sent the request message. Now, tim...

1. General Setup of System Well, there was that trouble connecting to the webserver mentioned in the previous post, which was more my fault at forgetting than anything. In addition, there's always the process of setting up new environments in Linux. Notable obstacle was getting the python setup in the webserver to execute scripts properly in the beginning because of missing modules (the Raspberry had python pre-installed with the Linux distribution I installed it with). More of the time obstacle than anything, and time (and some google searching for commands) solved this. Solution: Time and Google 2. Session Management Once I got a basic Websocket-compatible server running in the webserver with the help of Tornado (got some help from  http://lowpowerlab.com/blog/2013/01/17/raspberrypi-websockets-with-python-tornado/ . The site was for a Raspberry Pi, but I actually used it for an implementation for the webserver), I noticed that I was unable to send messages cross-session...