ROSCOE - A Scalable, Platform Independent Robot

Never use modern complex power cells without a BMU. Under different circumstances a discovery I made could have been fatal. There is still a positive potential between battery plus and earth ground through your soldering iron. Why this did not occur to me before fusing my tip to the gold connector I was soldering I dont know. I'm sure many engineers have wondered, as the light left their eyes, why they didnt consider some simple facts. I think I am going to follow the probe resistor acumen and no longer connect main power directly but lead in with a small resistive connection. The Anderson Power Pole is a great connector but it evaporated after repeated high power connections so I employed the gold connector standard. In actuality, there will probably be no need to disconnect the battery as there is a separate XLR charging plug connected to BMU. Eventually, ROSCOE will find his own recharging station using a design yet to be determined. 

Assembled components internal to case on 4" vinyl square post. Eventually 2 internal Pi's and 1 in battery box communicating with ARDrone boards. Most likely adding additional ultrasonic sensor at floor level to prevent possible toe jams and flatcats. Awaiting class T audio board to complete speech synthesis module with approx 8 watts output.

Configured RPi with EDimax to connect to unsecured ARDrone access point. Found a relatively up-to-date pure Java ARDrone V2 api. Numerous projects seem dropped after V1 of Parrot ARDrone, and V2 of ARDrone platform is radically enhanced with no backward compatibility. Found a ROS ARDrone pure Java project for V1 and will modify to create perhaps the first pure Java ROS ARDRone project for V2. The ardrone_autonomy project is V2, but has no provision for providing a Master ROS node. I'm building something that you can drop right on an RPi and run a ROS master to control the ARDrone such that the entire thing could theoretically be carried aloft, but thats another project.

At any rate I am getting nav data from the ARDrone boards through Java now. As far as status, of course it thinks its not flying, and the complete absence of its motors does not go unnoticed by the system. Is comes back with motor problem/emergency/not flying state but the sensor data and video still flow. The actual moving of the motors is probably the smallest part of the drone firmware so its no big deal to carry a few extra bytes and a couple board headers unused. The main board is still green light even with no motors attached.

You have to be careful mounting the boards and mind the standoff height as the sonar sensor is on a short leash. ROSCOE has a somewhat insectoid appearance as the camera sticks out like a proboscis and the sonar has those metal screen covers. The sonar sensors are a bit 'uplooking' due to short cable length. A very minimal amount of hot glue was used to secure the camera and sonar to the camera case. It always comes down to the hot glue. Hot glue: The duct tape of *real* engineers.

Assembled Parrot ARDrone boardset into disused 35mm underwater camera case. Will acquire a tripod mount to affix unit to robot with eventual aim of pan/tilt ability. Tested unit via ARDrone_autonomy ROS interface and verified video/nav. Intent is to utilize a full Java implementation ARDrone interface, readng directly from ARDrone data ports thus skipping various levels of API calls to publish nav and video topic to ROS Java directly.

Completed fork of ROSJava. Removed dependency on Google collections and assertion framework. Replaced with standard java collections and 'assert' keyword.

System is inexorably tied to Jetty 'netty' package for ChannelBuffer byte buffer as it generates references in message binding classes. The final tally of third party libs is as follows:

Jars required for ROSJava (ROSCOE fork)

commons-net-1.4.1 - 177k

commons-pool-1.6 - 109k

netty-3.2.0.Final - 930k

commons-lang-2.6 - 278k

ws-commons-util-1.0.1 - 35k

commons-httpclient-3.1 - 298k

commons-collections-2.1.1 - 172k

commons-digester-1.8.1 - 143k

commons-logging-1.1.2 - 61k

total - 2203k

Deep into modification of ROSJava. Removing google proprietary collection classes and assertion framework to use native Java in attempt to get bytecode down for RPi. Chopped out all the benchmarking and test junk thats not essential to runtime.  I have determined that the main areas to use the BigSack instead of the transient collections are the Parameter Server and the main message queue. These mods will give ROS something it needs that other message busses tout: durability. Advantages? Not 'lost work', more immediate resumption of tasks after reboot. Forensic analysis of data traffic (without ROSBagging). More importantly, the option of using those messages in realtime and offline sensor fusion.

The primary goal is to keep this 'open' and 'connected' and provide a mechanism to use whatever interesting advances arise in conjuntion with other ROS enabled platforms. How cool would it be to drop this code into say, an Atlas robot or a AUV or UAV and have it function right off? It seems that exposing the entire forked ROS runtime behind a service node and using that to interface other ROS networks would allow the capabilities of the forked master and parameter server to be used by ROS networks that already provide other-than-client services. 

ToDo: Research multiple masters, bridging, foreign relay:

http://www.ri.cmu.edu/education/McEachernRISSposter.pdf

Forming functors. To create colimits of functors that can be used in natural transformation and thereby form the commutative diagram that is at the heart of the ROSCOE cognition functions. Given the category of theorems 'dog', 'bone', 'food' and 'leg' how does one keep the dog from eating its own leg? It seems a simple noun, verb, noun functor where the domain is mapped to the codomain through simple verbs denoting a one-way transformation. bone->ispartof->dog, dog->eats->food, bone->ispartof->leg, leg->as->food maps the concept of 'bone' to 'food' in a commutative colimit yet preserves the concept of bone->ispartof->dog but creates no commutative mapping between bone->ispartof->dog to leg->as->food.

Configured espeak, flite, and festival on Raspian. Decided flite with vaguely Scottish sounding voice appropriate. Acquired portable powered speaker in a nice flat profile from clearance bin. Next step is to configure pocket sphinx for speech recognition.

Under no-load testing torque was sufficient to cause axle rotation. Acquired 16" bike steerer tube and bisected it longitudinally. Four holes were drilled in the steerer tube 2 in each fork half. Case was drilled to match holes in steerer tube and 2 7/16 stainless all thread rods were through bolted to line up each fork half with outside of motor hubs. Axles now firmly fixed and load capacity has been dramatically increased.