Closed knorth55 closed 7 years ago
My suggestion is
I prefer this dir tree construction, because it makes it easier to change directory like below:
start-jsk/jsk_apc/jsk_arc2017/common $ cd ../b<tab>
start-jsk/jsk_apc/jsk_arc2017/common $ cd ../baxter
start-jsk/jsk_apc/jsk_arc2017/baxter $ cd ../c<tab>
start-jsk/jsk_apc/jsk_arc2017/baxter $ cd ../common
start-jsk/jsk_apc/jsk_arc2017/common $
, OR we must do like below:
start-jsk/jsk_apc/jsk_arc2017_common $ cd ../jsk_arc2017_b<tab>
start-jsk/jsk_apc/jsk_arc2017_common $ cd ../jsk_arc2017_baxter
start-jsk/jsk_apc/jsk_arc2017_baxter $ cd ../jsk_arc2017_c<tab>
start-jsk/jsk_apc/jsk_arc2017_baxter $ cd ../jsk_arc2017_common
start-jsk/jsk_apc/jsk_arc2017_common $
My idea is
package names and dir
jsk_arc2017(or jsk_arc2017_robot?)/jsk_arc2017_baxter
jsk_arc2017_common
@pazeshun what is your idea?
cc. @k-okada
I think
are simplest and best.
just follow current package design,
jsk_2015_05_baxter_apc
jsk_2016_01_baxter_apc
jsk_apc2015_common
jsk_apc2016_common
so, I
jsk_2015_05_baxter_apc
jsk_2016_01_baxter_apc
jsk_2017_03_baxter_apc
jsk_apc2015_common
jsk_apc2016_common
jsk_apc2017_common
might be better, jsk_year_month_robot_project is jsk_demos style ( https://github.com/jsk-ros-pkg/jsk_demos) this also tell us we're 2 month behind compare to 2016.
-- ◉ Kei Okada
2017-03-17 11:25 GMT+09:00 Shun Hasegawa notifications@github.com:
I think
- start-jsk/jsk_apc/jsk_arc2017_baxter
- start-jsk/jsk_apc/jsk_arc2017_common are simplest and best.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/start-jsk/jsk_apc/issues/2027#issuecomment-287249352, or mute the thread https://github.com/notifications/unsubscribe-auth/AAeG3C8x447xYBfL1BV3jnoMqi1ACadwks5rme8XgaJpZM4MgFDy .
might be better, jsk_year_month_robot_project is jsk_demos style
What do you think about software updates? I think month is meaningless because software will be totally different from the one at the time of package creation.
this also tell us we're 2 month behind compare to 2016.
Is this important information?
@knorth55 @pazeshun Please try digging directory for apc year. If I dig jsk_arc2017
for common
and baxter
, I can focus on creating programs for 2017 without being interrupted like following.
$ cd ../jsk_<tab>
jsk_2015_05_baxter_apc jsk_2016_01_baxter_apc jsk_apc2015_common jsk_apc2016_common jsk_apc2017_common
$ cd ../jsk_apc20<tab>
jsk_apc2015_common jsk_apc2016_common jsk_apc2017_common
$ cd ../jsk_apc201<tab>
jsk_apc2015_common jsk_apc2016_common jsk_apc2017_common
$ cd ../jsk_apc2017<tab>
$ cd ../jsk_apc2017_common
Please try digging directory for apc year. If I dig jsk_arc2017 for common and baxter, I can focus on creating programs for 2017 without being interrupted like following.
In my understanting, ROS packages should be directly under jsk_apc
repository.
I tottaly support @pazeshun's idea. I think jsk_arc2017/common is weird. jsk_arc2017_common is better.
For baxter-specified package, i support @pazeshun's idea to remove month.
It seem not so weird considering similar kind of directory segmentation in moveit: https://github.com/ros-planning/moveit/tree/kinetic-devel/moveit_ros and "ROS packages should be directly under jsk_apc repository" is also a JSK-style: https://github.com/ros/ros_comm
The pros of creating jsk_arc2017/ are
cons are
I'm not sure what is the merit of non-segmented directory construction.
i think moveit dir tree is not good (actually i hate that) because it is difficult to find out where the specific source code is.
it is a cons of deep directory tree and short name of directory.
it should be not so long but also be not too short.
jsk~~~/common
is too short, i think.
So.. a possibility is
start-jsk/jsk_apc/arc2017/jsk_arc2017_common
start-jsk/jsk_apc/arc2017/jsk_arc2017_baxter
or
start-jsk/jsk_apc/2017/jsk_arc2017_common
start-jsk/jsk_apc/2017/jsk_arc2017_baxter
?
jsk~~~/common is too short, i think.
You mean you'd like to make package name and directory one same, right?
One idea is creating
at this time, and if it is too painful to use for me, I will try changing it with directory segmentation.
Agreed? @k-okada @knorth55 @pazeshun
my idea is
start-jsk/jsk_apc/jsk_arc2017_common
start-jsk/jsk_apc/jsk_arc2017_baxter
or
start-jsk/jsk_apc/jsk_arc2017/jsk_arc2017_common
start-jsk/jsk_apc/jsk_arc2017/jsk_arc2017_baxter
Agree? @k-okada @knorth55 @pazeshun
agreed
agreed
I think we can start this year with
start-jsk/jsk_apc/jsk_arc2017_common
start-jsk/jsk_apc/jsk_arc2017_baxter
BTW,
For example, given the setup below, C-x C-r C-f will find a package or file using rospack.
http://wiki.ros.org/rosemacs#Overview ? also vim plugins for roscd http://wiki.ros.org/IDEs#Vim? ROS/roscd provides non-hierarchical directory structure, so basically "depth" of the directory should be become a problem.Below is just a memo, please read 2 years later.
I feel like we're almost back to original directory structure https://github.com/amazon-picking-challenge/jsk_picking_challenge,
So, my expectation is this will going to start-jsk/jsk_apc/jsk_arc2018/{common,baxter}
and start-jsk/jsk_apc/jsk_arc2019
.
if common is vision part and baxter is manipulation or apc task part, common should merged into jsk_recognition and we only needs jsk_arc2017_baxter. This is the demo program for baxter robot and can be placed within jsk_demos, so we'll use jsk_demos/jsk_2019_10_arc
name for that. The original name of jsk_apc
is 2014-semi
and at that time, we (including me) are not get used to github so we need playground
for the project. Now we'll use github from 3rd year and 2016-semi
is no longer directory but a one PR on jsk_demos https://github.com/jsk-ros-pkg/jsk_demos/pull/1209 .
Do we need common and baxter package? is it a basically vision vs manipulation?
Do we need common and baxter package?
I'd like to use the "common" package for projects without using baxter robot. (for example hrp2_apc last year)
Is it a basically vision vs manipulation
I don't think so, because we have some visualization/evaluation/recognition nodes in "common", and "baxter" only includes robot-specific programs like baxter.launch, baxter-interface.l and baxter.l.
Does emacs users knows For example, given the setup below, C-x C-r C-f will find a package or file using rospack. http://wiki.ros.org/rosemacs#Overview ? also vim plugins for roscd http://wiki.ros.org/IDEs#Vim? ROS/roscd provides non-hierarchical directory structure, so basically "depth" of the directory should be become a problem.
I'm not sure what do you mean. But I can say that rospack/rosvim just depends on the package name written in package.xml, not the name of directory.
[http://baxter:11311][133.11.216.160] wkentaro at sheeta in ~
% roscd jsk_arc2017_common
[http://baxter:11311][133.11.216.160] wkentaro at sheeta in ~/…/src/start-jsk/jsk_apc/jsk_arc2017/common on heads/jsk_arc2017 rosp common
% pwd
/home/wkentaro/Projects/jsk_apc/src/start-jsk/jsk_apc/jsk_arc2017/common
I don't think so, because we have some visualization/evaluation/recognition node in "common", and "baxter" only includes robot-specific programs like baxter.launch, baxter-interface.l and baxter.l.
I see, what you need is something like baxter_jsk_2019_description, and/or baxter_jsk_2019_eus. (this package name is very bad idea, and you do not have to create this this year), and what you need is jsk_arc2019, because ideally if you define task, that program should run all robots. https://github.com/jsk-ros-pkg/jsk_pr2eus/blob/master/pr2eus/robot-interface.l#L1770
I'm not sure what do you mean. But I can tell that rospack/rosvim just depends on the package name written in package.xml, not the name of directory.
I'm talking about https://github.com/start-jsk/jsk_apc/issues/2027#issuecomment-287272928 discussion.
I see, what you need is something like baxter_jsk_2019_description, and/or baxter_jsk_2019_eus. (this package name is very bad idea, and you do not have to create this this year), and what you need is jsk_arc2019, because ideally if you define task, that program should run all robots.
Yeah, ideally, we should create jsk_arc2017 and robot-interface.l
(for robot-specific configuration is defined in baxter-interface.l
or hrp2-interface.l
inheriting robot-interface.l
.
I'm not so particular about the name of jsk_arc2017_baxter
, and I think it can be jsk_arc2017
, jsk_arc2017_demo
, and jsk_arc2017_robot
.
I think you can start with
start-jsk/jsk_apc/jsk_arc2017_common
start-jsk/jsk_apc/jsk_arc2017_baxter
, about jsk_arc2017_robot, that should be supported in jsk_robots in long-term perspective, I'll discuss with @pazeshun
-- ◉ Kei Okada
2017-03-19 8:41 GMT+09:00 Kentaro Wada notifications@github.com:
I'm not so particular about the name of jsk_arc2017_baxter, and I think it can be jsk_arc2017, jsk_arc2017_demo, and jsk_arc2017_robot.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/start-jsk/jsk_apc/issues/2027#issuecomment-287583172, or mute the thread https://github.com/notifications/unsubscribe-auth/AAeG3Cu3QSGYTlM3yF_-Az8iY46h2bK4ks5rnGu5gaJpZM4MgFDy .
Sure.
let's discuss about these topics!
Related to #2026 cc. @wkentaro