red flag

[varhub]

Slow down this development please. A minimal audit of this repo/umbrella reveals several drawbacks, so it is better to paralize it.

[varhub]

Leaving apart censured drawback list, let me ask a new question:

Why JdeRobot (core) is being infected by teaching's artifacts like gazebo models and worlds? These ones are portable, not compilable and just injected through env var or copy to home.

Are everyone satisfied by current approach?

[fqez]

Hi,

not all models and worlds are intended to be in teaching robotics suite. Besides I think is more easy for the new students/collaborators to have all the resources located in one place, it's also menat to be installed with the core in order to execute the exercises section proposed in jderobot.org At least that's what I think.

Do you have a better proposal to organize the projects? :D

Cheers!

[varhub]

I think that you already know the alternative. By the way, if no one complains about it and they feel happy it's better avoid open their eyes.

PS: note for the future: say nothing means support it.

[jmplaza]

Censored drawback list? AFAIK there is not such a thing. If I am wrong, please, just upload again whatever comments you have or drawbacks you envisage about the code. They are welcome, but don't expect everybody to agree with your point of view :-), neither expect that your proposals always fit the criteria of most of the experienced JdeRobot developers. Some of your proposals will and others, will not.

I'm comfortable with current approach on TeachingRobotics (TR). Most of the gazebo models and worlds used in TR are uploaded to JdeRobot repository in order to be available to other people just using them without downloading or using TR at all. TR will always depend on JdeRobot, but not the other way around. The rule of thumb is that only specific stuff should be kept in TR repository. If something is amenable to be used outside TR, the criteria is to put in JdeRobot repository, which is the general infrastructure package. For instance Formula1 car model or circuit.

Right now in our way to the TR 1.0 release, many exercises are mature enough, others are still under development and there are some odd things still pending of refinement. Seven drone exercises have been successfully used so far by more than 25 students. Other exercise is being used in the drone challenge coming soon, with no complains. And we are now under development of three new exercises: visual control (follow_line directory), local robot navigation and global robot navigation (teleTaxi directory).

[varhub]

Hum.., nowadays I do not remember it pretty well, at least this means that they were not critical. What I remember:

• CPack (see #1). Unrequired noise and overload. Current instructions requires a cp to $HOME. No difference with wget except additional hierarchy reorganization.
• Git history lost; and even worse, component version lost.
• introrob taken from JdeRobot before appy latest PRs.
• GitHub's fork and remix workflow for practices is broken and unfeasible (I almost forgot this one)
• ¿?

New ones:

• Twenty million copies of introrob_py. Hoping same core. And yes, maintain it.
• Gazebo assets related:
  • Several copies of same assets (meshes, models).
  • New/testing/unstable models/worlds reaching stable 'infrastructure' when others had been deleted

Am I the only stupid that thinks that develop every model/world into a single directory at TeachingRobotics and make a script to install it to $HOME (yes, without sudo!) is just easy?

NOTICE that since git history lost is the way to go at now, use TR as sandbox for mature models and worlds and eventually copy them to JdeRobot in a clean way does not seems too rare.