combining initialization functions

[brian soe]

There are five public initialization functions in CRobotApp: 1) init 2) initGraphics 3) registerCustomDynamicTypes 4) initMyController 5) setInitialStateForUIAndDynamics

It would be more clear if there was one public virtual initialization function, and one public initialization function which called this virtual initialization function.

1) init() should be renamed as initialize() 2) initGraphics() should be a private function, since it is called by init() 3) registerCustomDynamicTypes() should be combined into initMyController() 4) initMyController() should be the only public virtual function 5) setInitialStateForUIAndDynamics() should be combined into init(). a public function to associate UI points with tasks should called in initMyController().

The vector of UI points vector<SUICtrlPointData> should be part of the database, S_GUI. The chaigluthandler should update these positions of these points, as well as update the graphics (thread 1 - graphics thread - should be the only one with write access to graphics). A CRobotApp public function will update the task goal positions, treating S_GUI.ui_points_ as read only for thread safety. It should be called within stepMySimulation():

if(ctrl_ctr_%5==0){ robot_.computeServo(); }

And ctrl_ctr_ should be renamed simulation_steps_counter_, per google coding convention of not using abbreviations unless they abundantly obvious and widely used, e.g. num for number.

I think these would make a huge difference in making SCL more approachable.

[brian soe]

That should have been: if(ctrl_ctr_%5==0){ robot_.updateUITaskGoals(); }

I'm working on the UI point proposal, and will see how it goes.

[Samir Menon]

1) init() is short and sweet

2) Hmm. Well sometimes there are no graphics, and the user should be allowed to independently all whatever sub-init functions they want.

3) Custom dynamic types could include stuff apart from the controller data structures.

4) Same reason as (2).

(5) I agree about setInitialStateForUIAndDynamics()

• The controller has no idea that a UI exists. So we can't have any UI related stuff in initMyController()

• Yes. I agree. The UI point data should be in the database

• The control counter != simulation steps. We could run the simulation faster than the controller (for instance, in the implausible case when the robot is too complex and the controller is slowing things down).

• ctrl = Control (seems quite obvious). Though I could consider changing ctr to counter.

[Samir Menon]

Please open separate bugs about: (5), the UI point data, and renaming ctr to counter.

[Samir Menon]

See comments above.

[Samir Menon]

Most of this is fixed in the new tutorial apps.