Robotic Cerebellum. A simple robotics framework utilizing Web2 and REST technologies to provide component based control, sensor, visualization, navigation, and other processing faculties and services. The end objective being useful robotic work.
Currently, there is not a cohesive solution for an open source robotics framework utilizing REST technologies. And created for off the shelf computers. This is a proposal for an open source solution for this gap.
webserver an XML-RPC DOH! - light open source webserver offering basic XML-RPC services - should seriously consider swapping over - I'd also be interested if Tomcat supports deployment as well.
XML-RPC represents a calling message system - I do not know how GWT RPC manages its messages. With JSON a message would need to be defined - as JSON is really a data format. The records could easily be defined but it would be unique.
pro - leaning torwards XML-RPC - more structured than HTTP-ad hoc paramaters
pro - not too bloated like SOAP at least for the initial framework
pro - possible automated code generators for interface stubs
con - no currently generated
con - possible problem for complex types of parameter (or similiar to JSON?)
con - don't know how to create a HTML form which does a GET or POST using XML-RPC - single value HTTPREQUEST=<method>< ...? is a possible implementation
con - it appears that do to the nature of HTTP requests from HTML forms - the data is "flattened" - so some solutions include, flattening the request - makes it difficult to have complex types? - here is another example
if the server understood that the xml data would exist in HTTPREQUEST server variable then I think it would be pretty straight forward. You can make a GET or POST - it has one variable - the one variable is HTTPREQUEST - the downside of this would be, the XML would need to be assembled by javascript before setting.
It takes only 2 bits or control lines to provide simple control for a continuous dc motor. There appears to be 2 basic patterns to motor controllers. One, which is common in H-Bridge designs, I call the "Power Left Power Right" control pattern. One bit will turn the motor one way, the other bit will turn the motor in the opposite direction. Turn both on at the same time and some circuitry will destroy itself by shorting. The other basic pattern I call the "Power Direction" control pattern. Here one bit controls all the power. The other controls the direction. If the power is off, it does not matter what the direction bit is set to, the motor will be stopped.
all <Class>.class.toString() changed to <Class>.class.getCanonicalName()
remove name from OperatorEntry
Determine if a Message is Broadcasted out on Category or Class should it go out on Notify too - TBD - thinking yes
Use Cases ! - All Message Types follow the rule - when they leave a service all are addressed. Class Category & Address
Use Cases ! - Class only gets invoked on Class | Category invoked only on Category
All Transmuters will need a list of Categories -> how to config? a field which is overridden?
Category - Class - Address Filter -> to be added to all config? - to be added to all Inboxes
Operator.invoke vs Transmuter.invoke - need to normalize - static would be most accessible if possible
bolster config reporting - e.g. if config field exists and file is not found - warn - if finished with constructor and config is null warn
remove dataClass from object - should be pulled off of .data.getClass().getCanonicalName() - NORMALIZE
getCanonical name for ServiceEntry
implement global / static into garden objects
fix hashmap to use isKey column in db
make return Message from Transmuter invoke return object
Message.Object - should be an Array of Objects || paramters in java.reflect.invoke
outbox - needs to check if AddressedMessage is to self - should not send it
xml insert & extract containers need to support tags passed in
dispatch vs static route -- when to use each - static routes need to be established between operators
config - need to be able to specify static routes in config
pre-filter - post filter
junit tests - xml insert -> parse -> empty list -> empty hashmap -> insert -> parse
nightly build
generate contructors e.g. new ServiceEntry (String a, Boolean b, ........)
generate null constructors new ServiceEntry (null) - no field initialization
STANDARDIZE - names -> e.g. serviceName vs class vs category vs type
should there be only 1 type of commuter? - 2 service directories now 1 local 1 remote
MUST CREATE UNIT TESTS !!
When service directory changes Operator must broadcast new service directory
demo - where users can erase and drag-drop components through the web in order to get different behaviors on bot !
indistinguishable xdfd
Logging adjustments - 45078 [neck] INFO class org.osros.framework.Transmuter - ***neck invoking stopMotor (null)*** <-- type of Message (have one Invoke call the other) 45078 [neck_outbox] INFO class org.osros.framework.Outbox - addressing name from to comedi01 <-- from static route toNotifyList
Message Sets
Message Type
Fields
Description
Addressed
Direct Message Message.name=clock01 Message is addressed to a specific instance name
Operator
NonAddressed
Message will follow class broadcast and static routes
Class
Broadcast Class Message Message.class=org.osros.hardware.Operator Message is sent to all instances of the same type
NonClassed
Message will follow static routes or direct address
Category
Arbitrary broadcast to a Category of services Message.category=leftLegServices
A way to group service message broadcasts
Static
Message will follow static route to next destination
A static route message is very similiar to an addressed message - in fact from the recievers point of view they are indistinguishable
NonStatic
Message will follow direct address or typed
Method
Message has method - Invoked Dispatched or Sent Directly?
No Method
Data only? Valid?
Questions to resolve :
can a non-Operator deliver an addressed local Message? - YES
can a non-Operator deliver an addressed remote Message? - NO
can a non-Operator deliver a local Broadcast Class message? - NO
can an Operator deliver local messages in a static way only? - TBD - an example of use would be Remote->Operator->Authentication->Service where all messages need to funnel through one component
can a notifyList of an Operator contain remote services besides other Operators? - TBD - if the idea is to be seamless then - yes
