Menu
▾
▴
orca-robotics-devel
|
From: Tobias K. <t....@ac...> - 2004-07-01 07:51:36
Attachments:
GUI_project_description.pdf
|
Guys, Alex B. and I wrote up the attached proposal for Alex M.s suggestion of an XML generating GUI. Let us know what you think. ----------------------------------------------- Tobias Kaupp ARC Centre of Excellence for Autonomous Systems (Australian Centre for Field Robotics) The Rose St Building, J04 The University of Sydney, NSW 2006 Australia Phone: +61 2 9351 7154 Fax: +61 2 9351 7474 Email: t....@ca... Web: www.acfr.usyd.edu.au ----------------------------------------------- |
|
From: David K. <100...@st...> - 2018-01-05 19:41:58
|
http://chapter.timsales.us David Kennedy |
|
From: Tim A. <ta...@en...> - 2004-07-01 08:18:46
|
It looks pretty good to me. One thing I'm not sure of though, in creating a component library is a machine's local orca component repository searched and/or is the naming/trading service queried? Given that, when a system is composed would the user specify the component's host (if its configuration was found locally) or is it already known (from the naming/trading service)? Or is it irrelevant because the gui wouldn't consider specific instances of components, so you would hook up to any you find, irrespective of the host? Does this make any sense? Cheers, Tim Tobias Kaupp wrote: > Guys, > > Alex B. and I wrote up the attached proposal for Alex M.s suggestion of an > XML generating GUI. Let us know what you think. > > ----------------------------------------------- > Tobias Kaupp > > ARC Centre of Excellence for Autonomous Systems > (Australian Centre for Field Robotics) > The Rose St Building, J04 > The University of Sydney, NSW 2006 > Australia > > Phone: +61 2 9351 7154 > Fax: +61 2 9351 7474 > Email: t....@ca... > Web: www.acfr.usyd.edu.au > ----------------------------------------------- > > ------------------------------------------------------------------------ > Name: GUI_project_description.pdf > GUI_project_description.pdf Type: Portable Document Format (application/pdf) > Encoding: base64 > Download Status: Not downloaded with message |
|
From: Tim A. <ta...@en...> - 2004-07-01 08:43:27
|
Guys, I just had a chat with Jaime over a couple of points. Do we want to lay down which gui libraries to use? Should we stick with Qt for platform independence, or something similar? Also, while it doesn't really matter to anyone using the gui software, but internally I imagine the author is going to have to come up with a means of saving the system design (as a .orca file?). Whether this should be a part of the specification, or just common sense, I don't know. Tim Tobias Kaupp wrote: > Guys, > > Alex B. and I wrote up the attached proposal for Alex M.s suggestion of an > XML generating GUI. Let us know what you think. > > ----------------------------------------------- > Tobias Kaupp > > ARC Centre of Excellence for Autonomous Systems > (Australian Centre for Field Robotics) > The Rose St Building, J04 > The University of Sydney, NSW 2006 > Australia > > Phone: +61 2 9351 7154 > Fax: +61 2 9351 7474 > Email: t....@ca... > Web: www.acfr.usyd.edu.au > ----------------------------------------------- > > ------------------------------------------------------------------------ > Name: GUI_project_description.pdf > GUI_project_description.pdf Type: Portable Document Format (application/pdf) > Encoding: base64 > Download Status: Not downloaded with message |
|
From: Jaime V. M. <jai...@en...> - 2004-07-01 08:52:59
|
one further point. I think it would be a good idea to try and limit the number of different languages Orca is made of. We already have a myriad of them, namely idl, xml, cpp ... Maybe for the component library we should try and stick (as suggested) to XML, unless some limitation of the language specification I am not aware of at this stage. My take is that things are already complicated enough, and some time in the future we're gonna ask people to develop their stuff in the orca framework. So making it simple and not asking them to learn more stuff than strictly necessary should be a design mantra. My two cents. Jaime Tim Arney wrote: > Guys, > > I just had a chat with Jaime over a couple of points. Do we want to lay down which gui > libraries to use? Should we stick with Qt for platform independence, or something similar? > Also, while it doesn't really matter to anyone using the gui software, but internally I > imagine the author is going to have to come up with a means of saving the system design (as a > .orca file?). Whether this should be a part of the specification, or just common sense, I > don't know. > > Tim > > Tobias Kaupp wrote: > > > Guys, > > > > Alex B. and I wrote up the attached proposal for Alex M.s suggestion of an > > XML generating GUI. Let us know what you think. > > > > ----------------------------------------------- > > Tobias Kaupp > > > > ARC Centre of Excellence for Autonomous Systems > > (Australian Centre for Field Robotics) > > The Rose St Building, J04 > > The University of Sydney, NSW 2006 > > Australia > > > > Phone: +61 2 9351 7154 > > Fax: +61 2 9351 7474 > > Email: t....@ca... > > Web: www.acfr.usyd.edu.au > > ----------------------------------------------- > > > > ------------------------------------------------------------------------ > > Name: GUI_project_description.pdf > > GUI_project_description.pdf Type: Portable Document Format (application/pdf) > > Encoding: base64 > > Download Status: Not downloaded with message -- Dr Jaime Valls Miro Centre for Autonomous Systems (Room 2/6/31) Faculty of Engineering PO BOX 123, Broadway NSW 2007 p: +61 2 9514 2967 f: +61 2 9514 2655 jaime.vallsmiro[AT]eng.uts.edu.au |
|
From: Alex B. <a.b...@ac...> - 2004-07-01 09:34:12
|
Regarding Jaime's point as well: Toby and I deliberately didn't specify xml vs xxx or Qt vs xxx in the specification. I would recommend Qt and xml to keep to a minimum the number of things Orca has to link against, but we didn't want to mandate anything -- perhaps this guy has an extremely compelling reason for choosing something else. It's his project, after all. Saving the system design should _definately_ be done in xml, matching the way systems are currently described (with xml files). Alex On Thu, 2004-07-01 at 18:45, Tim Arney wrote: > Guys, > > I just had a chat with Jaime over a couple of points. Do we want to lay down which gui > libraries to use? Should we stick with Qt for platform independence, or something similar? > Also, while it doesn't really matter to anyone using the gui software, but internally I > imagine the author is going to have to come up with a means of saving the system design (as a > .orca file?). Whether this should be a part of the specification, or just common sense, I > don't know. > > Tim > > Tobias Kaupp wrote: > > > Guys, > > > > Alex B. and I wrote up the attached proposal for Alex M.s suggestion of an > > XML generating GUI. Let us know what you think. > > > > ----------------------------------------------- > > Tobias Kaupp > > > > ARC Centre of Excellence for Autonomous Systems > > (Australian Centre for Field Robotics) > > The Rose St Building, J04 > > The University of Sydney, NSW 2006 > > Australia > > > > Phone: +61 2 9351 7154 > > Fax: +61 2 9351 7474 > > Email: t....@ca... > > Web: www.acfr.usyd.edu.au > > ----------------------------------------------- > > > > ------------------------------------------------------------------------ > > Name: GUI_project_description.pdf > > GUI_project_description.pdf Type: Portable Document Format (application/pdf) > > Encoding: base64 > > Download Status: Not downloaded with message > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Orca-robotics-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel |
|
From: Tim A. <ta...@en...> - 2004-07-01 09:57:04
|
Alex, I'm not sure if you understood what I meant, but when I said saving a system design I didn't mean generating the xml config files. I mean saving the whole system model, so that you can transport/store a particular system design (as a file) and load it in this gui software. Whether it should be saved as an xml file, or whether the gui software could work backwards and import generated xml files to show the system architecture, I don't know. Tim Quoting Alex Brooks <a.b...@ac...>: > Regarding Jaime's point as well: > > Toby and I deliberately didn't specify xml vs xxx or Qt vs xxx in the > specification. I would recommend Qt and xml to keep to a minimum the > number of things Orca has to link against, but we didn't want to mandate > anything -- perhaps this guy has an extremely compelling reason for > choosing something else. It's his project, after all. > > Saving the system design should _definately_ be done in xml, matching > the way systems are currently described (with xml files). > > Alex > > > On Thu, 2004-07-01 at 18:45, Tim Arney wrote: > > Guys, > > > > I just had a chat with Jaime over a couple of points. Do we want to lay > down which gui > > libraries to use? Should we stick with Qt for platform independence, or > something similar? > > Also, while it doesn't really matter to anyone using the gui software, but > internally I > > imagine the author is going to have to come up with a means of saving the > system design (as a > > .orca file?). Whether this should be a part of the specification, or just > common sense, I > > don't know. > > > > Tim > > > > Tobias Kaupp wrote: > > > > > Guys, > > > > > > Alex B. and I wrote up the attached proposal for Alex M.s suggestion of > an > > > XML generating GUI. Let us know what you think. > > > > > > ----------------------------------------------- > > > Tobias Kaupp > > > > > > ARC Centre of Excellence for Autonomous Systems > > > (Australian Centre for Field Robotics) > > > The Rose St Building, J04 > > > The University of Sydney, NSW 2006 > > > Australia > > > > > > Phone: +61 2 9351 7154 > > > Fax: +61 2 9351 7474 > > > Email: t....@ca... > > > Web: www.acfr.usyd.edu.au > > > ----------------------------------------------- > > > > > > > ------------------------------------------------------------------------ > > > Name: > GUI_project_description.pdf > > > GUI_project_description.pdf Type: Portable Document Format > (application/pdf) > > > Encoding: base64 > > > Download Status: Not downloaded with > message > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by Black Hat Briefings & Training. > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > digital self defense, top technical experts, no vendor pitches, > > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > > Orca-robotics-devel mailing list > > Orc...@li... > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Orca-robotics-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > ---------------------------------------------------------------- UTS CRICOS Provider Code: 00099F |
|
From: <ama...@ma...> - 2004-07-01 11:17:27
|
there're 3 types of files here: 1. orca component description file (.ocd?), which I think we should mandate to be xml. these could reside in the component directories. these are written by the component developer. the format is to be determined but should't be to different from the current config files. 2. orca component configuration file (.occ?), which is definitely xml and the current .xml files. I would imagine moving these out of the global orca/xml directory into the user space like /myproject/*.occ 3. the gui session or project file (simulink calls it 'model'). the format of this is up to the developer, but I'd suggest text and probably xml. as for which gui technology to use, I'd request it to be at least win and linux. as long as we have control over this, I'd also strongly encourage Qt to make it more useful/maintainable in the future. Tim's point of what to use as the source of component information is very intersting: source code or trading service? the source code option is easier but also having something registered with the trading service implies having written the config files -- the process we are trying to automate here. alex m. Quoting Tim Arney <ta...@en...>: > Alex, > > I'm not sure if you understood what I meant, but when I said saving a > system > design I didn't mean generating the xml config files. I mean saving the > whole > system model, so that you can transport/store a particular system design > (as a > file) and load it in this gui software. Whether it should be saved as > an xml > file, or whether the gui software could work backwards and import > generated xml > files to show the system architecture, I don't know. > > Tim > > Quoting Alex Brooks <a.b...@ac...>: > > > Regarding Jaime's point as well: > > > > Toby and I deliberately didn't specify xml vs xxx or Qt vs xxx in the > > specification. I would recommend Qt and xml to keep to a minimum the > > number of things Orca has to link against, but we didn't want to > mandate > > anything -- perhaps this guy has an extremely compelling reason for > > choosing something else. It's his project, after all. > > > > Saving the system design should _definately_ be done in xml, matching > > the way systems are currently described (with xml files). > > > > Alex > > > > > > On Thu, 2004-07-01 at 18:45, Tim Arney wrote: > > > Guys, > > > > > > I just had a chat with Jaime over a couple of points. Do we want to > lay > > down which gui > > > libraries to use? Should we stick with Qt for platform > independence, or > > something similar? > > > Also, while it doesn't really matter to anyone using the gui > software, but > > internally I > > > imagine the author is going to have to come up with a means of > saving the > > system design (as a > > > .orca file?). Whether this should be a part of the specification, > or just > > common sense, I > > > don't know. > > > > > > Tim > > > > > > Tobias Kaupp wrote: > > > > > > > Guys, > > > > > > > > Alex B. and I wrote up the attached proposal for Alex M.s > suggestion of > > an > > > > XML generating GUI. Let us know what you think. > > > > > > > > ----------------------------------------------- > > > > Tobias Kaupp > > > > > > > > ARC Centre of Excellence for Autonomous Systems > > > > (Australian Centre for Field Robotics) > > > > The Rose St Building, J04 > > > > The University of Sydney, NSW 2006 > > > > Australia > > > > > > > > Phone: +61 2 9351 7154 > > > > Fax: +61 2 9351 7474 > > > > Email: t....@ca... > > > > Web: www.acfr.usyd.edu.au > > > > ----------------------------------------------- > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Name: > > GUI_project_description.pdf > > > > GUI_project_description.pdf Type: Portable Document > Format > > (application/pdf) > > > > Encoding: base64 > > > > Download Status: Not downloaded with > > message > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > digital self defense, top technical experts, no vendor pitches, > > > unmatched networking opportunities. Visit www.blackhat.com > > > _______________________________________________ > > > Orca-robotics-devel mailing list > > > Orc...@li... > > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by Black Hat Briefings & Training. > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > digital self defense, top technical experts, no vendor pitches, > > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > > Orca-robotics-devel mailing list > > Orc...@li... > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > ---------------------------------------------------------------- > UTS CRICOS Provider Code: 00099F > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Orca-robotics-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > -- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Alex B. <a.b...@ac...> - 2004-07-01 22:58:27
|
Another option, rather than having three file types, is to do what Tim suggested and have the gui 'work backwards' from the files it generates. That is, essentially use file set number 2 for purpose number 3. This may be a bit more difficult, but reduces the number of file types, reduces the number of places errors and inconsistencies can occur, and lets you 'edit' an existing setup. Alex On Thu, 2004-07-01 at 21:17, ama...@ma... wrote: > there're 3 types of files here: > > 1. orca component description file (.ocd?), which I think we should mandate > to be xml. these could reside in the component directories. these are > written by the component developer. the format is to be determined but > should't be to different from the current config files. > > 2. orca component configuration file (.occ?), which is definitely xml and > the current .xml files. I would imagine moving these out of the global > orca/xml directory into the user space like /myproject/*.occ > > 3. the gui session or project file (simulink calls it 'model'). the format > of this is up to the developer, but I'd suggest text and probably xml. > > as for which gui technology to use, I'd request it to be at least win and > linux. as long as we have control over this, I'd also strongly encourage > Qt to make it more useful/maintainable in the future. > > Tim's point of what to use as the source of component information is very > intersting: source code or trading service? the source code option is > easier but also having something registered with the trading service > implies having written the config files -- the process we are trying to > automate here. > > alex m. > > > Quoting Tim Arney <ta...@en...>: > > > Alex, > > > > I'm not sure if you understood what I meant, but when I said saving a > > system > > design I didn't mean generating the xml config files. I mean saving the > > whole > > system model, so that you can transport/store a particular system design > > (as a > > file) and load it in this gui software. Whether it should be saved as > > an xml > > file, or whether the gui software could work backwards and import > > generated xml > > files to show the system architecture, I don't know. > > > > Tim > > > > Quoting Alex Brooks <a.b...@ac...>: > > > > > Regarding Jaime's point as well: > > > > > > Toby and I deliberately didn't specify xml vs xxx or Qt vs xxx in the > > > specification. I would recommend Qt and xml to keep to a minimum the > > > number of things Orca has to link against, but we didn't want to > > mandate > > > anything -- perhaps this guy has an extremely compelling reason for > > > choosing something else. It's his project, after all. > > > > > > Saving the system design should _definately_ be done in xml, matching > > > the way systems are currently described (with xml files). > > > > > > Alex > > > > > > > > > On Thu, 2004-07-01 at 18:45, Tim Arney wrote: > > > > Guys, > > > > > > > > I just had a chat with Jaime over a couple of points. Do we want to > > lay > > > down which gui > > > > libraries to use? Should we stick with Qt for platform > > independence, or > > > something similar? > > > > Also, while it doesn't really matter to anyone using the gui > > software, but > > > internally I > > > > imagine the author is going to have to come up with a means of > > saving the > > > system design (as a > > > > .orca file?). Whether this should be a part of the specification, > > or just > > > common sense, I > > > > don't know. > > > > > > > > Tim > > > > > > > > Tobias Kaupp wrote: > > > > > > > > > Guys, > > > > > > > > > > Alex B. and I wrote up the attached proposal for Alex M.s > > suggestion of > > > an > > > > > XML generating GUI. Let us know what you think. > > > > > > > > > > ----------------------------------------------- > > > > > Tobias Kaupp > > > > > > > > > > ARC Centre of Excellence for Autonomous Systems > > > > > (Australian Centre for Field Robotics) > > > > > The Rose St Building, J04 > > > > > The University of Sydney, NSW 2006 > > > > > Australia > > > > > > > > > > Phone: +61 2 9351 7154 > > > > > Fax: +61 2 9351 7474 > > > > > Email: t....@ca... > > > > > Web: www.acfr.usyd.edu.au > > > > > ----------------------------------------------- > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > Name: > > > GUI_project_description.pdf > > > > > GUI_project_description.pdf Type: Portable Document > > Format > > > (application/pdf) > > > > > Encoding: base64 > > > > > Download Status: Not downloaded with > > > message > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > digital self defense, top technical experts, no vendor pitches, > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > _______________________________________________ > > > > Orca-robotics-devel mailing list > > > > Orc...@li... > > > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > digital self defense, top technical experts, no vendor pitches, > > > unmatched networking opportunities. Visit www.blackhat.com > > > _______________________________________________ > > > Orca-robotics-devel mailing list > > > Orc...@li... > > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > > > > > ---------------------------------------------------------------- > > UTS CRICOS Provider Code: 00099F > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by Black Hat Briefings & Training. > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > digital self defense, top technical experts, no vendor pitches, > > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > > Orca-robotics-devel mailing list > > Orc...@li... > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > -- > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Orca-robotics-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel |
|
From: <ama...@ma...> - 2004-07-02 10:42:46
|
Quoting Alex Brooks <a.b...@ac...>: > Another option, rather than having three file types, is to do what Tim > suggested and have the gui 'work backwards' from the files it generates. > That is, essentially use file set number 2 for purpose number 3. > agree that the connectivity is encoded in the config files generated, but the graphical information would be lost (eg. where the components were placed on the screen). not a big deal at the first glance but could get annoying quickly because to place them even semi-intelligently on the screen without human input is not trivial. ander's comment on special formats are very interesting. I wonder if Paul has looked into this. alex m. > This may be a bit more difficult, but reduces the number of file types, > reduces the number of places errors and inconsistencies can occur, and > lets you 'edit' an existing setup. > > Alex > > On Thu, 2004-07-01 at 21:17, ama...@ma... wrote: > > there're 3 types of files here: > > > > 1. orca component description file (.ocd?), which I think we should > mandate > > to be xml. these could reside in the component directories. these are > > written by the component developer. the format is to be determined but > > should't be to different from the current config files. > > > > 2. orca component configuration file (.occ?), which is definitely xml > and > > the current .xml files. I would imagine moving these out of the global > > orca/xml directory into the user space like /myproject/*.occ > > > > 3. the gui session or project file (simulink calls it 'model'). the > format > > of this is up to the developer, but I'd suggest text and probably xml. > > > > as for which gui technology to use, I'd request it to be at least win > and > > linux. as long as we have control over this, I'd also strongly > encourage > > Qt to make it more useful/maintainable in the future. > > > > Tim's point of what to use as the source of component information is > very > > intersting: source code or trading service? the source code option is > > easier but also having something registered with the trading service > > implies having written the config files -- the process we are trying > to > > automate here. > > > > alex m. > > > > > > Quoting Tim Arney <ta...@en...>: > > > > > Alex, > > > > > > I'm not sure if you understood what I meant, but when I said saving > a > > > system > > > design I didn't mean generating the xml config files. I mean saving > the > > > whole > > > system model, so that you can transport/store a particular system > design > > > (as a > > > file) and load it in this gui software. Whether it should be saved > as > > > an xml > > > file, or whether the gui software could work backwards and import > > > generated xml > > > files to show the system architecture, I don't know. > > > > > > Tim > > > > > > Quoting Alex Brooks <a.b...@ac...>: > > > > > > > Regarding Jaime's point as well: > > > > > > > > Toby and I deliberately didn't specify xml vs xxx or Qt vs xxx in > the > > > > specification. I would recommend Qt and xml to keep to a minimum > the > > > > number of things Orca has to link against, but we didn't want to > > > mandate > > > > anything -- perhaps this guy has an extremely compelling reason > for > > > > choosing something else. It's his project, after all. > > > > > > > > Saving the system design should _definately_ be done in xml, > matching > > > > the way systems are currently described (with xml files). > > > > > > > > Alex > > > > > > > > > > > > On Thu, 2004-07-01 at 18:45, Tim Arney wrote: > > > > > Guys, > > > > > > > > > > I just had a chat with Jaime over a couple of points. Do we > want to > > > lay > > > > down which gui > > > > > libraries to use? Should we stick with Qt for platform > > > independence, or > > > > something similar? > > > > > Also, while it doesn't really matter to anyone using the gui > > > software, but > > > > internally I > > > > > imagine the author is going to have to come up with a means of > > > saving the > > > > system design (as a > > > > > .orca file?). Whether this should be a part of the > specification, > > > or just > > > > common sense, I > > > > > don't know. > > > > > > > > > > Tim > > > > > > > > > > Tobias Kaupp wrote: > > > > > > > > > > > Guys, > > > > > > > > > > > > Alex B. and I wrote up the attached proposal for Alex M.s > > > suggestion of > > > > an > > > > > > XML generating GUI. Let us know what you think. > > > > > > > > > > > > ----------------------------------------------- > > > > > > Tobias Kaupp > > > > > > > > > > > > ARC Centre of Excellence for Autonomous Systems > > > > > > (Australian Centre for Field Robotics) > > > > > > The Rose St Building, J04 > > > > > > The University of Sydney, NSW 2006 > > > > > > Australia > > > > > > > > > > > > Phone: +61 2 9351 7154 > > > > > > Fax: +61 2 9351 7474 > > > > > > Email: t....@ca... > > > > > > Web: www.acfr.usyd.edu.au > > > > > > ----------------------------------------------- > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > Name: > > > > GUI_project_description.pdf > > > > > > GUI_project_description.pdf Type: Portable > Document > > > Format > > > > (application/pdf) > > > > > > Encoding: base64 > > > > > > Download Status: Not downloaded > with > > > > message > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > > digital self defense, top technical experts, no vendor pitches, > > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > > _______________________________________________ > > > > > Orca-robotics-devel mailing list > > > > > Orc...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > digital self defense, top technical experts, no vendor pitches, > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > _______________________________________________ > > > > Orca-robotics-devel mailing list > > > > Orc...@li... > > > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > > > > > > > > > ---------------------------------------------------------------- > > > UTS CRICOS Provider Code: 00099F > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > digital self defense, top technical experts, no vendor pitches, > > > unmatched networking opportunities. Visit www.blackhat.com > > > _______________________________________________ > > > Orca-robotics-devel mailing list > > > Orc...@li... > > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > > > > > -- > > > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by Black Hat Briefings & Training. > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > digital self defense, top technical experts, no vendor pitches, > > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > > Orca-robotics-devel mailing list > > Orc...@li... > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Orca-robotics-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > -- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Anders <or...@na...> - 2004-07-02 01:30:41
|
I have to mention that there is a language/file-format especially created for modelling/descriptions of systems, namely XMI. XMI (XML Metadata Interchange) is an OMG standard which is closely coupled to UML. E.g. the program Umbrello (http://uml.sf.net) uses it. So XMI should definitely be considered for no 3. Then there is something called MOF (Meta Object Facility) which I don't know much about, but I suspect it could be used for no 1. Regarding the source of component information, it could get arbitrarily complex. In the (far?) future we may start using the Property Service, Interface Repository, and the Implementation Repository. But I suggest to start in the easiest possible way which is probably the config files. (Sorry about the name-dropping;-) ./Anders On Thursday 01 July 2004 11:17, ama...@ma... wrote: > there're 3 types of files here: > > 1. orca component description file (.ocd?), which I think we should mandate > to be xml. these could reside in the component directories. these are > written by the component developer. the format is to be determined but > should't be to different from the current config files. > > 2. orca component configuration file (.occ?), which is definitely xml and > the current .xml files. I would imagine moving these out of the global > orca/xml directory into the user space like /myproject/*.occ > > 3. the gui session or project file (simulink calls it 'model'). the format > of this is up to the developer, but I'd suggest text and probably xml. > > as for which gui technology to use, I'd request it to be at least win and > linux. as long as we have control over this, I'd also strongly encourage > Qt to make it more useful/maintainable in the future. > > Tim's point of what to use as the source of component information is very > intersting: source code or trading service? the source code option is > easier but also having something registered with the trading service > implies having written the config files -- the process we are trying to > automate here. > > alex m. |
|
From: <ama...@ma...> - 2004-07-02 12:56:10
|
lost the original email but wanted to add to the thread on time stamps in OrcaObject. agree with anders that having multiple ones may help in debugging. Player has 3 (they make it available on the level of each device proxy): 1. timestamp (data was generated by the device) 2. senttime (left the server) 3. receivedime (arrived at the client) alex m. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Tim A. <ta...@en...> - 2004-07-02 16:42:49
|
Out of interest, to determine latencies are we assuming that the clocks used to generate these send and receive timestamps are synchronised (manually?), or is this one of those topics not yet explored? Tim Quoting ama...@ma...: > lost the original email but wanted to add to the thread on time stamps in > OrcaObject. > > agree with anders that having multiple ones may help in debugging. > > Player has 3 (they make it available on the level of each device proxy): > 1. timestamp (data was generated by the device) > 2. senttime (left the server) > 3. receivedime (arrived at the client) > > alex m. > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Orca-robotics-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > ---------------------------------------------------------------- UTS CRICOS Provider Code: 00099F |
|
From: Tim A. <ta...@en...> - 2004-07-02 16:55:37
|
Though I suppose latencies could be determined by doing such things as sending objects round trip, and then a common clock is used... Quoting Tim Arney <ta...@en...>: > Out of interest, to determine latencies are we assuming that the clocks used > to > generate these send and receive timestamps are synchronised (manually?), or > is > this one of those topics not yet explored? > > Tim > > > Quoting ama...@ma...: > > > lost the original email but wanted to add to the thread on time stamps in > > OrcaObject. > > > > agree with anders that having multiple ones may help in debugging. > > > > Player has 3 (they make it available on the level of each device proxy): > > 1. timestamp (data was generated by the device) > > 2. senttime (left the server) > > 3. receivedime (arrived at the client) > > > > alex m. > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by Black Hat Briefings & Training. > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > digital self defense, top technical experts, no vendor pitches, > > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > > Orca-robotics-devel mailing list > > Orc...@li... > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > ---------------------------------------------------------------- > UTS CRICOS Provider Code: 00099F > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Orca-robotics-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > ---------------------------------------------------------------- UTS CRICOS Provider Code: 00099F |
|
From: <ama...@ma...> - 2004-07-02 17:01:46
|
Quoting Tim Arney <ta...@en...>: > Though I suppose latencies could be determined by doing such things as > sending > objects round trip, and then a common clock is used... > for testing purposes, query is the simplest because it uses the same clock. to measure one way latencies you could send 1000 objects one way, log times on both clocks, then send 1000 objects the other way, then find average of 2000 time differences (half of them will probably be negative). for distributed data fusion we'll need time synch anyway. how to do it remains to be determined. > > Quoting Tim Arney <ta...@en...>: > > > Out of interest, to determine latencies are we assuming that the > clocks used > > to > > generate these send and receive timestamps are synchronised > (manually?), or > > is > > this one of those topics not yet explored? > > > > Tim > > > > > > Quoting ama...@ma...: > > > > > lost the original email but wanted to add to the thread on time > stamps in > > > OrcaObject. > > > > > > agree with anders that having multiple ones may help in debugging. > > > > > > Player has 3 (they make it available on the level of each device > proxy): > > > 1. timestamp (data was generated by the device) > > > 2. senttime (left the server) > > > 3. receivedime (arrived at the client) > > > > > > alex m. > > > > > > ---------------------------------------------------------------- > > > This message was sent using IMP, the Internet Messaging Program. > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > digital self defense, top technical experts, no vendor pitches, > > > unmatched networking opportunities. Visit www.blackhat.com > > > _______________________________________________ > > > Orca-robotics-devel mailing list > > > Orc...@li... > > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > > > > > ---------------------------------------------------------------- > > UTS CRICOS Provider Code: 00099F > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by Black Hat Briefings & Training. > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > digital self defense, top technical experts, no vendor pitches, > > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > > Orca-robotics-devel mailing list > > Orc...@li... > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > ---------------------------------------------------------------- > UTS CRICOS Provider Code: 00099F > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Orca-robotics-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > -- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: <ama...@ma...> - 2004-07-01 11:22:49
|
sorry for a separate post, the point about UML output is very good. at the risk of being to prescriptive I'd even request the on-screen display to be in UML instead of some made up notation. alex m. Quoting Tim Arney <ta...@en...>: > Alex, > > I'm not sure if you understood what I meant, but when I said saving a > system > design I didn't mean generating the xml config files. I mean saving the > whole > system model, so that you can transport/store a particular system design > (as a > file) and load it in this gui software. Whether it should be saved as > an xml > file, or whether the gui software could work backwards and import > generated xml > files to show the system architecture, I don't know. > > Tim > > Quoting Alex Brooks <a.b...@ac...>: > > > Regarding Jaime's point as well: > > > > Toby and I deliberately didn't specify xml vs xxx or Qt vs xxx in the > > specification. I would recommend Qt and xml to keep to a minimum the > > number of things Orca has to link against, but we didn't want to > mandate > > anything -- perhaps this guy has an extremely compelling reason for > > choosing something else. It's his project, after all. > > > > Saving the system design should _definately_ be done in xml, matching > > the way systems are currently described (with xml files). > > > > Alex > > > > > > On Thu, 2004-07-01 at 18:45, Tim Arney wrote: > > > Guys, > > > > > > I just had a chat with Jaime over a couple of points. Do we want to > lay > > down which gui > > > libraries to use? Should we stick with Qt for platform > independence, or > > something similar? > > > Also, while it doesn't really matter to anyone using the gui > software, but > > internally I > > > imagine the author is going to have to come up with a means of > saving the > > system design (as a > > > .orca file?). Whether this should be a part of the specification, > or just > > common sense, I > > > don't know. > > > > > > Tim > > > > > > Tobias Kaupp wrote: > > > > > > > Guys, > > > > > > > > Alex B. and I wrote up the attached proposal for Alex M.s > suggestion of > > an > > > > XML generating GUI. Let us know what you think. > > > > > > > > ----------------------------------------------- > > > > Tobias Kaupp > > > > > > > > ARC Centre of Excellence for Autonomous Systems > > > > (Australian Centre for Field Robotics) > > > > The Rose St Building, J04 > > > > The University of Sydney, NSW 2006 > > > > Australia > > > > > > > > Phone: +61 2 9351 7154 > > > > Fax: +61 2 9351 7474 > > > > Email: t....@ca... > > > > Web: www.acfr.usyd.edu.au > > > > ----------------------------------------------- > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Name: > > GUI_project_description.pdf > > > > GUI_project_description.pdf Type: Portable Document > Format > > (application/pdf) > > > > Encoding: base64 > > > > Download Status: Not downloaded with > > message > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > digital self defense, top technical experts, no vendor pitches, > > > unmatched networking opportunities. Visit www.blackhat.com > > > _______________________________________________ > > > Orca-robotics-devel mailing list > > > Orc...@li... > > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by Black Hat Briefings & Training. > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > digital self defense, top technical experts, no vendor pitches, > > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > > Orca-robotics-devel mailing list > > Orc...@li... > > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > > > > > ---------------------------------------------------------------- > UTS CRICOS Provider Code: 00099F > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Orca-robotics-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel > -- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X