search

start-jsk / jsk_apc

Other
36 stars 35 forks source link

ARC2017 package #2027

Closed knorth55 closed 7 years ago

knorth55 commented 7 years ago

let's discuss about these topics!

Related to #2026 cc. @wkentaro

wkentaro commented 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 $
knorth55 commented 7 years ago

My idea is

@pazeshun what is your idea?

cc. @k-okada

pazeshun commented 7 years ago

I think

are simplest and best.

k-okada commented 7 years ago

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 .

pazeshun commented 7 years ago

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?

wkentaro commented 7 years ago

@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
pazeshun commented 7 years ago

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.

knorth55 commented 7 years ago

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.

wkentaro commented 7 years ago

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.

knorth55 commented 7 years ago

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.

wkentaro commented 7 years ago

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

?

wkentaro commented 7 years ago

jsk~~~/common is too short, i think.

You mean you'd like to make package name and directory one same, right?

wkentaro commented 7 years ago

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

knorth55 commented 7 years ago

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
knorth55 commented 7 years ago

Agree? @k-okada @knorth55 @pazeshun

agreed

pazeshun commented 7 years ago

agreed

k-okada commented 7 years ago

I think we can start this year with

start-jsk/jsk_apc/jsk_arc2017_common
start-jsk/jsk_apc/jsk_arc2017_baxter

BTW,

Below is just a memo, please read 2 years later.

  1. 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.

  2. 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 .

wkentaro commented 7 years ago

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
k-okada commented 7 years ago

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.

wkentaro commented 7 years ago

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.

wkentaro commented 7 years ago

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.

k-okada commented 7 years ago

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 .

wkentaro commented 7 years ago

Sure.