arrow-left

All pages
gitbookPowered by GitBook
1 of 1

Loading...

2.1 Technical Design Report

Each team is required to submit a TDR that describes the team’s design principles and competition priorities. The report should address the rationale for which autonomy challenge tasks have been chosen to attempt and how this competition strategy influenced the design decisions for the hull, propulsion system, control systems, and autonomy system. Teams must follow the TDR instructions provided below. To be eligible for full points, teams must submit their TDR by the deadline found in Section 1.5.

A strong TDR provides a coherent narrative and addresses the elements of the rubric as much as possible, including citing references used. The competition strategy justifies the choices of autonomy challenge tasks and design decisions that trace back to those task choices. The report also identifies which software tools allow the team to accomplish the tasks chosen.

circle-check

Top-Scored Report: Get inspiration from Gdańsk University's first place report from RoboBoat 2025. View the report herearrow-up-right.

The technical design report is worth a total of 200 points. The outline of each content section includes a scoring weight with guidance for scoring considerations that are provided to the judges during evaluations.

hashtag
2.1.1 Deliverable Requirements

The content of the written paper shall include the following sections:

  • Technical Content: ,

The format of the written paper shall adhere to the following guidelines:

  • 6 page limit (excluding References and Appendices)

  • 8.5 x 11 in. page size

  • Margins ≥ 0.8 in.

  • Font: Times New Roman 12pt

Optional Formatting: Teams may choose to follow the two-column format, editorial style for IEEE Conference Proceedings: .

circle-info

RoboNation Tip: It is recommended that papers be peer-reviewed prior to submission. For example, teams can utilize resources at their institution, fellow students, or professional editing services.

Formatting Scoring Metrics (5% of score)

hashtag
2.1.2 Abstract

The abstract is a short summary of the main points in the paper. The abstract should summarize the linkage between overall competition strategy and system architecture, design, and engineering decisions.

hashtag
Abstract Scoring Metrics (10% of score)

hashtag
2.1.3 Acknowledgements

Participating in the competition, as in all research projects, involves leveraging resources and support beyond the efforts of individual team members. This support can take many forms such as technical advice, labor, equipment, facilities, and monetary contributions. Acknowledging those who have supported efforts is important.

hashtag
Acknowledgements Scoring Metrics (5% of score)

hashtag
2.1.4 References

As with any technical publication, original ideas and content not generated by the paper’s authors should be properly cited. The references should follow the .

hashtag
References Scoring Metrics (5% of score)

hashtag
2.1.5 Competition Strategy

The paper must include details on the team’s strategy for the competition, including the plans for approaching the course and how the vehicle design relates to this approach. The course consists of multiple tasks with associated points for accomplished behaviors. The only required task is navigating through the start gates. Teams may choose to attempt the other tasks and complete the tasks in any order. The more tasks a vehicle is designed and engineered to accomplish, the more complex the overall vehicle system will be.

Discuss the team's strategy on trade-offs between system complexity and reliability. For example, teams have a limited number of working hours to prepare for the competition; this time could be spent adding additional capabilities or testing and improving the reliability of an existing capability. As system complexity grows, changes in subsystems can propagate in unmanageable ways when time is limited. Based on history and the system engineering talents of the team, include a description the team’s strategic vision.

hashtag
Competition Strategy Scoring Metrics (25% of score)

hashtag
2.1.6 Design Strategy

Given the strategy for success at the competition and the approach to managing complexity, the paper must include a description of the system design to meet the goals they established for the competition. Justification for design choices should be clear. Discuss how components and subsystems were selected and integrated on the vehicle. For teams that are working with a previously designed vehicle, discuss how the design meets the current competition strategy and any modifications needed at the component, subsystem, and/or integrated system levels. Describe the experience in making both architectural/design decisions and system engineering decisions.

This section should not include detailed component descriptions and/or specifications not of original design.

hashtag
Design Strategy Scoring Metrics (25% of score)

hashtag
2.1.7 Testing Strategy

Testing and experimentation is a crucial step to preparing and innovating a system design that strongly correlates with a competitive performance in the arena. The paper must include the approach to a testing strategy, including various test plans, both physically and in simulation.

Discuss considerations of the time needed to thoroughly test to meet the determined goals and the demands of design and engineering with those of testing and experimentation.

hashtag
Testing Strategy Scoring Metrics (25% of score)

hashtag
2.1.8 Test Plan & Results (Optional Appendix)

Based off the testing approach outlined in the paper, this appendix showcases the test plan that was developed and the detailed results that came out of testing. Teams should present their plans for testing, including algorithm testing in a virtual environment, component testing in a laboratory setting, subsystem testing in a relevant environment, and full system testing in a pseudo-competition environment. Test set up should be included and results presented. Any design modifications or changes in competition strategy as a result of testing should be discussed.

While this appendix is not required, excellence seen in this section can be eligible for a special judges’ award.

The appendix may include detailed documentation covering the following areas:

  • Scope: Objectives and test cases (this may also specify what was not included in tests)

  • Schedule: Start/end dates and deadlines

  • Resource and Tools: Resources and tools needed to conduct tests and assess results

,
  • Optional Appendix: Test Plan & Results

  • Header on every page including team name and page number

  • Submitted in .pdf format

  • Abstract section is included but does not serve the intent of an abstract. The abstract is treated as an introduction and provides no summary of the paper.

    Requirements Not Met

    No abstract is included.

    Discussion of the team’s vision is incoherent; rationale for competition goals is not discussed.

    Requirements Not Met

    No mention of competition goals.

    Provides limited information on the creative aspects of system. Creative design methodology is hypothesized. No evidence to support application of Systems Engineering principles.

    Requirements Not Met

    Creative aspects of design are not described.

    Testing is done to a certain degree. No components and sensors are tested independently. There are no test plans.

    Requirements Not Met

    No mention of testing or connection with the system design.

    Environment: Description of the test environment, configurations, and availability
  • Risk Management: Outline potential risks that could occur throughout testing

  • Results: Detailed outcomes of test cases

  • Strong

    Paper follows page limit, and all formatting guidelines are followed. The document is professionally organized. All required sections are included and easy to identify. All grammar, punctuation, and spelling are correct. The style follows that expected of a scientific paper submitted for publication.

    Requirements Not Met

    Formatting guidelines are not followed and the layout is unorganized.

    Outstanding

    Abstract is engaging, lists the scope of the work, and provides a thorough summary of the paper.

    Strong

    Abstract provides a strong overview of the scope of work and a detailed summary of the paper.

    Average

    An adequate explanation of the scope of work is included with a brief summary of the paper.

    Below Average

    Abstract provides a basic summary of the paper.

    Strong

    Acknowledgements detail supporting personnel and their contributions as well as resources. Sponsors and their contributions are acknowledged.

    Average

    Acknowledgements include a list of supporters and sponsors with little or no detail of the support provided.

    Poor

    Acknowledgements provide a general thank you but do not specify particular contributions.

    Requirements Not Met

    No acknowledgements are included.

    Strong

    Sources include notable technical references including technical papers and articles. Use of the source materials are evident in the TDR. Sources are thoroughly documented. The IEEE citation style is correctly utilized.

    Average

    Sources are adequate and documented correctly with the IEEE citation style is utilized.

    Poor

    Limited sources are documented but there is no adherence to the IEEE citation style.

    Requirements Not Met

    No sources or citations are documented.

    Outstanding

    Detailed description of the team's strategic vision and how the vehicle design compliments their goals. Detailed discussion on trade-off studies between system complexity and reliability during design development process.

    Strong

    The team's goals are clearly evident but not discussed in detail. Trade-off studies evident but lacking details.

    Average

    Brief mention of team’s strategic goals and/or trade-off studies.

    Below Average

    Document hints at a goal for competition and/or trade-off studies.

    Outstanding

    Provides in-depth explanations on design strategy and clearly identifies creative aspects of system. Creative design methodology is justified with required calculation steps and visual aids. Content clearly exhibits a Systems Engineering approach.

    Strong

    Provides explanations on design strategy and identifies creative aspects of system. Creative design methodology is justified with calculation steps and visual aids. Content hints at a Systems Engineering approach.

    Average

    Provides some information on design strategy and creative aspects of system. Creative design methodology is supported with a few calculations. Content could be justified as a Systems Engineering approach.

    Below Average

    Provides little information on design and creative design methodology. Little evidence to support applications of a Systems Engineering approach.

    Outstanding

    Testing approach is presented in great detail, to include test strategy and plans. Component testing, sensor and control systems testing done in accordance with a test plan.

    Strong

    Detailed testing approach, test strategy, and plans. Documentation shows good overview of components, sensors and control system testing.

    Average

    Testing approach is presented with sufficient detail, including mention of test strategy and plans. Documentation shows components, sensors and control system testing.

    Below Average

    Testing approach is presented with little to no detail. No mention of components or sensors testing.

    Abstract
    Acknowledgements
    References
    Competition Strategy
    Design Strategy
    www.ieee.org/conferences/publishing/templates.htmlarrow-up-right
    IEEE Conference Proceedings citation stylearrow-up-right

    Poor

    Poor

    Poor

    Poor

    Testing Strategy