OpenRocket wiki - User contributions [en]

Component databases

2013-06-09T23:22:40Z

Soupwizard: /* Introduction */

== Introduction ==

This page is for planning the implementation of component databases in OpenRocket and splitting the implementation into smaller tasks.

Currently in OpenRocket, details about rocket components must be entered by hand every time a rocket is designed. For example, when a body tube is added both the inner diameter, outer diameter, and material need to be specified. However, many of the rocket components generally used are standard commercial items whose design specifications are already know. It would be useful to allow OpenRocket users to, for example, select a body tube by manufacturer and type, and only have to specify the variable dimensions: ie, select an Estes BT-60 tube (which will set the tube dimensions and material), then specify a length of 50 cm.

== OpenRocket Component (.orc) XML File Format ==

XML format for storing component databases: [[Component database XML format]]

== Functionality To Be Built ==

The functionality needed to support the above use case can be broken down into the following:

=== Phase 1 ===

==== OpenRocket Component (ORC) Format ====

An open and extensible standard for specifying all relevant details about rocket components. The obvious choice is an XML format. OpenRocket will need to be able to read and write this format.

The format could also allow non-structural components such as rocket motors, wadding or nomex sheets for recovery device protection, etc - any item that is attached to a rocket.

The initial specification of the XML fields and structure can be generated by looking at the ORK rocket design format for what it stores for parts data.

''Should the component db extension be tied to OpenRocket (ORC)? Ideally the format would be adopted by other software as well... [[User:Plaa|Plaa]] 19:24, 8 October 2011 (UTC)''

==== Import and Export Tools for the OpenRocket Component Format ====

Component data will somehow have to converted into ORC XML files, either by the manufacturers themselves or hobby volunteers. It is unreasonable to expect that manufacturer's staff or hobbyists will have the expertise and time to hand-code component XML files. It is more likely that intermediate spreadsheet files will be created with component data. Therefore, we will need a utility to convert both ways between the ORC XML format and standard comma-separated (CSV) value spreadsheet files.

The import/export utility could be built into the OpenRocket software itself, or could be a separate program.

==== Modifications to OpenRocket Client ====

Changes needed to the OpenRocket application to make use of the component functionality:

* OpenRocket must support reading and writing of ORC XML files.
* Store all component data outside the program code (ie, in ORC XML files).
* Don't allow user to modify or overwrite standard OpenRocket supported part, instead allow user to copy, modify, and store new customized parts.
* When user chooses to add a part to a design, allow user to pick one from the component library, or to create a new part using the existing parts specification UI.

=== Phase 2 ===

=== Online Library of OpenRocket Components ===

A useful feature for OpenRocket users would be an online library of OpenRocket component files, a canonical location for the latest version of component files. This would allow the OpenRocket software to obtain the latest component files via the internet, and provide both a web UI for people to view the library, and a web api to allow software to update or retrieve component info.

In addition to commercial rocket components, the library could store non-commercial components, such as combinations of components that form a larger useful piece. For example, an ejection baffle can be created from 3 smaller components: a tube coupler and 2 thin bulkheads with holes drilled in the in various patterns.

Over time, the rocketry community could build an open library of components and ideas to use in constructing rockets, and indeed entire rocket designs.

For rocket motors, we could obtain curated motor data from thrustcurve.org via their internet API. Would we want to use their data directly (each OpenRocket user's instance reads from thrustcurve.org), or would we pull data and store in the OpenRocket library? (or give the option to do either?). Having the OpenRocket program communicate directly with thrustcurve.org (or for that matter, any data source (estes, etc)) would put additional, possibly unwanted, load on their servers. Also, for OpenRocket users who do not have internet access (or sporadic access), having OpenRocket retrieve all it's component data from the library in ORC format allows those disconnected users to manually update their component files by putting a updated snapshot of the library (via usb stick, or infrequent download) on their machine.

Potential messiness: someone will have to maintain the library. Maybe divide the library between official OpenRocket supported components (data from manufacturers, approved submitters and/or rocketry clubs, etc), and a general open-upload section.

==== Modifications to OpenRocket Client ====

* Allow updating of component files from the OpenRocket component library:
** From an online connection to the library web api
** From a snapshot set of updated ORC files, for users who do not have internet access (for example, out at a launch site).
* Allow creation and uploading of custom components

== Software Design ==

=== Tasks ===

* Design XML format for storing component databases: [[Component database XML format]]
** Write schema for the format

* Implement framework for using standard components
** RocketComponentPreset class?
** loadPreset(PresetComponent) method in RocketComponent?
** Remember what is used as a preset component
** When changing critical variables preset component is cleared (e.g. diameter of body tube), but not when changing others (e.g. length of body tube)

* Implement database for storing standard components
** Maintain user-selectable presets list (user can choose which components are in an easy-to-access presets list)

* Implement methods for reading XML format

* Implement methods for reading CSV format

* Implement GUI for component selection
** Preset dropdown
** Button for opening selection dialog
** Dialog allows selecting which components are displayed in the preset list

* Implement GUI for creating components(?)
** Useful for manufacturers

* How to store the preset info in ORK file? Should the entire preset info be included, or just a digest that is used in case the preset is already loaded and available?

Component databases

2013-06-09T23:22:22Z

Soupwizard:

== Introduction ==

This page is for planning the implementation of component databases in OpenRocket and splitting the implementation into smaller tasks.

Currently in OpenRocket, details about rocket components must be entered by hand every time a rocket is designed. For example, when a body tube is added both the inner diameter, outer diameter, and material need to be specified. However, many of the rocket components generally used are standard commercial items whose design specifications are already know. It would be useful to allow OpenRocket users to, for example, select a body tube by manufacturer and type, and only have to specify the variable dimensions: ie, select an Estes BT-60 tube (which will set the tube dimensions and material), then specify a length of 50 cm.

== OpenRocket Component (.orc) XML File Format

XML format for storing component databases: [[Component database XML format]]

== Functionality To Be Built ==

The functionality needed to support the above use case can be broken down into the following:

=== Phase 1 ===

==== OpenRocket Component (ORC) Format ====

An open and extensible standard for specifying all relevant details about rocket components. The obvious choice is an XML format. OpenRocket will need to be able to read and write this format.

The format could also allow non-structural components such as rocket motors, wadding or nomex sheets for recovery device protection, etc - any item that is attached to a rocket.

The initial specification of the XML fields and structure can be generated by looking at the ORK rocket design format for what it stores for parts data.

''Should the component db extension be tied to OpenRocket (ORC)? Ideally the format would be adopted by other software as well... [[User:Plaa|Plaa]] 19:24, 8 October 2011 (UTC)''

==== Import and Export Tools for the OpenRocket Component Format ====

Component data will somehow have to converted into ORC XML files, either by the manufacturers themselves or hobby volunteers. It is unreasonable to expect that manufacturer's staff or hobbyists will have the expertise and time to hand-code component XML files. It is more likely that intermediate spreadsheet files will be created with component data. Therefore, we will need a utility to convert both ways between the ORC XML format and standard comma-separated (CSV) value spreadsheet files.

The import/export utility could be built into the OpenRocket software itself, or could be a separate program.

==== Modifications to OpenRocket Client ====

Changes needed to the OpenRocket application to make use of the component functionality:

* OpenRocket must support reading and writing of ORC XML files.
* Store all component data outside the program code (ie, in ORC XML files).
* Don't allow user to modify or overwrite standard OpenRocket supported part, instead allow user to copy, modify, and store new customized parts.
* When user chooses to add a part to a design, allow user to pick one from the component library, or to create a new part using the existing parts specification UI.

=== Phase 2 ===

=== Online Library of OpenRocket Components ===

A useful feature for OpenRocket users would be an online library of OpenRocket component files, a canonical location for the latest version of component files. This would allow the OpenRocket software to obtain the latest component files via the internet, and provide both a web UI for people to view the library, and a web api to allow software to update or retrieve component info.

In addition to commercial rocket components, the library could store non-commercial components, such as combinations of components that form a larger useful piece. For example, an ejection baffle can be created from 3 smaller components: a tube coupler and 2 thin bulkheads with holes drilled in the in various patterns.

Over time, the rocketry community could build an open library of components and ideas to use in constructing rockets, and indeed entire rocket designs.

For rocket motors, we could obtain curated motor data from thrustcurve.org via their internet API. Would we want to use their data directly (each OpenRocket user's instance reads from thrustcurve.org), or would we pull data and store in the OpenRocket library? (or give the option to do either?). Having the OpenRocket program communicate directly with thrustcurve.org (or for that matter, any data source (estes, etc)) would put additional, possibly unwanted, load on their servers. Also, for OpenRocket users who do not have internet access (or sporadic access), having OpenRocket retrieve all it's component data from the library in ORC format allows those disconnected users to manually update their component files by putting a updated snapshot of the library (via usb stick, or infrequent download) on their machine.

Potential messiness: someone will have to maintain the library. Maybe divide the library between official OpenRocket supported components (data from manufacturers, approved submitters and/or rocketry clubs, etc), and a general open-upload section.

==== Modifications to OpenRocket Client ====

* Allow updating of component files from the OpenRocket component library:
** From an online connection to the library web api
** From a snapshot set of updated ORC files, for users who do not have internet access (for example, out at a launch site).
* Allow creation and uploading of custom components

== Software Design ==

=== Tasks ===

* Design XML format for storing component databases: [[Component database XML format]]
** Write schema for the format

* Implement framework for using standard components
** RocketComponentPreset class?
** loadPreset(PresetComponent) method in RocketComponent?
** Remember what is used as a preset component
** When changing critical variables preset component is cleared (e.g. diameter of body tube), but not when changing others (e.g. length of body tube)

* Implement database for storing standard components
** Maintain user-selectable presets list (user can choose which components are in an easy-to-access presets list)

* Implement methods for reading XML format

* Implement methods for reading CSV format

* Implement GUI for component selection
** Preset dropdown
** Button for opening selection dialog
** Dialog allows selecting which components are displayed in the preset list

* Implement GUI for creating components(?)
** Useful for manufacturers

* How to store the preset info in ORK file? Should the entire preset info be included, or just a digest that is used in case the preset is already loaded and available?

Component database XML format

2013-06-09T08:53:37Z

Soupwizard:

Design of an XML format for component database.

A serialized database of components is created by reading one or more XML files that contain components.

<OpenRocketComponent> - base container element, surrounds everything

(Manufacturers is not implemented in version 0.1)

<Manufacturers> - list of manufacturers used in this database file
: <Manufacturer id="mfgid"> - definition of a single manufacturer
::: (id must be unique within this file, does not need to be globally unique)
:: <DisplayName> - a short display/common name of the manufacturer
:: <FullName> - the full name of the manufacturer
:: <URL> - Manufacturer URL
:: <LogoURL> - Link to Manufacturer's logo, must be of size xx by yy pixels.
: <Manufacturer>
<Manufacturers>

<Materials> - list of materials used in this database file
: <Material UnitsOfMeasure="{text}">
:: <Name lang=""> {text} </Name>
:: <Density> {float} </Density>
:: <Type> {BULK | SURFACE | LINE} </Type>
: </Material>
</Materials>

* Are materials really needed? For most components the total mass should be known, and the best way to use it is to compute the component density from the mass. This allows the user to modify the component (e.g. shorten a body tube) and the mass changes correspondingly.

<Components>

: < common to all components, inside each of those elements >
:: <Manufacturer> {text} </Manufacturer>
:: <PartNumber> {text} </PartNumber>
:: <Description> {text} </Description>
:: <Material Type="BULK">{text} </Material> [should this be validated against material types listed higher up?]
:: <Mass Unit="kg">0.035892</Mass>
:: <Finish> </Finish>
:: <CG> </CG>
: < /common to all components, inside each of those elements >

: <BodyTube>
:: <InsideDiameter Unit="m">0.0657352</InsideDiameter>
:: <OutsideDiameter Unit="m">0.06604</OutsideDiameter>
:: <WallThickness Unit="m">0.06604</WallThickness>
:: <Length Unit="m">0.36195</Length>
: </BodyTube>

: <BulkHead>
:: <Filled>true</Filled> ?? nonfilled for baffle? or separate item for baffles? hollow plastic bulkheads?
:: <OutsideDiameter Unit="m">0.028701999999999995</OutsideDiameter>
:: <Length Unit="m">0.038099999999999995</Length>
: </BulkHead>

: <CenteringRing>
:: <InsideDiameter Unit="m">0.0187452</InsideDiameter>
:: <OutsideDiameter Unit="m">0.0240792</OutsideDiameter>
:: <Thickness Unit="m">0.003175</Thickness>
:: <Length Unit="m">0.00635</Length>
: </CenteringRing>

: <EngineBlock>
:: <InsideDiameter Unit="m">0.013131799999999999</InsideDiameter>
:: <OutsideDiameter Unit="m">0.017983199999999998</OutsideDiameter>
:: <Thickness Unit="m">0.003175</Thickness>
:: <Length Unit="m">0.003175</Length>
: </EngineBlock>

: <LaunchLug>
:: <InsideDiameter Unit="m">0.0055626</InsideDiameter>
:: <OutsideDiameter Unit="m">0.006096</OutsideDiameter>
:: <Length Unit="m">0.0508</Length>
: </LaunchLug>

: <NoseCone>
:: <Shape>ELLIPSOID</Shape>
:: <ShapeParameter>1.0</ShapeParameter> (???)
:: <Filled>true</Filled>
:: <OutsideDiameter Unit="m">0.06604</OutsideDiameter>
:: <BaseDiameter Unit="m">0.06604</BaseDiameter>
:: <ShoulderDiameter Unit="m">0.064922</ShoulderDiameter>
:: <ShoulderLength Unit="m">0.0381</ShoulderLength>
:: <ShoulderThickness Unit="m">0.003175</ShoulderThickness>
:: <EndCapped>true</EndCapped>
:: <Length Unit="m">0.1016</Length>
:: <Thickness Unit="m">0.003175</Thickness>
: </NoseCone>

: <Parachute>
:: <Diameter Unit="m">0.6095999999999999</Diameter>
:: <DragCoefficient>0.80</DragCoefficient>
:: <Sides>8</Sides>
:: <LineCount>8</LineCount>
:: <LineLength Unit="m">0.7493</LineLength>
:: <RadialDistance>1</RadialDistance>
:: <RadialDirection>15</RadialDirection>
: </Parachute>

: <ShockCord>
:: <Length Unit="cm"> </Length>
: </ShockCord>

: <Streamer>
:: <DragCoefficient>0.80</DragCoefficient>
:: <Length Unit="cm"> </Length>
:: <Width Unit="cm'> </Width>
:: <Area Unit="cm^2"> </Area>
:: <AspectRatio > </AspectRatio>
:: <RadialDistance>1</RadialDistance>
:: <RadialDirection>15</RadialDirection>
: <Streamer>

: <TubeCoupler>
:: <InsideDiameter Unit="m">0.0</InsideDiameter>
:: <OutsideDiameter Unit="m">0.017907</OutsideDiameter>
:: <Thickness Unit="m">0.003175</Thickness> (wall thickness???)
:: <Length Unit="m">0.019049999999999997</Length>
: <TubeCoupler>

: <Transition>
:: <Shape>OGIVE</Shape>
:: <Filled>true</Filled>
:: <ForeOutsideDiameter Unit="m">0.067056</ForeOutsideDiameter>
:: <ForeShoulderDiameter Unit="m">0.064973</ForeShoulderDiameter>
:: <ForeShoulderLength Unit="m">0.0254</ForeShoulderLength>
:: <ForeShoulderThickness Unit="m">0.003175</ForeShoulderThickness>
:: <AftOutsideDiameter Unit="m">0.03175</AftOutsideDiameter>
:: <AftShoulderDiameter Unit="m">0.0</AftShoulderDiameter>
:: <AftShoulderLength Unit="m">0.0</AftShoulderLength>
:: <AftShoulderThickness Unit="m">0.003175</AftShoulderThickness>
:: does EndCapped make sense here? or ForeCapped?
:: <Length Unit="m">0.1524</Length>
:: <Thickness Unit="m">0.003175</Thickness> (wall thickness???)
: </Transition>

</Components>

Common data:

<name> - short name of the part (? - is this necessary, or should it just be labeled by mfg and partno) 
<partno> - Part number / ID 
<description> - longer description of the part 
<manufacturer ref="mfgid"> 
<url> - URL related to the component (? - is this useful)

<diameter> 
<length> 

</Components>

Component database XML format

2013-06-09T08:44:53Z

Soupwizard:

Design of an XML format for component database.

A serialized database of components is created by reading one or more XML files that contain components.

<OpenRocketComponent> - base container element, surrounds everything

(Manufacturers is not implemented in version 0.1)

<Manufacturers> - list of manufacturers used in this database file
: <Manufacturer id="mfgid"> - definition of a single manufacturer
::: (id must be unique within this file, does not need to be globally unique)
:: <DisplayName> - a short display/common name of the manufacturer
:: <FullName> - the full name of the manufacturer
:: <URL> - Manufacturer URL
:: <LogoURL> - Link to Manufacturer's logo, must be of size xx by yy pixels.
: <Manufacturer>
<Manufacturers>

<Materials> - list of materials used in this database file
: <Material UnitsOfMeasure="{text}">
:: <Name lang=""> {text} </Name>
:: <Density> {float} </Density>
:: <Type> {BULK | SURFACE | LINE} </Type>
: </Material>
</Materials>

* Are materials really needed? For most components the total mass should be known, and the best way to use it is to compute the component density from the mass. This allows the user to modify the component (e.g. shorten a body tube) and the mass changes correspondingly.

<Components>

: < common to all components, inside each of those elements >
:: <Manufacturer> {text} </Manufacturer>
:: <PartNumber> {text} </PartNumber>
:: <Description> {text} </Description>
:: <Material Type="BULK">{text} </Material> [should this be validated against material types listed higher up?]
:: <Mass Unit="kg">0.035892</Mass>
:: <Finish> </Finish>
:: <CG> </CG>
: < /common to all components, inside each of those elements >

: <BodyTube>
:: <InsideDiameter Unit="m">0.0657352</InsideDiameter>
:: <OutsideDiameter Unit="m">0.06604</OutsideDiameter>
:: <WallThickness Unit="m">0.06604</WallThickness>
:: <Length Unit="m">0.36195</Length>
: </BodyTube>

: <BulkHead>
:: <Filled>true</Filled> ?? nonfilled for baffle? or separate item for baffles? hollow plastic bulkheads?
:: <OutsideDiameter Unit="m">0.028701999999999995</OutsideDiameter>
:: <Length Unit="m">0.038099999999999995</Length>
: </BulkHead>

: <CenteringRing>
:: <InsideDiameter Unit="m">0.0187452</InsideDiameter>
:: <OutsideDiameter Unit="m">0.0240792</OutsideDiameter>
:: <Thickness Unit="m">0.003175</Thickness>
:: <Length Unit="m">0.00635</Length>
: </CenteringRing>

: <EngineBlock>
:: <InsideDiameter Unit="m">0.013131799999999999</InsideDiameter>
:: <OutsideDiameter Unit="m">0.017983199999999998</OutsideDiameter>
:: <Thickness Unit="m">0.003175</Thickness>
:: <Length Unit="m">0.003175</Length>
: </EngineBlock>

: <LaunchLug>
:: <InsideDiameter Unit="m">0.0055626</InsideDiameter>
:: <OutsideDiameter Unit="m">0.006096</OutsideDiameter>
:: <Length Unit="m">0.0508</Length>
: </LaunchLug>

: <NoseCone>
:: <Shape>ELLIPSOID</Shape>
:: <ShapeParameter>1.0</ShapeParameter> (???)
:: <Filled>true</Filled>
:: <OutsideDiameter Unit="m">0.06604</OutsideDiameter>
:: <BaseDiameter Unit="m">0.06604</BaseDiameter>
:: <ShoulderDiameter Unit="m">0.064922</ShoulderDiameter>
:: <ShoulderLength Unit="m">0.0381</ShoulderLength>
:: <ShoulderThickness Unit="m">0.003175</ShoulderThickness>
:: <EndCapped>true</EndCapped>
:: <Length Unit="m">0.1016</Length>
:: <Thickness Unit="m">0.003175</Thickness>
: </NoseCone>

: <Parachute>
:: <Diameter Unit="m">0.6095999999999999</Diameter>
:: <Sides>8</Sides>
:: <LineCount>8</LineCount>
:: <LineLength Unit="m">0.7493</LineLength>
: </Parachute>

: <Streamer>
:: <Length Unit="cm"> </Length>
:: <Width Unit="cm'> </Width>
:: <Thickness Unit="m">5.08E-5</Thickness>
: <Streamer>

: <TubeCoupler>
:: <InsideDiameter Unit="m">0.0</InsideDiameter>
:: <OutsideDiameter Unit="m">0.017907</OutsideDiameter>
:: <Thickness Unit="m">0.003175</Thickness> (wall thickness???)
:: <Length Unit="m">0.019049999999999997</Length>
: <TubeCoupler>

: <Transition>
:: <Shape>OGIVE</Shape>
:: <Filled>true</Filled>
:: <ForeOutsideDiameter Unit="m">0.067056</ForeOutsideDiameter>
:: <ForeShoulderDiameter Unit="m">0.064973</ForeShoulderDiameter>
:: <ForeShoulderLength Unit="m">0.0254</ForeShoulderLength>
:: <ForeShoulderThickness Unit="m">0.003175</ForeShoulderThickness>
:: <AftOutsideDiameter Unit="m">0.03175</AftOutsideDiameter>
:: <AftShoulderDiameter Unit="m">0.0</AftShoulderDiameter>
:: <AftShoulderLength Unit="m">0.0</AftShoulderLength>
:: <AftShoulderThickness Unit="m">0.003175</AftShoulderThickness>
:: does EndCapped make sense here? or ForeCapped?
:: <Length Unit="m">0.1524</Length>
:: <Thickness Unit="m">0.003175</Thickness> (wall thickness???)
: </Transition>

Common data:

<name> - short name of the part (? - is this necessary, or should it just be labeled by mfg and partno) 
<partno> - Part number / ID 
<description> - longer description of the part 
<manufacturer ref="mfgid"> 
<url> - URL related to the component (? - is this useful)

<diameter> 
<length> 

</Components>

Component database XML format

2013-06-09T08:27:19Z

Soupwizard:

Component database XML format

2013-06-09T08:23:25Z

Soupwizard:

2011-08-28T07:25:14Z

Soupwizard:

== Introduction ==

This page is for planning the implementation of component databases in OpenRocket and splitting the implementation into smaller tasks.

== Use Cases ==

== Software Design ==

=== Tasks ===

* Design XML format for storing component databases: [[Component database XML format]]
** Write schema for the format

* Implement framework for using standard components
** RocketComponentPreset class?
** loadPreset(PresetComponent) method in RocketComponent?
** Remember what is used as a preset component
** When changing critical variables preset component is cleared (e.g. diameter of body tube), but not when changing others (e.g. length of body tube)

* Implement database for storing standard components
** Maintain user-selectable presets list (user can choose which components are in an easy-to-access presets list)

* Implement methods for reading XML format

* Implement methods for reading CSV format

* Implement GUI for component selection
** Preset dropdown
** Button for opening selection dialog
** Dialog allows selecting which components are displayed in the preset list

* Implement GUI for creating components(?)
** Useful for manufacturers

* How to store the preset info in ORK file? Should the entire preset info be included, or just a digest that is used in case the preset is already loaded and available?