From ros-users-bounces@code.ros.org Mon Apr 16 08:20:45 2012 Return-Path: X-Original-To: www-data@code.ros.org Delivered-To: www-data@code.ros.org Received: from pub5.willowgarage.com (localhost [127.0.0.1]) by pub5.willowgarage.com (Postfix) with ESMTP id CA7DB25C1BF; Mon, 16 Apr 2012 08:20:45 -0700 (PDT) X-Original-To: ros-users@code.ros.org Delivered-To: ros-users@code.ros.org Received: from esg256-2.itc.swri.edu (esg256-2.itc.swri.edu [129.162.243.101]) by pub5.willowgarage.com (Postfix) with ESMTPS id 1156B25C199 for ; Mon, 16 Apr 2012 08:20:43 -0700 (PDT) Received: from exchmail.swri.org (casht256-1.adm.swri.edu [129.162.243.120]) by esg256-2.itc.swri.edu (8.14.4/8.14.4) with ESMTP id q3GFKgxB012841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 16 Apr 2012 10:20:42 -0500 Received: from ADSMS02.dyn.datasys.swri.edu (129.162.104.29) by casht256-1.adm.swri.edu (129.162.243.105) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 16 Apr 2012 10:20:20 -0500 Received: from ADSMS02.dyn.datasys.swri.edu ([fe80::bcce:9407:39b8:98da]) by ADSMS02.dyn.datasys.swri.edu ([fe80::bcce:9407:39b8:98da%14]) with mapi id 14.02.0283.003; Mon, 16 Apr 2012 10:20:42 -0500 From: "Edwards, Shaun M." To: User discussions Thread-Topic: [ros-users] Enterprise Version of ROS Thread-Index: Ac0YWW5Wuzug1eSnSHuVZS8OI1EcSABv3k6AAFWCHaAADVTNAAAKpiuAAA7nl4AACeiU8A== Date: Mon, 16 Apr 2012 15:20:41 +0000 Message-ID: References: <1334374253.1862.277.camel@kia.secret.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.162.110.75] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-16_03:2012-04-16, 2012-04-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_policy_spam_rewrite_notspam policy=inbound_policy_spam_rewrite score=0 spamscore=0 ipscore=0 suspectscore=7 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=-960 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1204160156 Subject: Re: [ros-users] Enterprise Version of ROS X-BeenThere: ros-users@code.ros.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: User discussions List-Id: User discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0373656965028159939==" Sender: ros-users-bounces@code.ros.org Errors-To: ros-users-bounces@code.ros.org --===============0373656965028159939== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_D0DD76995BDBEA49A40F667B60AE5BFC1EB51AADSMS02dyndatasys_" --_000_D0DD76995BDBEA49A40F667B60AE5BFC1EB51AADSMS02dyndatasys_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kartik, Based on our customers, which I admit is probably a very narrow viewpoint, = there would be no need for backwards compatibility. Our customers aren't i= nterested in the latest and greatest. What's more important is that the ve= rsion that they are using is robust and reliable. In practice this might r= esult in porting critical bug fixes back to "certified" versions for those = customers that need it, but I would hope these would be few and far between= . I wouldn't want to limit ROS development by imposing backwards compatibilit= y requirements. As ROS and associated libraries become more mature we coul= d then impose backwards compatibility requirements. I think what you point out is certifying versions of ROS will require signi= ficant amounts of testing development effort. The hope would be that the t= esting software component would not have to be reworked every time we decid= e to created a certified version of ROS, thereby imposing some sort of back= wards compatibility requirement. There is certainly a balancing act that w= e as a community need to maintain so that we can have certified versions of= ROS with commercial acceptance as well as freedom to change and develop RO= S as needed to meet research objectives. Shaun Edwards Senior Research Engineer Manufacturing System Department http://robotics.swri.org http://rosindustrial.swri.org/ http://ros.swri.org Southwest Research Institute 210-522-3277 From: ros-users-bounces@code.ros.org [mailto:ros-users-bounces@code.ros.org= ] On Behalf Of Kartik Babu Sent: Monday, April 16, 2012 9:53 AM To: User discussions Subject: Re: [ros-users] Enterprise Version of ROS Aside from maximizing the MTBF to meet industrial standards, the pace at wh= ich API either change or deprecated is also another topic to address. There is also the issue of dependence on other libraries for important func= tionality, (OpenCV, PCL etc.). OpenCV seems fairly stable, but PCL like ROS= is still 'settling in'. How would we reconcile the need for new 'certified versions' to be backward= s compatible with older certified releases, and the need to incorporate ne= w, cutting edge packages so that ROS can grow as a whole? K 2012/4/16 Adolfo Rodr=EDguez Tsouroukdissian > On Mon, Apr 16, 2012 at 4:40 AM, Jonathan Bohren > wrote: On Sun, Apr 15, 2012 at 9:31 PM, Edwards, Shaun M. > wrote: I agree that hardware drivers are a good place to start. However, I think = the sooner we can certify ROS core (communications, node handling, etc..), = the better. I know this is the first question I get asked by someone unfamiliar with RO= S when I mention it. This is an especially important focus here at Hopkins = where so many research systems are being developed for applications with hi= gh-cost-of-failure like robotic surgery, deep sea exploration, and on-orbit= telerobotics. I see two very valid and mostly orthogonal use cases so far. 1. Ensuring that certain core ROS functionalities comply with some (3rd-par= ty certified) criteria, so that people that deal with high-cost-of-failure = or safety-critical systems can trust what they are using. 2. Ensuring that a certain piece of hardware/software is ROS-compatible, so= that people that venture into using them can expect compliance with specif= ied ROS interfaces (no surprises attached). I see great value in both, but to clarify, my initial answer to this thread= was oriented mostly towards 1. Adolfo. -j -- Jonathan Bohren PhD Student Dynamical Systems and Control Laboratory Laboratory for Computational Sensing and Robotics The Johns Hopkins University (707) 520-4736 jbo@jhu.edu _______________________________________________ ros-users mailing list ros-users@code.ros.org https://code.ros.org/mailman/listinfo/ros-users -- Adolfo Rodr=EDguez Tsouroukdissian Robotics engineer adolfo.rodriguez@pal-robotics.com http://www.pal-robotics.com PAL ROBOTICS S.L c/ Pujades 77-79, 4=BA4=AA 08005 Barcelona, Spain. Tel. +34.93.414.53.47 Fax.+34.93.209.11.09 AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden c= ontener informaci=F3n privilegiada y/o confidencial que est=E1 dirigida exc= lusivamente a su destinatario. Si usted recibe este mensaje y no es el dest= inatario indicado, o el empleado encargado de su entrega a dicha persona, p= or favor, notif=EDquelo inmediatamente y remita el mensaje original a la di= recci=F3n de correo electr=F3nico indicada. Cualquier copia, uso o distribu= ci=F3n no autorizados de esta comunicaci=F3n queda estrictamente prohibida. CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may co= ntain confidential information which is privileged and intended only for th= e individual or entity to whom they are addressed. If you are not the inte= nded recipient, you are hereby notified that any disclosure, copying, distr= ibution or use of this e-mail and/or accompanying document(s) is strictly p= rohibited. If you have received this e-mail in error, please immediately n= otify the sender at the above e-mail address. _______________________________________________ ros-users mailing list ros-users@code.ros.org https://code.ros.org/mailman/listinfo/ros-users --_000_D0DD76995BDBEA49A40F667B60AE5BFC1EB51AADSMS02dyndatasys_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Kartik,=

 <= /p>

Based on our customers, w= hich I admit is probably a very narrow viewpoint, there would be no need fo= r backwards compatibility.  Our customers aren’t interested in the latest and greatest.  What’s more important is that the = version that they are using is robust and reliable.  In practice this = might result in porting critical bug fixes back to “certified” = versions for those customers that need it, but I would hope these would be few and far between.

 <= /p>

I wouldn’t want to = limit ROS development by imposing backwards compatibility requirements.&nbs= p; As ROS and associated libraries become more mature we could then impose backwards compatibility requirements.

 <= /p>

I think what you point ou= t is certifying versions of ROS will require significant amounts of testing= development effort.  The hope would be that the testing software component would not have to be reworked every time we decide to c= reated a certified version of ROS, thereby imposing some sort of backwards = compatibility requirement.  There is certainly a balancing act that we= as a community need to maintain so that we can have certified versions of ROS with commercial acceptance as well a= s freedom to change and develop ROS as needed to meet research objectives.<= o:p>

 <= /p>

Shaun Edwards<= /span>

Senior Research Engineer<= o:p>

Manufacturing System Depa= rtment

 <= /p>

 <= /p>

http://robotics.swri.org

http://rosindustrial.swri.org/

http://ros.swri.org

Southwest Research Instit= ute

210-522-3277

 <= /p>

From: ros-user= s-bounces@code.ros.org [mailto:ros-users-bounces@code.ros.org] On Behalf Of Kartik Babu
Sent: Monday, April 16, 2012 9:53 AM
To: User discussions
Subject: Re: [ros-users] Enterprise Version of ROS=

 

Aside from maximizing the MTBF to meet industrial st= andards, the pace at which API either change or deprecated is also another = topic to address. 

 

There is also the issue of dependence on other libra= ries for important functionality, (OpenCV, PCL etc.). OpenCV seems fairly s= table, but PCL like ROS is still 'settling in'.

 

How would we reconcile the need for new 'certified v= ersions' to be backwards compatible with older certified releases, and the = need to  incorporate new, cutting edge packages so that ROS can grow a= s a whole?

 

K

 

2012/4/16 Adolfo Rodr=EDguez Tsouroukdissian <adolfo.= rodriguez@pal-robotics.com>

 

On Mon, Apr 16, 2012 at 4:40 AM, Jonathan Bohren <= ;jonathan.bo= hren@gmail.com> wrote:

On Sun, Apr 15, 2012 at 9:31 PM, Edwards, Shaun M. &= lt;sedwards@swri.org= > wrote:

I agree that hardware drivers are a good place to st= art.  However, I think the sooner we can certify ROS core (communicati= ons, node handling, etc..), the better.  

 

I know this is the first question I get asked by som= eone unfamiliar with ROS when I mention it. This is an especially important= focus here at Hopkins where so many research systems are being developed f= or applications with high-cost-of-failure like robotic surgery, deep sea exploration, and on-orbit telerobotics.


I see two very valid and mostly orthogonal use cases so far.

1. Ensuring that certain core ROS functionalities comply with some (3rd-par= ty certified) criteria, so that people that deal with high-cost-of-failure = or safety-critical systems can trust what they are using.

2. Ensuring that a certain piece of hardware/software is ROS-compatible, so= that people that venture into using them can expect compliance with specif= ied ROS interfaces (no surprises attached).

I see great value in both, but to clarify, my initial answer to this thread= was oriented mostly towards 1.

Adolfo.

 

-j


-- 
Jonathan Bohren

PhD Student=

Dynamical Systems and = Control Laboratory

Laboratory for Computa= tional Sensing and Robotics

The Johns Hopkins Univ= ersity

 

 

 

_____________________= __________________________
ros-users mailing list
ros-users@code.= ros.org
https://code.ros.org/mailman/listinfo/ros-users




--
Adolfo Rodr=EDguez Tsouroukdissian
Robotics engineer
adol= fo.rodriguez@pal-robotics.com
http://www.pal-r= obotics.com

PAL ROBOTICS S.L
c/ Pujades 77-79, 4=BA4=AA
08005 Barcelona, Spain.
Tel. +34.93.414.53= .47
Fax.+34.93.209.11.= 09

AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden c= ontener informaci=F3n privilegiada y/o confidencial que est=E1 dirigida exc= lusivamente a su destinatario. Si usted recibe este mensaje y no es el dest= inatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notif=EDquelo inmediatamente y r= emita el mensaje original a la direcci=F3n de correo electr=F3nico indicada= . Cualquier copia, uso o distribuci=F3n no autorizados de esta comunicaci= =F3n queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s)= may contain confidential information which is privileged and intended only= for the individual or entity to whom they are addressed.  If you are = not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail = and/or accompanying document(s) is strictly prohibited.  If you have r= eceived this e-mail in error, please immediately notify the sender at the a= bove e-mail address.


_______________________________________________
ros-users mailing list
ros-users@code.= ros.org
https://code.ros.org/mailman/listinfo/ros-users

 

--_000_D0DD76995BDBEA49A40F667B60AE5BFC1EB51AADSMS02dyndatasys_-- --===============0373656965028159939== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ros-users mailing list ros-users@code.ros.org https://code.ros.org/mailman/listinfo/ros-users --===============0373656965028159939==--