wiki:WikiStart/OngoingWork/Syskit/NamingConventions

Naming conventions

Requirements:

  • avoid nameclashes
    • e.g. ObjectDetection::Task, ObjectDetection (A Composition)
    • avoid to find strange renaming schemes
  • how to handle the 'robots' concept as part of naming schema
  • one-to-one mapping between file structure and class/task name naming
  • make the code readable for users
  • make it easy (short enough) for lazy developers

Additional points for discussion

  • ~autoloading of files (avoid automagic loading)~
  • ~introduce file suffix for services, composition~
  • ~where to define services:~
    • bundle/<namespace>
    • automatic generation of providers for simple types
      • ~similarly to controller/ControlledSystem~
      • ~where should what go into~
  • introduce mapping for libraries, e.g. from drives/<type> -> bundles/<type>
  • how to deal with project specific modelling, i.e. how to allow direct integration of modelling on public repositories with optional dependencies
  • editing from syskit browse
  • ~profiles/action libraries~
  • migration path

Usage of compositions

  • composition with only data services
    • abstract model / element of the architecture
  • composition with a single task context -- everything else which is added to the composition is a data service
  • composition with majority of real task contexts (vs. added via services)

Collection of options

namespace/prefix/suffix/none

Variant Task Composition Service
A none none none
B namespace (Task::) namespace (Composition::) namespace (Service::)
C suffix suffix suffix
D none namespace namespace
E namespace none none
  • add related compositions into the same module namespace of the task, e.g.
    • ObjectDetection::Task
      • ObjectDetection::YourComposition
  • Variant F:
    • Tasks::ObjectDetection::Task
    • Compositions::ObjectDetection
    • DataServices::ObjectDetection
  • Variant G:
    • <ROOT:nameOfBundle>::Tasks::ObjectDetection::Task
    • <ROOT:nameOfBundle>::Compositions::ObjectDetection
    • <ROOT:nameOfBundle>::DataServices::ObjectDetection
  • Variant H:
    • 1
      • Tasks::ObjectDetection::Task
        • since they are defined outside of any bundles
      • Compositions::<ROOT:nameOfBundle>::ObjectDetection
      • Services::<ROOT:nameOfBundle>::ObjectDetection
    • 2
      • OroGen::ObjectDetection::Task
        • OroGen::ObjectDetection::Deployments::Test
      • ROS::ObjectDetection::Task
        • ROS::ObjectDetection::Launchers::Test
      • <ROOT:nameOfBundle>::Compositions::ObjectDetection
      • <ROOT:nameOfBundle>::Services::ObjectDetection
  • ruby:
    • global namespace: ::
    • module namespace: module ModuleName
    • task namespace:
      module ModuleName
         class Task
         end
      end
      

Comments

  • Benefits of namespacing
    • autocompletion
      • support for editors
  • Other project: prefix serving as functional marker, suffix describing the type of object, e.g. manipulation_XXX_composition

Robot concept

  • variant 1
    • config/init.rb
    • config/robots/<robot-name>/init.rb
    • config/robots/<robot-name>/requires.rb
    • config/robots/<robot-name>/config.rb
  • variant 2
    • config/robots/<robot-name>.rb containing blocks
        init do
        end
        requires do
        end
        config do
        end
      

Results

  • participants: Malte Wirkus, Steffen Planthaber, Sylvain Joyeux, Thomas Roehr
  • Variant H 2 has been identified as best compromised:
    • OroGen::ObjectDetection::Task
      • OroGen::ObjectDetection::Deployments::Test
    • ROS::ObjectDetection::Task
      • ROS::ObjectDetection::Launchers::Test
    • <ROOT:nameOfBundle>::Compositions::ObjectDetection
    • <ROOT:nameOfBundle>::Services::ObjectDetection
    • <ROOT:nameOfBundle>::Devices::ObjectDetection
  • Additionally naming for profiles and action interfaces:
    • <ROOT:nameOfBundle>::Profiles::ObjectDetection
    • <ROOT:nameOfBundle>::Actions::ObjectDetection
  • get rid of autoloading
  • Robot concept:
    • variant 2
      • config/robots/<robot-name>.rb containing blocks
          init do
          end
          requires do
          end
          config do
          end
        
  • renaming DataServices to Services
  • Folders:
    • models/orogen
    • models/ros
    • models/compositions
    • models/services
    • models/actions
    • models/profiles
    • models/devices

  • specializations
    # in bundles/rock/models/compositions/control_loop.rb
    class ControlLoop < Syskit::Composition
    end
    
    # in bundles/rock/models/compositions/specializations/trajectory_follower.rb
    require 'models/compositions/control_loop'
    Rock::Compositions::ControlLoop.specialize 'controller' => TrajectoryFollower::Task do
    end
    
    # bundles/rock_auv/models/services/auv_6dcontrol.rb
    Rock::Compositions::ControlLoop.declare_standard_control_services '/auv_control/Cmd6D'
    # bundles/rock_auv/models/compositions/specializations/auv_6dcontrol.rb
    Rock::Compositions::ControlLoop.declare_standard_control_loop_specializations '/auv_control/Cmd6D'
    
  • robot-specific models
    • 1
      • models/profiles/manipulation/dual_arm.rb
      • models/artemis/profiles/manipulation/dual_arm.rb
    • 2
      • models/profiles/manipulation/dual_arm.rb
      • models/profiles/artemis/manipulation/dual_arm.rb
    • 3: BAD, the main file (manipulation.rb does NOT load the subfolder's contents which goes contrary to customs)
      • models/profiles/manipulation/dual_arm.rb
      • models/profiles/manipulation/artemis/dual_arm.rb
    • 4: BAD, the main file (manipulation/dual_arm.rb does NOT load the subfolder's contents which goes contrary to customs)
      • models/profiles/manipulation/dual_arm.rb
      • models/profiles/manipulation/dual_arm/artemis.rb
    • 5
      • models/profiles/manipulation/dual_arm/common.rb
      • models/profiles/manipulation/dual_arm/artemis.rb

Example: action interface

# actions/artemis.rb

# should only load profiles/manipulation.rb which loads content from profiles/manipulation/... --> common loading practice
require 'profiles/manipulation' 

# loads 'profiles/manipulation' and specialization in 'profiles/artemis/manipulation.rb' which loads 'profiles/artemis/manipulation/..."
require 'profiles/artemis/manipulation' 

require 'profiles/artemis'
 
require 'actions/artemis/manipulation'


# actions/artemis-simulation.rb

require 'profiles/artemis-simulation/manipulation'

# If you see that you need specific information from the actions/artemis folder in the actions/artemis-simulation folder, that means the action definition should be outside of the <robot>  specific subfolder, i.e.
# bad: require 'actions/artemis/manipulation' --> good: require 'actions/manipulation'

  • deciding for option number 2 as given in the example above
Last modified 5 years ago Last modified on 01/10/14 12:28:53