\documentclass{article}
\usepackage{enumitem,amssymb}
\usepackage{lipsum} % for filler text
\usepackage{fancyhdr}
\pagestyle{fancy}

\newlist{todolist}{itemize}{2}
\setlist[todolist]{label=$\square$}
\usepackage{easylist}
\fancyfoot{} % clear all footer fields
\fancyfoot[LE,RO]{\thepage}           % page number in "outer" position of footer line
\fancyfoot[RE,LO]{Version VERSIONNUMBER} % other info in "inner" position of footer line


\begin{document}
	
{\huge \textbf{Zen Robotics Pentatholon}}

\vspace{1cm}


\vspace{1cm}

{\huge \textbf{Purpose}}
\vspace{1cm}

The purpose of this Pentatholon is to encourage students to become good engineers. A good engineer is defined as someone who builds systems that accomplish tasks with accessible designs, give and receive aid among peers, and competes to push forward the edge of the known possible. In short, we intend to inject hope into the world through inspiring feats of engineering.

Accessible designs means that the designs, tools and components are accessible to all competitors, and non competitors equally. Designs and code should be housed in public facing Git repository. Tools should be free and open source to all people. The intent is to prevent enclosure of students skills by companies.  Components should be generic commodity components or be manufactured with open licenses for multi-vendor sourcing.  

To give and receive aid means that you use the tools and sources of others and assume that the tools and code you create will be used by others. This means being a responsible user of open source code. You should also be a responsible creator of open source code and documentation. The aid you receive, and the aid you give, should be  balanced. 

To push forward the edge of the known possible means that we compete against physics, not against each other nor against the rules. The purpose of the rules is to ensure recognition of collaboration and an even playing field. Since there can be as many winners as there are teams that accomplish the task, there is no motivation to compete against another team of students. We want to see designs and software that can accomplish tasks, and to see how different folks choose and remix designs to push forward. 

  
This pentathlon is designed to foster a connection to these principles for each student. The intent of the rules and scoring structure is to encourage collaboration across teams, and across the world. Students compete against the course, not against each other. Each teams accomplishments are intended to be acknowledged on their own merits. We are all competing together against the edge of the known possible.
\pagebreak


{\huge \textbf{Justification of Decisions}}
\vspace{1cm}

This competition was inspired as an act of schismogenesis in response to FIRST and Vex competitions. The competition structure, team-on-team competition and my-win-requires-your-loss aspects are the motivations for a change. There are elements that are desirable, such as team collaboration, across-team collaboration and high school engineering. 

Why Linux as the runtime? 
\begin{enumerate}
\item We want to encourage full-scale compute hardware as the runtime for robot programs. 

\item We want to see tight integration of Control Code, Robot Kinematics, Robot CAD and Robot Simulation. 

\item We want to see fully open source designs that can be composites of many repositories, with runtime self-bootstrapping on new systems. 

\item We want to have students able to open up the robot in an Integrated Robotics Development Environment. 

\item We want to encourage a distributed architecture of compute and edge devices. 

\end{enumerate}
\pagebreak


{\huge \textbf{Overview}}
\vspace{1cm}

\textbf{Competition description:} The pentathlon will consist of a standard obstacle course in 5 stages, through which a robot will traverse. Robots will be constrained by the design and construction rules below. Obstacles will be added as needed to the end of the course to ensure balanced difficulty. Early sections of the course will be stable for an extended period of time. 
\begin{enumerate}
\item Stage one is a performance to hype up and interact with the crowd.

\item Stage two is the first stage of obstacle course. 

\item Stage three is the midpoint performance.

\item Stage four is the last portion of obstacle course. 

\item Stage five is the final performance and celebration. 
\end{enumerate}

Students will compete in independent categories for recognition awards. These awards will have a grading rubric and top teams will have the ability to get an award based on their individual contributions. Multiple awards are possible in any category. Likewise if no team in a competition scores high enough, the award will not be awarded to the highest point scorer. 

\begin{enumerate}
	
\item Distance through the course
 
\item Time of completion
 
\item Mechanical design contribution
 
\item Code contribution
 
 \item Build quality, adornment and animation
 
 \item Documentation award for writing and improving documentation
 
 \item Toolmaker award for making tools used in the creation of robots
 
\end{enumerate}

 At the end of the course will be a button, which the robot must press to have completed the course. The time through the course is measured and compared for the completion time award. Separate awards will be given for each robot to accomplish the course. If no robot accomplishes the whole course, then the robots will be scored solely on total distance through the course. 
 
 An award for contribution to code will be given to the team that contributes a code contribution that affects the control of the robot and accomplishes some aspect of the challenge, and is well documented and easily accessible for other teams.
 
 An award for build quality, adornment and animation will be given for the care given to the aesthetics of the robot and especially the attention paid to human robot interaction. Robots that are perceived well and interact well with judges will be eligible for this award. 
 
  Teams that share source early, and over multiple years, will be eligible for the two design awards. Teams will provide authorship of all code submitted, and will need to describe the functionality of each piece of code contributed by other teams. Each team awards percentages of their own contributions and the contributions of other competitors. The percentages are totaled, like a ranked choice vote, to assign the winner of this years global design awards. 
  
  Documentation awards recognize creation or improvement of the documentation of either a mechanical, code or tool contribution. Teams can take an existing  submission, improve its documentation, and submit the improved stack as their submission. This documentation award recognizes the value of increasing accessibility of an existing design. 
  
  Toolmaker awards are for the contribution of an IDE, CAD package, simulation package, assembly jig or any other hardware or software that is used for the creation of the robot, but is not in use at competition time. To be a tool, the contribution must not be active or in use during a competition run. If a contribution is active during a run, it would be considered either a mechanical or code design contribution. 
 
 \pagebreak
 
{\huge \textbf{Definitions}}
\begin{enumerate}
	\item \textbf{Open Source:} When all of the files used to create an application or design are available.
	\item \textbf{Vitamins:} components generally available, preferable with multiple sources. A specific list will be provided with standard pricing.
	\item \textbf{Save-point:} A point in the course where your robot is expected to perform an animation for the crowd.  
\end{enumerate}

  \pagebreak
{\huge \textbf{Rules}}

\begin{enumerate}
	
\item \textbf{Composition Of Robot:} A robot that competes in the competition must be composed of FFF printed parts made on an approved printer in an approved material with sources provided, Vitamins from the approved list with BoM provided. Using the posted price list, all vitamins in a submitted robot must not exceed \$500, or from a drag-knife cutter using paper, hardboard or cloth. 

\item \textbf{Open Source Requirement:} All of the sources for the design elements of the robot, the robots control code, all dependent libraries, and all software tools used must be open source at the time of competition. 

\item \textbf{Program execution:} Robots must communicate to the competition station using the provided protocol. A robots competition code is run by the judges based on the Git URl and tag associated with the competition. 


\item \textbf{Performance:} Before proceeding into the obstacle course, the robot will be judged on a 90 second animation intended to hype up the crowd. At each save-point through the course another 90 second animation will be required. 

\item \textbf{Eligibility:} High school and Jr High school students affiliated with public schools or not-for-profit private schools. Pay-to-play organizations are explicitly forbidden, all students must be able to join teams without a per student cost borne by the students or their families. 


\item \textbf{Team Composition:} Teams can be 1-6 students. Each team member registers an email address with the team submission for automatic contribution allocation. Teams must have at least one adult coach to register for events. Teams may consist of students from any eligible organization and need not all be from a single organization.  

 
\item \textbf{Attribution} Everything submitted for competition must be attributed accurately. This includes the students code. Big blocks of changes copy and pasted into a students repository will be flagged as a potential attribution violation. If work is done collaboratively then the email of each student that contributed must be included in the commit message. Work done by, or modified by, an ML model may not be claimed as a contribution of the student, and must be attributed to the model that created or modified it. (Note that according to the open source tools rule, only open weight ML models may be used)




\end{enumerate}

 \pagebreak

{\huge \textbf{Competition structure}}

The competition will be held over the same weekend by all teams wishing to compete. 

Teams will register with the completion central ranking server and may submit early if they so choose. Early submissions with novel open source elements may be picked up by other teams, increasing the likelihood the team that posts early gets recognition for one of the design contributions awards.

Each submission team must include an attribution document in the root of the software submission. This document will show clearly what aspect of the submission were done by the students on the team, and what elements were done by current competitors, and what portions are generic open source contributions. When a student submits a contribution it can be used by other teams and must be attributed. When a student graduates, or is not registered as a competitor in the competition year, their contributions are considered generic open source contributions thereafter.  Attribution documents must be in the specified format to be machine readable for scoring purposes. 

Tool attribution is a separate document in the top level of the students submission repository. Tool attribution follows the rules for code contributions, but must document exactly which tools are used in the creation of each element of the robot. Every tool used by the students in planning, design, CAD and programming must be listed. Use of a tool must be attributed even if the tool's output is converted to another format and modified further. For instance, if a model is designed in OpenSCAD, then exported into Blender for aesthetic modification, both tools must be listed, even if the Blender file is the final version submitted. Using a closed-source tool in a pipeline of otherwise open source tools is not permitted. 

In the root of the students submission must be a BoM file that contains each and every vitamin used in the robot. The BoM must have the reference location of that vitamin in the approved vitamins list (Type and Size), its location within the robot, and unique name. No vitamins may be used unless they are in the approved vitamins list. Competitors may submit requests to add new vitamins via a Pull Request to the approved vitamins list with dual sourcing information, sizes and a parametric model in the BowlerStudio format. 

Each student, and their associated contributions, are associated to one and only one email address. This email address identifies the student with their contributions. It is very important that the Git Repository involved are configured to use the students email for each commit. 

All submissions from a student registered on a team apply to the entire team. If a team works collaboratively on contributions, but has a single "author" in the Git Repository, that is OK. Awards and contributions are applied to whole teams. 

All teams that compete in the code portion must have at least one hardware submission. Multiple code teams may use a single hardware entry. A code entry may be used on more than one hardware entry. 

Hardware only teams may compete for the design award. They must demonstrate that the design works with an existing software release, or that they have developed and released a working software stack by performing well in the obstacle course. 

Performance only teams may compete so long as the animations and costume can be demonstrated to still work within the obstacle course. 

All teams that wish to compete for top prizes must compete over the competition weekend. All robots source must be posted and tagged by the provided time, on the day before competition. 

Competition consists of the judges running the tagged code against the student provided robot, connected to the judges station's network. The judge will run the tagged code in a standard execution environment. Students code must work as a self contained system, or bootstrap components as they are needed. Judges station will have access to the internet during practice run to ensure bootstrapping. Student downloads are limited to 8gb of total used disk space. The student provided software will have a competition.sh file that will perform then entire task of animation, course navigation and stopping at the end to press the button. Animation audio will play through the station computer. 

Each team in the competition must perform some portion of the obstacle course to be counted for judging. All runs of the course are recorded for the instant runoff judging. Judging for objective measures such ad distance and time will be judged instantly. Performance and design contribution judging will be performed over the following weeks. Finalists will be invited to submit a new animation for second round judging at a central event. The finalists will be judged and awarded at that time. 



 \pagebreak

{\huge \textbf{Software}}

\textbf{Competition Runtime:} The competition runtime is a Linux computer. Student code will consist of a launcher script that performs the entire course without further human interaction. The competition runtime computer will be Ubuntu LTS on x86\_64 processor with 32gb of ram. The competition station will be connected to a WiFi station. The robot will be connected to the same WiFi station.  

\textbf{Libraries:} Code and design libraries can be kept as BowlerStudio Groovy scripts, or they my be distributed on Maven. Teams are expected to provide authorship of all libraries used within a submission. 

\textbf{Design tools:} IDE's, CAD packages, Simulation tools, project planning and any other necessary piece of software used in the process of planning, design, or production of a submission must also be open source. BowlerStudio, FreeCAD, Blender, OpenSCAD, Inkscape are examples of CAD design tools that would be acceptable. Web based tools do not count.  


\vspace{1cm}

 \pagebreak

{\huge \textbf{Judging}}

\textbf{Distance through the course:} The judging for distance through the course will be measured as a distance from the start line to the point on the robot closest to the start line. If the robot splits into multiple pieces (intentionally or otherwise) the piece that is closest to the starting line will be measured. Any part that falls off during competition will mark the furthest point that can be judged for distance.  
 	
\textbf{Time of completion:} Time through the obstacle portion will be timed. The performance time, since it is required to take a fixed amount of time, do not count towards completion time. Time for the 2 sections of obstacle course will be measured separately.  
 	
 \textbf{Mechanical design contribution:} Attribution documents will be used to determine the contributions for the mechanical design award. All the competitors submissions will act as a student-led vote for this award. The judges will assess the existence of the  attribution documents and arbitrate any challenges to the distributions percentages. The judges will not qualitatively evaluate this award, instead it is voted on using the attribution documents. 
 	
\textbf{Code contribution:} Attribution documents will be used to determine the contributions for the code award. All the competitors submissions will act as a student-led vote for this award. The judges will assess the existence of the  attribution documents and arbitrate any challenges to the distributions percentages. The judges will not qualitatively evaluate this award, instead it is voted on using the attribution documents. 
 	
\textbf{Build quality, adornment and animation:} This award will be judged qualitatively by the judges at each competition event site. A scoring rubric will be used to establish fair judging standards. The site competition winners will be featured on the main competition website for the following year. 
 	
\textbf{Documentation award for writing and improving documentation:} Attribution documents will be used to determine the contributions for the aesthetics award. All the competitors submissions will act as a student-led vote for this award. The judges will assess the existence of the  attribution documents and arbitrate any challenges to the distributions percentages. The judges will not qualitatively evaluate this award, instead it is voted on using the attribution documents. 
 	
\textbf{Toolmaker award for making tools used in the creation of robots:} Attribution documents will be used to determine the contributions for the toolmaker design award. All the competitors submissions will act as a student-led vote for this award. The judges will assess the existence of the  attribution documents and arbitrate any challenges to the distributions percentages. The judges will not qualitatively evaluate this award, instead it is voted on using the attribution documents. 

\textbf{Voting} Competitor voting will be allocated as percentages of the total, summed together. Each team has one submission for each: code, mechanical and tools. The total of the percentage allocation must sum to exactly 1. Fractional allocations must have no more than 3 significant figures. Voting will be run algorithmically on the day of competition after all the teams get judging sign off of the accuracy and completeness of the documents. 

 	
\textbf{Championship} Each event's qualitative judging will award 3, unranked, winners. The winners of the qualitative judging will be offered to compete in a championship competition event following the general competition weekend. The championship event must be held in the city where Zen Robotics originated, Worcester MA. Championship will award 3 ranked winners. 



\vspace{1cm}
 
 

\end{document}
