ROSCOE - A Scalable, Platform Independent Robot

So it occurred to me that I really dont need to have all addresses assigned via DHCP and indeed, that would suck. The only one I need is the immediate node attached to the ARDrone to have contact with the outside world and get a DHCP address, everyone else can have a static IP, including the eth0 port on the same node as wlan0 attached to ARDrone. Of course, name resolution and routing are fuXXored  there so it requires manual routing and changes to /etc/network/interfaces as indicated in the amended build instructions. 

Looks like maybe any binding to localhost is a bad idea here, but localhost is the default and yes, the master and slave run on localhost so its not like its a totally illegitimate URI, except that no one can find you from outside. Probably end up running DNS. ROSCOE needs multiple Pi's and you cant resolve the nodes on the other local 'robot net' by name without it. Since we are stuck with DHCP address assignment (like the Parrot ARDrone does) you cant rely on a regular IP address to put in your server startup bind declarations and a design goal is to use unmodified Parrot's. After that I can bind to ROS_HOSTNAME or perform the equivalent action in CommandLineLoader. 

The master server attempts to resolve a request for publishers by looking up the node name in a table and then comparing the URI of the request to the URI of the node retrieved from the table. If the 2 URI's do not match Master will attempt to shut down the running node and replace it with a new one listening at the URI of the request. In this way the client drives the creation of the slave server that will service future requests at the known URI, or so it seems to me. 

Recall that the slave server is composed of 2 subsystems: Apache XmlRpcServer and TcpRosServer which is the persistent P2P socket connect that actually handles topic data traffic. The XmlRpcServer is composed of a rudimentary web server which is necessary because random ports listening to the Http XmlRpc traffic are necessary and spawned as needed, something that is anathema to standalone containers like Apache that need lots of configs and specific port assignments.

TcpRosServer is based on the Netty project, part of JBoss. Essentially its a framework for protocol server construction that allows you to set up Java NIO channel groups and service them asynchronously and lots of other neat stuff we used to have to cobble here and there.

ROS is a big improvement over the PowerKernel architecture I devised where the connections are static and the compute graph is monolithic but getting everything to hook up is just as much a beeyotch. It occurred to me that wow, put some VTUN software on a 1U *nix box and install a ROS master and you have a ready-made dark web. Lo and behold I see the guy that wrote ROSJava has just such a project on his site. Great minds..

Anyway, when the client node requests a topic the master calls a shutdown of the slave XmlRpcServer and TcpRosServers and invokes this onNodeReplacement method that signals shutdown through the slave client I believe. Somewhere in the chain of events an attempted  connection to the old server or the new one is causing 'Connection Refused' exception and bombing the slave server. The web server runs its own thread so most likely theres a lifecycle issue there. Web server shutdown involves killing its listener thread and shutting down the thread pool of requests it maintains. Its possible I may have to more tightly integrate it, perhaps put it under a different Executor. 

And so it functions, ROS Java Core, on a Raspberry Pi. Heres a thing: I wondered why old Goog had the source for Apache XmlRpc in the ROS Java project and now I know, its because the current apache distro is broken as far as correctly loading the handlers of which XmlRpc is all about. Commons and client are fine, but you must use the XmlRpc Server build in the project. But yeah, its working! I'll put up repos soon but I'm having too much fun trying to break it now.

Going to stick with janky webserver, reason being that ROS needs to spin at least 2 instances of XmlRpcServer (master, slave) with an option of binding to any port on startup. These factors are incompatible with Tomcat startup parameters as it likes known ports and does not provide an easy way to spin a connector to bind to arbitrary ports or have multiple dynamic port listeners.

I hate redundancy in code. Everyone would claim the same but the difference is I wont overlook it. To me its always a thing that needs fixed, like that broken thing in the kitchen you see every morning. ROSJava uses the Apache XmlRpcServer as the master registration node that participants use to locate each other before establishing a persistent peer-to-peer Tcp socket. I know the registration server doesnt need high throughput but ROSJava uses the stub webserver that comes as a debug tool in Apache XmlRpcServer, you know, the one that says in the docs "I cant understand why people like and use this thing so much because it really actually sucks so use tomcat or something" [nonsic]. I think any good open connected robot should be running a real web server and I have Tomcat7 active now on Pi. They way they do it in ROSJava is to spin the web server inside of the master node, which is very Jetty-like but like I said; hate that redundancy, and I'm an old tomcat through and through. I can always make it work somehow. So even though this is a contest I'm going to give it a shot and construct a ROS XmlRpcServlet so I can bring up the master inside of tomcat and see how cool that turns out to be. 

Three plots of roll, yaw, and pitch variations and how they plot at the 90 degree pitch of ROSCOE. The test was performed by rocking the unit left/right, yaw by rotating the unit left/right, and pitch by rocking back and forth. I wanted to verify the readings with the board orientation in the head of ROSCOE:

Replaced Max232 chip with multi-drop mux board to perform TTL to RS232 to talk to motor controller. Board also provides RS485 and USB for the addition of those devices if necessary. Cleaned up sound by adding mass and damping to speaker box, as much as possible in 2 inches sq. Wired peripheral board for Arduino to break out pins 22-56 and wired forward floor level ultrasonic to pin 22. Added M-code 300 and 301 to take US ping or start publishing of ultrasonic range via USB to RPi to ROS to decision making. Now ready to assemble rear box containing battery and RPi1/Arduino and MUX board. See attached pic:

Added audio board to inner cabinet, seen at bottom green LED. quality is so, so more to do with speakers, which are metal-cone 2W @ 4R. Board is Shure class D 2X2W. Tested closed cabinet for several hours with infared thermo gun and not much above ambient. Camera case with ARDrone boards @ 93F, acceptable. Sniff test of cabinet after opening revealed only normal remnants of old 20mm shells and surplus store vs telltale bakelite baking.

Now that all the ultrasonics are in place the time has come to determine their optimum  use. Basically, the faster you are moving the less time you have stop and the less time something can be in range. The decision to halt forward momentum is based on how long something is in range vs closing distance which is all a function of speed. Its a classic time, speed distance calculation which as I see it becomes a linear programming problem in three dimensions. Using the speed axis as Y, the X plane becomes time something is in range and Z becomes distance. The attached photo shows the relationships via graph.