Open diegocardozo97 opened 4 years ago
I've been thinking about this subject, and I propose the following changes:
Add RB_ as a prefix to all the packages defined/developed by us. For example: _mainengine -> _RB_mainengine
Move the parser from action_selectors to main_engine, as I believe (and I think @diegocardozo97 agrees with me), the parser is more involved with the action manager than with the stt.
Rename the following packages: -action_selectors -> RB_speech_to_text
Include @IquiBalamHM 's code in RB_vision (#35)
What do you guys think?
Hi! I agree with Paul to just add the "rb" prefix (or maybe change it to a more specific one like roborregos, robert_, etc), just taking into account the package convention of having it lowercase and with a significant, distinguishing characteristic.
- if a package is specialized for a software project, prepend its name
- if a package is specialized for a hardware piece, prepend its name
- if a package is specialized for a robot, prepend its name
- if a package is specialized by an entity (lab, company, ...), prepend the name of the entity. Once the package is commonly used, owned and maintained, that name can be dropped
You should check it out, because there is also a section for special cases such as launch files packages and bring-up files, which is exactly what I navigation is trying to implement and we'll have to implement in the future.
Thats amazing, thanks for the info! So I guess the rb (robert) is decided then? What do you think about the other changes?
That info, Aurora, is very nice, I didn't know it. I think something like rbrobert or rbhome is good. Additionally, I was wondering that if in the future with too many packages, we should start using like java's convention for the packages' name.
For example,
catkin_home
|--->src
|--->rb
| |--->home
| | |--->move
| | | |--->pid
| | | | |--->~actual package (rb_home_move_pid)~
| | | |--->state
| | | |--->~actual package (rb_home_move_state)~
| | |--->mainengine
| | |--->voice
| | | |--->~actual package (rb_home_mainengine_voice)~
| | |--->state
| | |--->~actual package (rb_home_mainengine_state)~
| |--->vsss
| |--->vision
| |--->colortracking
| |--->~actual package (rb_vsss_vision_colortracking)~
|--->third_party
|--->vizbox
|--->~actual package (vizbox)~
Then, by including the path in the package name, we can avoid collisions of the packages, for example move's state and mainengine's state. Maybe is too much, but is an option. I say that ROS was made originally for research purpose, that's why is too bad for actual code.
All right, I think I like Cardozo's idea to go with the prefix
Did I miss something? We should add a small page to the wiki regarding this issue and update our own folder areas.
Rules & style proposal: https://docs.google.com/document/d/1N8xFicfTHTpQcqkreHXX42Bds1BwUN9iJZjaGxtYXlQ/edit#
Will this be a thing?
@AuroTB @paulvazbad friendly ping
@AuroTB @paulvazbad
To achieve a better organization and to even allow externals easily use our ROS packages without having to change names, define and implement a new packages' name convention.
I think is fine having that convention and you (navigation, with this PR) can start doing it like that. About the mentioned problem, I think could be later resolved with a new pkg name and path standard like:
catkin_home/src/robo/athome/navigation/a_pkg
->package(robo_athome_navigation_apkg)
.Originally posted by @diegocardozo97 in https://github.com/RoBorregos/Robocup-Home/pull/25#issuecomment-615487710