A robotics software development framework for Node.js.
Sensors, Controllers, Actuators - SCA.
Information flows: sensors -> controllers -> actuators
Debugging flows the other way: actuators -> controllers -> sensors
Therefore we tie the controllers to the actuators.
is there a way to automate the creation of components based on them being in the proper directories?
Create a new ribbon project:
Creates directory structure:
* app * actuators * controllers * sensors * config * doc * lib * log * test * actuators * controllers * sensors
Adds /package.json with dependencies:
Install vows globally to get vows command working? Or mask it behind a ribbon command?
npm install vows -g
Generate actuators, controllers, sensors and custom objects.
$ ribbon generate Usage: ribbon generate GENERATOR [args] [options] ... Please choose a generator below. Ribbon: actuator controller sensor generator ...
Generate a solenoid
$ ribbon generate solenoid BrakeDrum creates: * app/actuators/brake.drum.js * test/actuators/brake.drum.test.js
about inheritance and 'as' function. the thought is 'as' has a nice prototype ring to it. for example, i can use an LED object as a protoype for a solenoid. actuating the solenoid is a lot like blinking a LED. so, we use Led as a Solenoid: Led.as(Solenoid);.
Sensors are Emitters.
Controllers are Listeners.
Sensors communicate with Controllers via Events.
Controllers contain Actuators and acuate them via function calls.
MVC versus SCA
In an MVC framework like Ruby on Rails there is one model, one view and one controller for each class. For example a model for people would look like
/controllers/people_controller.rb /models/person.rb /views/people/edit.html.haml /views/people/index.html.haml /views/people/new.html.haml /views/people/show.html.haml
Ribbons tries to realize some of the benefits of predictable file naming conventions and locations so that as projects grow and the teams that work on them evolve it's easier to be productive.
view -- controller -- model >-< models
Ribbons uses a model of Sensors, Controllers and Actuators. While this is helpful there isn't a 1:1:1 relationships among the components. In fact, it's often interesting to have many sensors impacting the same actuator. And likewise it's common to have multiple actuators impacted by one sensor. So, what do we do? Controllers are defined by the many sensors and actuators they control.
sensors >-< sensors >- controller -< actuator >-< actuator