Labels

Thursday, February 28, 2013

How about a streaming point for a VGA projector?

I have an issue that has always bugged me, streaming a presentation from an iPad 2 to a VGA projector.  This would require the RPi to first of all be a Wireless Access Port to allow the iPad to connect to it.  Secondly, this would require the iPad to stream the VGA signal to the RPi in some sort of fashion.  I have seen other setups of this nature which would place the presentation on the wifi device for streaming, or to have a VNC server on a laptop which the wifi device accesses for streaming to the projector.  There is a real difficulty with this setup in that the iPad does not like to play nice with other things.  I could have used an Apple TV to do the streaming but it requires a third party wifi access port which both the ATV and the iPad are connected to.  I want to eliminate one device in the chain.  So how do I do this?

Video streaming in AirPlay has not been cracked yet.  Those keys are still pretty proprietary as well as the overall protocol.  In addition, the ATV2 is geared for 720p and the ATV3 is geared for 1080p (I am looking for something in the 1024x768 range) - so their usage might not be the best even if I don't resolve this with the RPi.  I may be barking up a tree that does not contain a squirrel here.

Update:  I stumbled across an article that claims AirPlay can be streamed to the RPi with Raspbmc at www.hanselman.com.  I will have to try this to see if it works!

Thinking about a distance sensor experiment

Last night I received another distance sensor, Ultrasonic Module HC-SR04 Distance Sensor For Arduino, from Amazon.  This is a sensor that is a little more long distance than the IR sensor that I have which has a range of 1-12 inches.  Using the two sensors, I now have a short distance and long distance resolution.

I was thinking that I might use the sensors in an experiment on top of the Create that would allow me to figure out the best way to use them.  I would like to design a wall follower.  Both of the sensors could be used to sweep back and forth, gathering distance/angle data and then take that data to build a model workup of the hallway or room that the Create was in.  From that information you could develop a driving routine that would day allow you to follow a wall within 5 inches.  Other parts of the routine would be able to react when something was placed in the way of the Create.  It would have to make a decision to go around and what would be the best way to do that.  I am thinking that the blackboard idea that I have proposed before would be the best option for doing this.  My use of the Blackboard would require me to have an overall computational strategy.  This is something that would need to be worked on.

I am still out on whether I should interface to an Arduino to control the sweeping sensors however.  That seems to be a better way to accomplish the goal.  Both of these sensors interface directly with the Arduino, whereas I would have to really think about how I would do this in the RPi.  I do have more than one RPi in order to accomplish multiple computer type tasks, but a control processor may be more useful this time around.  I could then concentrate on using the RPi to do the decision tasks.

Wednesday, February 27, 2013

I was fortunate to get a Blackboard Systems book

I just got a "Blackboard Systems" by Iain Craig delivered last night.  I had tried previously through Amazon to get this book but when I ordered it Amazon was not able to fulfill, so I have been waiting to finally get my hands on a copy.  Up to this point I have been looking through the Google Books copy at Blackboard Systems at Google Books.  But I have been wanting my own copy for my home library, and I like the feel of a book in my hands.  Going through Amazon, I note that there are very few copies available, so I feel fortunate.  I plan on using this book both for work and for working on the software for my Robot.

Tuesday, February 26, 2013

Going to try my hand at a cross-compiler for RPi

I was on the site at Kitware and got some instructions for setting up a cross-compiling platform.  I am planning on trying out the instructions tonight and hopefully, I will be able to have a way to compile all of my goodies in the future.  I have been longing for something to setup a meaningful toolchain so that I can compile the Robotic SW on a faster platform.  That way I should be able to update things as necessary and get it running quickly instead of waiting for a couple of hours for a compile.

Monday, February 25, 2013

Have had difficulty in getting interface to Pololu Maestro Servo controller

I have tried a whole bunch of things, trying to get the Pololu Maestro Servo controller to work with the RPi.  Although I was successful at loading the linux loads from the Pololu site, it turns out that it needs an i386 architecture which does not help me.  So what do I do now?  I have been searching all over the net looking for someone who has successfully used the RPi with this controller.  I may have to go back to my SSC-32 to get it to work.  I would really like to use the Maestro because the analog input has a lot more bits to play with.  Time will tell.

Update: I did manage to load the Pololu Maestro controller onto my laptop yesterday and this morning I was able to get the servos to move and read the output from the distance sensor.  So I at least know that the board works on a Windows 7 platform.  I just need to do the same thing via the RPi.

Saturday, February 23, 2013

Built up the pan-tilt camera unit and distance sensor sweep

It's Saturday and I was given the chance to,work on some Robotic elements that I have been neglecting. I took about an hour to make up
a Pan/Tilt unit with some spare servos that I had laying around. I was also able to make up a sensor sweep with an additional servo. The two units look like this (sorry for the poor picture quality, crappy camera on the iPad):





The Pan/Tilt unit on the left has a servo mounted vertically for Pan and a servo mounted horizontally for Tilt. The webcam is a Microsoft Lifecam with a IDE field of view and a built in microphone. Here is a close up.





The servo mounts are some that I had left over from two years ago when I was diddling with Robotics. The sweep unit uses one servo mounted vertically.





The L shaped bracket has an IR distance sensor mounted on it. I am hoping to interface these two units to a Palolu Maestro servo controller. I did see where someone had written a Python library to control the Maestro using ROS. So now you know what direction that I am headed.

Thursday, February 21, 2013

Starting to think of the Robotic SW that I will use

So far, I haven't said much about what software will run where in the Robot that I am working on.  In the back of my mind, I am intending on learning a bit about some Artificial Intelligence (AI) techniques.  The AI technique that I will be using is Blackboard.  Imagine for a moment that you have several mathematicians sitting in front of a blackboard trying to solve a math problem.  At any one time one of them will get up and put part of the resolution on the board.  There is no  communication between the mathematicians other than through the blackboard.  There might be a secretary who puts the original problem on the board, and perhaps another secretary that records the solution when they are finished.  But event the secretaries do not have to communicate with the mathematicians.  This is kind of the idea of how a blackboard works.

In my Robot example there would be Knowledge Sources (those elements that do the thinking) that grab sensor information and place it on a global data area (the Blackboard).  Other Knowledge Sources would try to make sense of the information and place updates onto the Blackboard which in turn triggers different Knowledge Sources to act.  Sometimes the Blackboard information would change so that still different Knowledge Sources would output the information to actuators (wheels, servos, etc.) to act upon the information.  In fact, which Knowledge Source goes next could be decided by different Knowledge Sources.  This is kind of the idea that I will use.

The pattern for the Blackboard architecture will be based upon a paper, "Two complementary patterns to build multi-expert systems" by Philippe Lalanda. Additional papers will be added as I progress.  I do know that whatever I come up with will have to have a distributed capability - my plan was use one RPi as a camera sensor/image processing element, a second RPi to control motors and servos, and a third RPi to do the thinking.

Setup an RPi as a Wireless Access Point

This morning I used the information I found at TheBITBangTheory to setup one of my RPis to be a wireless access point.  This particular RPi is the one that I have the PiFace plugged into, and would be the one that I would mount on the iCreate.  My theory is this - create an internal network, isolated from the outside that connects the RPis with each other.  Since I am intending on isolating the home network, I should probably put some rules in order to keep outsiders from entering my network while I am attempting to run some experiments.  I am already planning on moving one of my managed switches to the downstairs bedroom for the purpose of isolating the RPi test setup from the rest of my home network.  I just don't want to give anyone on the outside a free ride on my internet connection (Verizon frowns on this).  So I will need to use WPA2 between individual RPis that are part of the test setup and in addition, I will need to put the test setup on a different VLAN from the rest of the house; sort of an experimental network.
I have been appreciative of the article that I found because the author goes into some detail about first determining that your usb wireless adapter is able to do the AP thing.  After determining that the adapter will work, then he goes into explaining about setting up hostapd and udhcpd in an AP mode with encrypted access.  In my particular case, I think that I will use a subnet that is nowhere close to what I use in the house.  That way I can minimize the stray electrons that move about.
Update: I followed the instructions almost to the end but did not execute the last commands that would get the services running.  The reason that I did not do this was that I wanted to wait until after I was home (I'm doing this at work during lunch) to complete the task.  I forsee that I will have a problem since I added the NAT capability and the subnet is not recognized within the house network.

Unfortunately, I was unable,to get the hostapd service to start after the configuration. I took the same wireless USB adapter and was able to use the WiFi Configuration utility on the RPi to connect to my home network. I did notice that I was able to use the Ethernet or the WiFi but not both at the same time. Is there some setting that I have not discovered yet to get this working correctly?

Put in order for Gertboard

I put in an order yesterday for an assembled Gertboard, an additional RPi, a cable breakout from Adafruit, and a wire connector kit.  I decided on getting the Gertboard after looking through the user manual.  I am convinced that it gives a lot more control over what the RPi can do in terms of interfacing that what I have available with the PiFace.  However, right now I will deal with the PiFace and report on the pros and cons of making my Robotic interface.

The key detail that told me this would be a good buy was the fact that the Gertboard has a plug panel arrangement.  You only patch in the items that you wish to use.  There are different groupings of capability on the board, but you only have to interface to some of them, and arrange them in any order you wish.  Good design for experimentation!

Wednesday, February 20, 2013

Trying to make sense of an iRobot Create setup

Well, I have been trying to figure out how to wire the RPi / PiFace / iRobot Create (iCreate) / SSC-32 so that I can do what I want to on the iCreate both on the bench and mounted on the iCreate.  So far my test setup is as follows:



So far, what I haven't shown in this diagram is the connection wires between the iCreate DB25 connector and the PiFace.  I have decided that they will of necessity have to go through a protoboard.  The PiFace will also be connected to a distance sensor.  The actual control for movement will be done by serial connection (the iCreate USB to serial cable) to the iCreate body.  This stems from the fact that I have not figured out which pins are going to do what with the interface.  I can put this test setup together over the course of a few weeks. I do show a temporary connection to the RPi via Ethernet as this will serve to be the network connection to the RPi while it is on the bench.  While the test setup is on the bench, the MonoPrice Battery power will be supplied by a dual USB power supply and the iCreate Battery power will be supplied by a 6 volt power supply.

So what am I able to do with this setup?  I am able to build up to a final configuration over time.  The key elements are:
(1) implement a connection strategy between the RPi and some other controller over WiFi or Ethernet
(2) control of the pan/tilt servos via the SSC-32
(3) stream the camera to and through the RPi
(4) control the iCreate via a serial connection from the RPi
(5) interface a distance sensor to the RPi via the PiFace
(6) interface various digital pinouts on the iCreate DB25 connector via the PiFace/Protoboard
(7) Use either battery power or power supply to power up the equipment

I am hoping that I will be able to put together the test setup in a number of phases:

(1) System on bench / ethernet connection:
a. build up a Lexan plate with holes drilled for the iCreate body, mounting for the RPi, mounting for the SSC-32, mounting for hub / batteries, and mounting for a pan/tilt unit for the camera.
b. mount plate on the wood platform via standoffs with the rest screwed into the plate.
c. build up pan/tilt unit, interface pan/tilt to SSC-32, test with RPi.
d. connect camera into system, test with RPi
e. connect RPi over the network via ethernet, stream video over ethernet
(2) System mounted on iCreate / power from bench(3) System mounted on iCreate, all connections independent of bench

Tuesday, February 19, 2013

Stupid RPi Tip #3 - have a standard setup in mind

Along with the idea of tagging the SD Cards, you should always have a standard setup in mind when putting together a fresh SD card.  I would go with the following elements (assuming a Raspbian build):
(1) setup the SD card to expand the partition to the limit of what is available on the SD card (from "sudo raspi-config")
(2) make sure that the keyboard is setup for your country (in my case I changed the /etc/default/keyboard from "gb" to "us")
(3) turn on SSH access (from "sudo raspi-config")
(4) install a VNC server (from "sudo apt-get install tightvncserver")
(5) boot up in  GUI mode (from "sudo raspi-config")
(6) setup wireless access, if you normally connect this way, otherwise Ethernet is usually better (I keep an Ethernet hub on the table with my RPis).

Stupid RPi Tip #2 - mind your power sources

I have learned a few things about power sources over the years. One, you never want to be on the hairy edge of any power input or output requirement and two, current is additive at times. You will deal with a lot of 5 volt sources to power the RPi(s) and usually any USB hub(s) that you have around, not to mention the monitor and powered speakers.  So how do we deal with this?

Make sure that you pay attention to the current draw from the RPi.  The USB ports only allow for 150 ma draw and exceeding that value also affects the ethernet port; not to mention the damage that it might cause (there is no overcurrent protection).  I would start by only connecting powered USB hubs to the USB ports on the RPi.  In that way, you are pretty much assured that you will not be drawing too much current from the port.  However, be careful - I have heard reports that there are some older hubs that try to draw the normal 500 ma from the main USB port connection.

The problem with current USB hubs is that you don't know how much current that they will normally provide.  The package typically will not tell you what the power supply is capable of delivering.  Sometimes, you have to do a little extra research to find out.  E.g., when you are standing in the store about to pick up the USB hub, do a check with your smart phone to find out if there are some specs available on the model.  A lot of times you will see a 5volt/1 amp power supply for a 7-port USB hub.  Do the math, if the spec says that the USB port should supply 500 ma, then there is no way that a 1 amp (1000 ma) supply is sufficient.  Finding hubs capable of supplying the spec level current is very hard.  I have an old 4-port Belkin hub that has a 5 volt/2.5 amp supply - it has the capability of supplying the specified current on each port with some extra.

If at all possible find hubs that have supplies that are powered by 5 volt supplies.  The reason is that eventually you may want to power the hub with a 5 volt battery that would also powers the RPi.

Monday, February 18, 2013

Building the ROS Core and OpenCV

I was able to have Presidents Day off and my wife is out to lunch with my daughter. This is a perfect time to get up to date with my RPi things. I decided to load OpenCV and ROS onto one of the 16GB SD cards. I am currently following the instructions on http://www.ros.org/wiki/fuerte/Installation/Debian. The instructions are a little old, but do have some steps for a Wheezy build which is the current Raspbian build on the RPi website. Apparently I performed some of this setup earlier but I don't remember it. I think that I am going to have to start keeping a logbook in order to make sure that I don't repeat myself again. That is probably a good topic for an RPi Tip.

Sunday, February 17, 2013

Stupid RPi Tip #1 - Tag Your SD Cards

SD cards are becoming more and more available in larger and larger sizes for cheap. As a result, you may find yourself deciding to keep separate experiments on different cards. This often results in a plethora of cards laying around on the table along with their holders in separate piles. I am exaggerating here but I have 10 SD cards lying on my test setup table right now. The other problem is that you are constantly adding things to the images and even overwriting the card contents. We have already learned what to do with keeping disk drives organized, but what about these cards?
What I have learned to do is to label the cards and the SD card containers. I serialize each card by attaching a label with a number (one up from the previous numbered card). This can be done to the front or the back (if it's on the back, you can read the number when it's in the RPi). I make sure that the number is in ink, I don't put anything else on the card itself. I can always refer to this specific card because it has a unique number. In fact, as I am taking notes on an experiment, I can refer to it as SD#n, and i don't get confused. On the SD card case, I put a label strip but now I switch to a pencil and put the version of the original image (e.g., Raspian 10/28/12) along with the number on the SD card (circled in pencil). As I make changes to what is on the card, I can add the change in pencil.
Trust me, this will keep you from getting confused about what card goes with what project. The SD card slot does not interfere with the label as long as the label is on the front. It doesn't have to be a big label, only big enough to have the number on it.

Update:  I found out that Avery 5412 labels can be used on both a micro-SD and the adapter.  I would use them to record the number of the SD card and put what version and changes on the label in the cover.  In this case, the micro-SD label will show up on the bottom and is visible so that you know which SD is in the RPi.

Friday, February 15, 2013

Wondering about interface in Thin Client

It occurred to me today that if I want to write code for the AVR processor on the iCreate, I will have to have access to the WinAVR compiler/linker and the USB port from a Windows 7 machine.  I could do this by compiling code in a Windows 7 VM running on my Mac Mini but this would mean that I would still have to plug into the USB port on the Mac Mini to get it to download.  I was wondering if I could come up with an across the lan way of having a remote USB port, i.e., redirecting the USB output to the RPi and then on from the USB Hub to the iCreate Command Module.  Conversely, I would like to be able to plug in something USB to the USB Hub and have it appear remote across the lan.  Need to do some further research about this.

Update: I was able to discover a project on SourceForge called USB over IP (http://usbip.sourceforge.net). This appears to have most of what I am looking for. The problem is that there is no part that is useful for Mac OSX. There was a different project at https://github.com/forensix/libusbip called libusbip. I am not sure if they are reflections of each other or not. What I may end up doing is altering both and combining them to get what I need. One thing is for sure, the cost of hardware devices that do the same thing is above $190 apiece. It would be worth my time to give back to the community.

Thursday, February 14, 2013

Another Experimentation Point

I just got through looking at a YouTube video of a guy opening and closing his garage door with a Siri controlled RPi setup (https://github.com/plamoni/SiriProxy). That is just pure genius and I might try something out since I have an iPhone with Siri capability.

I am going to have to remember

I am going to have to remember which blog that I am writing to.  I almost posted something from the Raspberry Pi blog that I am using  (http://rpiexperimenter.blogspot.com).  I am really concentrating efforts there on my newfound hobby.

Was able to get PwnPi up and running

I guess in the grand scheme of things, I am starting to get proficient at moving images over to SD cards on the Mac Mini. The latest one was for the PwnPi image. This is a penetration tester image containing about 200 tools for use in breaking into systems. Since I am interested in obtaining a CEH certification in the future, I thought that I might get ahold of this district and try,out a few of the tools on my own network. I downloaded the image through the http://PwnPi.net website.

I was home anyway because I threw out my back at the gym yesterday.

Wednesday, February 13, 2013

Notes on RPi Thin Client

I was able to do some testing last evening with the RPi Thin Client software.  I was able to use one of the packages to connect VNC wise to both of the other RPis and to my Mac Mini.  It is important that I am able to connect to the Mac Mini because I intend on using some VMs to do special things; like simulate an RPi and develop new image loads.  This will be a way that I can compile something that would normally take a long time on an RPi, like the OS.

I did note that the VNC connection assumes that you want to use an SSL tunnel (not necessary in my house).  The response on the RPis was pretty good but not fabulous, I assume because of the clock speed on the RPi VNC servers.  I was able to link into my Mac Mini after a while, but only after I changed the depth to 24 bits.  Before that all I got was crashes of the VNC application.

Again what I did not test on this go around was whether the RDP and X Windows connection would work.  I need the RDP for the Windows 7 VM that I can run from my Mac Mini.  I need the X Windows connections for those times that I use the Ubuntu VMs on the Mac Mini.  I might even decide to move the Mac Mini into the downstairs bedroom - nah, bad idea.

Tuesday, February 12, 2013

Trying to put together a Thin Client

After contemplating the RPi setup that I have, it occurred to me that if I sacrifice one of the three RPis that I own, I could setup a rather nice little Thin Client.  This makes a whole lot of sense because I can use the Thin Client to get into pretty much anything in my home network, including the other RPis.  I took a look at the Raspberry Pi Thin Client project and made a determination that it would supply most of my needs.  It also happens to have a very tiny image that I was able to download.

Well, I downloaded the RPi thin client from Google drive and placed it onto a 2GB SD card last night.  I did not have much of a chance to try it out until this morning before going to work.  I did bump into an obvious problem, I didn't know how to use pretty much any of the tools in the image.  That will be my next challenge.  I know that I need to be able to do RDP, VNC, and probably XWindows.  I would really like to use the Thin Client to do XWindows.  Right now, I was very pleased to see that the system came up without a hitch.  I had reformatted the SD Card from my Mac prior to loading the thin client image.

I can foresee using the Thin Client to be able to access the two remaining RPis, my Mac Mini, any one of several VMs running in the Mac Mini, my work laptop, the home laptop, the WMC computer, and other servers in the house as well as external servers that I am in charge of.  This would be a great way to access these elements.  However, I do see a problem in the meantime because there is no X11 acceleration in the image, but that has been promised.  Cudos to the Thin Client project for the work done thus far.

Monday, February 11, 2013

Put up most of the Test Setup this weekend

This weekend I had a little time to try getting my things in order.  I used most of the time to put together a Test Setup in one of the downstairs bedrooms.


I basically took a keyboard stand and placed a 2' by 4' piece of 3/4" plywood on it.  Then I started strapping down other items.  I put my Robotic Arm on a roll around stand to the left of the setup.  I spent most of the time updating and then upgrading each of the three RPis.  I also added a tightvnc server to each of them and made sure the keyboard was US and the bootup goes right directly into the GUI.  I should probably change this to coming up to the command line and then as I need it, bring up the GUI with "startx".  I can do this by executing "sudo raspi-config" from the command line and selecting the GUI to not boot up.  I made sure that each of the RPis have an SSH server running.  I did discover two things over the weekend:

(1) strangely enough, the HDMI-to-VGA cable (the cheapest one that I could get) worked just fine with my VGA monitor.
(2) I discovered that a cable only 4-port USB hub (unpowered) was able to be used to pass power to two RPis at the same time, thereby freeing up one port on the power supply.

I also checked the serial cable, it is based upon an sl2303 chipset.  It seemed to recognize the cable, although I have not checked out the workings of the servos via the SSC-32 yet.

Saturday, February 9, 2013

Started setting up the test setup

Well, today I started setting up my test setup. I started with a few hiccups, namely not being able to get my video working right. After much trying with some USB to VGA interfaces, I went back to a really cheap hdmi to VGA cable that I had bought last week. It worked like a champ. Anyway, here is the setup.





It turned out rather well.

-- LW

Friday, February 8, 2013

Might Try My Hand at a Pentester

Last night when I was going through some Raspberry Pi stuff, I happened upon two Pentesting packages for the RPi:

http://sourceforge.net/projects/pwnpi/
http://pwnpi.net/

http://blog.pwnieexpress.com/post/24967860602/raspberry-pwn-a-pentesting-release-for-the-raspberry
https://github.com/pwnieexpress/Raspberry-Pwn

The first two urls are for the PwnPi distro which is self contained, the second url being the home page.  The next two urls are for PwnieExpress which you have to build from the Debian Weezy distro (at http://www.raspberrypi.org/downloads).  The instructions are at the github address to set it up.

This would be a good chance to try out a different use for the RPi and at the same time get some background info for the CEH which I have been studying for.

Thursday, February 7, 2013

So Which Came First?

My hope in setting up a Test circuit for the RPi is to allow for multiple experiments and software developments without having to do much in the way of circuit design and development.  I do have some prototyping equipment and I do know some things about circuit design but I would rather plug and play to accomplish the task. Besides, I would like to know how far I can get without having to resort to circuit design (I might resort in the future, but not now).  So my list of things to do has changed somewhat:

1. Setup the basic test setup in the downstairs bedroom / computer room with the regular power supplies.
2. Add an additional Ethernet line from the home network to allow for this (I am thinking of putting it on a separate vlan, just to keep it simple and safe).
3. Setup the Ubuntu laptop for experiments with the RPi including compiling a new kernel and possibly running an emulation of the RPi.
4. Experiment 1: setup a thin client VNC/RDP on RPi to be able to access other servers in the home network.
5. Experiment 2: build camera servo pan/tilt unit, mount camera, connect camera servos to SSC-32, run check on pan/tilt with camera streaming on RPi.
6. Experiment 3: setup web service on RPi to allow control from "Control" app on iPad - check against pan/tilt unit, setup camera stream to iPad (might be really hard, or not possible).
7. Experiment 4: connect robotic arm servos to SSC-32, run check on robotic arm servos on RPi
8. Experiment 5: connect bluetooth, check bluetooth control on iCreate on RPi.
9. Experiment 6: setup Raspbmc on RPi (diff SD card), check video streaming to monitor, setup read of HDHR Prime TV signal on Raspbmc.
10. Experiment 7: setup Shorewall router on RPi (diff SD card, secondary USB-Ethernet cable), setup router between different vlans on home network.

Thats all for now.

Configuration for testing camera on iCreate

I thought a little more about what I was going to do after getting the software working on the Test Setup.  When I go to move the RPi and equipment onto the iCreate, I probably need some sort of a test platform.  Since I was already thinking about using multiple RPis, it occurred to me that I could just re-use the test setup with the iCreate by using a wireless interface.  The following diagram shows what I am thinking about.


As you can see in the diagram, the RPi with the PiFace fits nicely into a package that interfaces to the iCreate Command Module and a Distance Sensor.  I was thinking that I might need the distance sensor (around 30cm distance) to figure out what is in the way (chair legs, that kind of thing) and respond to it.  By keeping the test setup intact, I can then write code to interface to what the iCreate is doing.  This seems like a pretty elegant plan of attack for what I want.


Wednesday, February 6, 2013

Thinking of a Thin Client on RPi

It occurs to me that if I have the RPi in the bedroom and my MacMini is in a different room and various other servers are located throughout the house, it might be good to incorporate a Thin Client on the test setup.  This would enable me to get to other boxes in the network and do things without having to get up from the chair (I know, lazy me).  I already have VNC running throughout the house, I just need to incorporate a VNC/RDP client on RPi in order to do this.  It might not be really fast but at least it is cheap to put together.  Need to do some further research.

Posted a question on Reddit about Test Setup

Interesting, I posted a question on Reddit ( see piface_came_in_now_on_to_experimenting) about my test setup asking if anyone had experience with multi-port USB hubs and power requirements.  I did get some posts re my question but another question was raised, namely about the USB-Serial cable that I was using.  To tell you the truth, I had not even thought about it.  I was able to get the cable to work with an old Ubuntu laptop a couple of years ago, so I thought that I would not have any issues.  I will be able to test out the test setup over the weekend, but I will be paying particular attention to this issue.

Tuesday, February 5, 2013

The PiFace Came In

I was able to get several parts in over the last couple of weeks. As shown in this photo, I now have a battery, a new 7 port USB hub, a new RPi, and the new PiFace.




I have plans for later on using the battery, which has both a 1 amp and 2.1 amp output to supply power to a robotic vehicle (using my iCreate robot), specifically the RPi and some servos. The 7 port USB hub can also be used to interface to various pieces of equipment (including a camera) and be controllable via the RPi.  The PiFace will be used to interface to the iCreate and some servos so that I can control both movement and the other equipment at the same time.  I don't have a picture of the SSC-32 which is a multiple servo controller with a serial interface.

My game plan is to setup a test rig for trying out some Robotics things (which I have been wanting to do for a long time).  The test setup looks like the following.



This setup of course assumes that I am not connected to my home network or to an external laptop; which will pretty much happen.  Also, I have a bluetooth setup with the iCreate that I could use, sans PiFace to control movement.  This of course is TBD.