##Instructions for using the template {#fall-2017-projects-instructions}

1. Make a copy of the template `10_templates` folder and paste it inside `/atoms_85_fall2017_projects`.

2. Rename the folder to the next available integer followed by the short group name. E.g.: `10_templates` becomes `11_first_group_name` for the first group, then `12_second_group_name` for the second, and so forth.

3. Edit the `10-preliminary-design-document-template` file name by substituting `template` with `group-name`

4. Open the preliminary design document and personalize the template to your group.

Note: All groups have got their unique ID number and folders are renamed according to the following table. You are allowed and encouraged to use short names. Please merge from the master. New pull requests conflicting to this table will be rejected.

1. Make a copy of the template `10_templates` folder and paste it inside `/atoms_85_fall2017_projects`.

2. Rename the folder to the next available integer followed by the short group name. E.g.: `10_templates` becomes `11_first_group_name` for the first group, then `12_second_group_name` for the second, and so forth.

3. Edit the `10-preliminary-design-document-template` file name by substituting `template` with `group-name`

4. Open the preliminary design document and personalize the template to your group.

Note: All groups have got their unique ID number and folders are renamed according to the following table. You are allowed and encouraged to use short names. Please merge from the master. New pull requests conflicting to this table will be rejected.

The “Heroes” team is a special task force with the responsibility to make sure that “everything works” and create a smooth experience for the rest of the teams, in terms of developing own projects, integration with other teams and documentation. Apart from that, each of the heroes will also have their own individual quest...

@@ -86,7 +88,7 @@ Since the most common PD in Duckietown is a Raspberry Pi, we can design a USB pl

Problem: The primary problem with this approach is its difficult, especially given the project’s short timeframe. However, we could focus on designing and building a prototype that works that could then be mass produced and implemented for the whole Duckietown sometime in the future.

@@ -304,15 +304,14 @@ To reproduce the results see the [operation manual](#demo-sysid) which includes

For recording the Rosbag, the Duckiebot has to be placed in front of the chessboard at a distance of slightly more than 1 meter in front of the chessboard (~2 duckie tiles), as shown in the image. The heading has to be set iteratively to maximize the time the Duckiebot sees the chessboard.

From last year’s project, the baseline implementation of a pose estimator and a controller were provided to us for further improvement. The prior pose estimator was designed to deliver the pose for a Duckiebot on straight lanes only. If the Duckiebot was in or before a curve and in the middle of the lane, the estimated pose showed an offset **d**, see definition of **d** in figure below. The existing controller worked reasonably on straight lines. Although, due to the inputs from the pose estimator to the controller, the Duckiebot overshot in the curves and crossed the left/right line during or after the curve.

* the Duckiebot stops between 0.10m and 0.16m in front of the center of the red stop line, i.e. $d_x \in \lbrack 0.1m,0.16m\rbrack$, has an error of no more than 0.03m with respect to the center of its lane, i.e. $d_y \in \lbrack-0.03m,0.03m\rbrack$, and that the orientation error is smaller than 0.17rad, i.e. $\theta\in\lbrack-0.17rad,0.17rad\rbrack$ (see Fig. 1.2 for details, all values are with respect to the origin of the Duckiebot’s axle-fixed coordinate frame).

* a lane following controller exists that takes as inputs the distance from desired path $d$ and and the orientation error with respect to the path tangent $\theta$ (see Fig. 1.3 for details).

* a lane following controller exists that takes as inputs the distance from desired path $d$ and and the orientation error with respect to the path tangent $\theta$ (see Fig. 1.3 for details). XXX

<div figure-id="fig:2" figure-caption="Pose of the duckiebot in front of an intersection">

<div figure-id="fig:duckiebot_red_line1" figure-caption="Pose of the duckiebot in front of an intersection">

<img src="duckiebot_red_line.png" style="width: 100%"/>

</div>

<div figure-id="fig:3" figure-caption="Pose of the duckiebot relative to the desired path">

<div figure-id="fig:duckiebot_path1" figure-caption="Pose of the duckiebot relative to the desired path">

<img src="duckiebot_path.png" style="width: 100%"/>

</div>

@@ -96,7 +96,7 @@ The *"intersection_localization"*-node publishes the following topic:

It is estimated that it will take approximately 15ms to estimate the Duckiebot's pose once the camera image is received, hence about 15ms of delay can be expected on the published topics. However, the delay will be compensated for by the *"intersection_navigation"*-node.

<div figure-id="fig:4" figure-caption="Pose of the duckiebot inside a four way intersection">

<div figure-id="fig:bot_in_intersection" figure-caption="Pose of the duckiebot inside a four way intersection">

Additionally we have implemented rigth priority option in order to accelerate the traffic at the intersection. Rigth priority doesn't allow a Duckiebot to drive and as lang as another Duckiebot is standing right to them at an intersection.