https://www.elcanoproject.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=Tfolsom 2026-04-04T00:11:01Z User contributions MediaWiki 1.32.2 https://www.elcanoproject.org/wiki/index.php?title=Mapping_System&diff=364 2020-08-06T19:45:02Z

<p>Tfolsom: </p> <hr /> <div>The Sensor Hub has a low-definition digital map of its operating area. That map is a directed graph of intersections. The files system on the SD card is organized at the original PC MS-DOS system: file names of up to 8 characters, a dot, and an extension of up to three characters.<br /> <br /> ==Master File==<br /> The master file is named MAP_DEFS.TXT<br /> It may look like this:<br /> <br /> 47.758949, -122.190746, UWB_CAMP.TXT<br /> <br /> 47.6213 , -122.3509 , SEATTCEN.TXT<br /> <br /> 47.662 , -122.115 , MARYMOOE.TXT<br /> <br /> 47.660 , -122.185 , BRIDLETR.TXT<br /> <br /> 47.760854, -122.190033, UWB_SCCR.TXT<br /> <br /> 49, 8, CARLA.TXT<br /> <br /> The first two numbers are the latitude and longitude of the origin of the map file. The third item is the name of the file.<br /> When the robot powers up, it will acquire a GPS fix for its present position. It will find the closest latitude and longitude to its position and load that file.<br /> <br /> ==Local Maps==<br /> <br /> For instance, the first few entries of MARYMOOE.TXT are<br /> <br /> -775855, -78948, 1 , END, END, END, 1, 1, 1, 1<br /> -598367, 16679, 0 , 2 , END, END, 1, 1, 1, 1<br /> -426121, 137882, 3 , 17, 19, END, 1, 1, 1, 1<br /> -345240, 149001, 4 , 18, END, END, 1, 1, 1, 1<br /> -216431, 154561, 18, 15, 5, END, 1, 1, 1, 1<br /> -34449, 174576, 4 , 6 , 14, END, 1, 1, 1, 1<br /> 89118, 116792, 5 , 7 , 13, END, 1, 1, 1, 1<br /> 148281, 165680, 6 , 8 , 12, END, 1, 1, 1, 1<br /> <br /> [[File:Marymoor.PNG]]<br /> <br /> Each line corresponds to one of the numbered intersections (nodes) in the figure, starting at 0 and increasing by 1. The fist number is the distance north from the origin in millimeters (or distance south for a negative number). The second number is the distance east in mm if positive or distance west if negative.<br /> The third, forth, fifth and sixth numbers are the nodes connected to the present node, or &quot;END&quot; if none. An intersection of more than four ways can be handled by introducing a helper node at the same location.<br /> <br /> Distances are given in mm so that they can be stored in a 32-bit integer and will not overflow until the distance is over 2147 km. Arithmetic in integers is much faster than floating point, especially on micro-controllers that do not have hardware floating point. <br /> <br /> The last four numbers are the relative costs of the paths linking the nodes. Path planning is done with A*, which makes the assumption that the distance between nodes is Euclidean. If this is not the case, due to road curvature or speed restriction, the multiplier should be modified.<br /> <br /> The vehicle will find a path that goes from node to node until it reaches the destination that was entered. To do so, it finds the closest road (where roads are the lines connecting nodes and takes the shortest path to that road. It then follows the road network from node to node until it gets close to the destination. If the destination is not on a road, the vehicle will follow a path to the origin that is perpendicular to the nearest road.<br /> <br /> The map should be laid out to give preferred robot paths that do not contain any fixed obstacles. Nodes should be provided to approximate road curvature.<br /> <br /> ==Enhanced Mapping==<br /> This basic map structure should be augmented by a secondary file that describes the road. This supplemental file may include road curvature, number of lanes, lane width, lane markings, and speed.<br /> <br /> The SD card has a simple files system where only one file can be open at a time. After MAP_DEFS.TXT is read, that file is closed, and the file for the directed graph is read into memory and then closed. A road supplemental file could be read as needed.<br /> <br /> ==Cubic Splines==<br /> The nodes in the directed graph are of class Waypoint. A Waypoint may contain more information than just its location. In the implementation as of August 2020, Waypoints are connected by straight lines, which produces discontinuities where they join. In the original design, Waypoints were connected by cubic splines (Hermite Curves; see James Foley et al. &quot;Introduction to Computer Graphics&quot; for a good summary). Cubics are infinitely differentiable and are widely used to fit smooth curves. The main practical difference between a line segment and a cubic is that the line is specified by its two endpoints, but the Hermite curve also requires the tangents (directions) at the endpoints. The cubic connecting two intersections will be different if one is required to approach from the west or from the south; the line segment would be identical.<br /> Bezier curves are similar to Hermite curves. Both have four control points. The Bezier curve has two control points not on the curve that are used to shape it. There is a simple matrix transformation relating the Bezier and Hermite curves.<br /> <br /> ==Latitude and Longitude==<br /> Global positions on the earth are given in spherical coordinates: <br /> * Latitude - angle between the north (90) and south (-90) poles<br /> * Longitude - angle east or west of Greenwich.<br /> * Radius of the earth (meters)<br /> <br /> Since the Elcano system is designed to operate in a small area, it is not concerned about great circle routes for intercontinental distances. Instead it makes the approximation that the earth is locally flat. It sets an origin for the area in which it operates, and sets up a coordinate system (x,y) where positive x is distance east of the origin and positive y is distance north. Distances are internally stored in mm, and can be easily displayed in meters.<br /> The distance represented by one degree of longitude varies from 111 km at the equator to 0 at the poles. The size of a degree of longitude depends on the cosine of the latitude.<br /> <br /> Given a (latitude, longitude) its map position as (east_mm, north_mm) is given by<br /> <br /> north_mm = (latitude - latitude_of_map_origin) * earth_radius_mm<br /> <br /> east_mm = (longitude - longitude_of_map_origin) * cos(latitude_of_map_origin) * earth_radius_mm</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Mapping_System&diff=363 2020-08-06T19:16:40Z

<p>Tfolsom: </p> <hr /> <div>The Sensor Hub has a low-definition digital map of its operating area. That map is a directed graph of intersections. The files system on the SD card is organized at the original PC MS-DOS system: file names of up to 8 characters, a dot, and an extension of up to three characters.<br /> <br /> ==Master File==<br /> The master file is named MAP_DEFS.TXT<br /> It may look like this:<br /> <br /> 47.758949, -122.190746, UWB_CAMP.TXT<br /> <br /> 47.6213 , -122.3509 , SEATTCEN.TXT<br /> <br /> 47.662 , -122.115 , MARYMOOE.TXT<br /> <br /> 47.660 , -122.185 , BRIDLETR.TXT<br /> <br /> 47.760854, -122.190033, UWB_SCCR.TXT<br /> <br /> 49, 8, CARLA.TXT<br /> <br /> The first two numbers are the latitude and longitude of the origin of the map file. The third item is the name of the file.<br /> When the robot powers up, it will acquire a GPS fix for its present position. It will find the closest latitude and longitude to its position and load that file.<br /> <br /> ==Local Maps==<br /> <br /> For instance, the first few entries of MARYMOOE.TXT are<br /> <br /> -775855, -78948, 1 , END, END, END, 1, 1, 1, 1<br /> -598367, 16679, 0 , 2 , END, END, 1, 1, 1, 1<br /> -426121, 137882, 3 , 17, 19, END, 1, 1, 1, 1<br /> -345240, 149001, 4 , 18, END, END, 1, 1, 1, 1<br /> -216431, 154561, 18, 15, 5, END, 1, 1, 1, 1<br /> -34449, 174576, 4 , 6 , 14, END, 1, 1, 1, 1<br /> 89118, 116792, 5 , 7 , 13, END, 1, 1, 1, 1<br /> 148281, 165680, 6 , 8 , 12, END, 1, 1, 1, 1<br /> <br /> [[File:Marymoor.PNG]]<br /> <br /> Each line corresponds to one of the numbered intersections (nodes) in the figure, starting at 0 and increasing by 1. The fist number is the distance north from the origin in millimeters (or distance south for a negative number). The second number is the distance east in mm if positive or distance west if negative.<br /> The third, forth, fifth and sixth numbers are the nodes connected to the present node, or &quot;END&quot; if none. An intersection of more than four ways can be handled by introducing a helper node at the same location.<br /> <br /> Distances are given in mm so that they can be stored in a 32-bit integer and will not overflow until the distance is over 2147 km. Arithmetic in integers is much faster than floating point, especially on micro-controllers that do not have hardware floating point. <br /> <br /> The last four numbers are the relative costs of the paths linking the nodes. Path planning is done with A*, which makes the assumption that the distance between nodes is Euclidean. If this is not the case, due to road curvature or speed restriction, the multiplier should be modified.<br /> <br /> The vehicle will find a path that goes from node to node until it reaches the destination that was entered. To do so, it finds the closest road (where roads are the lines connecting nodes and takes the shortest path to that road. It then follows the road network from node to node until it gets close to the destination. If the destination is not on a road, the vehicle will follow a path to the origin that is perpendicular to the nearest road.<br /> <br /> The map should be laid out to give preferred robot paths that do not contain any fixed obstacles. Nodes should be provided to approximate road curvature.<br /> <br /> ==Enhanced Mapping==<br /> This basic map structure should be augmented by a secondary file that describes the road. This supplemental file may include road curvature, number of lanes, lane width, lane markings, and speed.<br /> <br /> The SD card has a simple files system where only one file can be open at a time. After MAP_DEFS.TXT is read, that file is closed, and the file for the directed graph is read into memory and then closed. A road supplemental file could be read as needed.<br /> <br /> ==Cubic Splines==<br /> The nodes in the directed graph are of class Waypoint. A Waypoint may contain more information than just its location. In the implementation as of August 2020, Waypoints are connected by straight lines, which produces discontinuities where they join. In the original design, Waypoints were connected by cubic splines (Hermite Curves; see James Foley et al. &quot;Introduction to Computer Graphics&quot; for a good summary). Cubics are infinitely differentiable and are widely used to fit smooth curves. The main practical difference between a line segment and a cubic is that the line is specified by its two endpoints, but the Hermite curve also requires the tangents (directions) at the endpoints. The cubic connecting two intersections will be different if one is required to approach from the west or from the east; the line segment would be identical.<br /> Bezier curves are similar to Hermite curves. Both have four control points. The Bezier curve has two control points not on the curve that are used to shape it. There is a simple matrix transformation relating the Bezier and Hermite curves.<br /> <br /> ==Latitude and Longitude==<br /> Global positions on the earth are given in spherical coordinates: <br /> * Latitude - angle between the north (90) and south (-90) poles<br /> * Longitude - angle east or west of Greenwich.<br /> * Radius of the earth (meters)<br /> <br /> Since the Elcano system is designed to operate in a small area, it is not concerned about great circle routes for intercontinental distances. Instead it makes the approximation that the earth is locally flat. It sets an origin for the area in which it operates, and sets up a coordinate system (x,y) where positive x is distance east of the origin and positive y is distance north. Distances are internally stored in mm, and can be easily displayed in meters.<br /> The distance represented by one degree of longitude varies from 111 km at the equator to 0 at the poles. The size of a degree of longitude depends on the cosine of the latitude.<br /> <br /> Given a (latitude, longitude) its map position as (east_mm, north_mm) is given by<br /> <br /> north_mm = (latitude - latitude_of_map_origin) * earth_radius_mm<br /> <br /> east_mm = (longitude - longitude_of_map_origin) * cos(latitude_of_map_origin) * earth_radius_mm</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Mapping_System&diff=362 2020-08-05T00:25:35Z

<p>Tfolsom: </p> <hr /> <div>The Sensor Hub has a low-definition digital map of its operating area. That map is a directed graph of intersections. The files system on the SD card is organized at the original PC MS-DOS system: file names of up to 8 characters, a dot, and an extension of up to three characters.<br /> <br /> The master files is named MAP_DEFS.TXT<br /> It may look like this:<br /> <br /> 47.758949, -122.190746, UWB_CAMP.TXT<br /> <br /> 47.6213 , -122.3509 , SEATTCEN.TXT<br /> <br /> 47.662 , -122.115 , MARYMOOE.TXT<br /> <br /> 47.660 , -122.185 , BRIDLETR.TXT<br /> <br /> 47.760854, -122.190033, UWB_SCCR.TXT<br /> <br /> 49, 8, CARLA.TXT<br /> <br /> The first two numbers are the latitude and longitude of the origin of the map file. The third item is the name of the file.<br /> When the robot powers up, it will acquire a GPS fix for its present position. It will find the closest latitude and longitude to its position and load that file.<br /> <br /> For instance, the first few entries of MARYMOOE.TXT are<br /> <br /> -775855, -78948, 1 , END, END, END, 1, 1, 1, 1<br /> -598367, 16679, 0 , 2 , END, END, 1, 1, 1, 1<br /> -426121, 137882, 3 , 17, 19, END, 1, 1, 1, 1<br /> -345240, 149001, 4 , 18, END, END, 1, 1, 1, 1<br /> -216431, 154561, 18, 15, 5, END, 1, 1, 1, 1<br /> -34449, 174576, 4 , 6 , 14, END, 1, 1, 1, 1<br /> 89118, 116792, 5 , 7 , 13, END, 1, 1, 1, 1<br /> 148281, 165680, 6 , 8 , 12, END, 1, 1, 1, 1<br /> <br /> [[File:Marymoor.PNG]]<br /> <br /> Each line corresponds to one of the numbered intersections (nodes) in the figure, starting at 0 and increasing by 1. The fist number is the distance north from the origin in millimeters (or distance south for a negative number). The second number is the distance east in mm if positive or distance west if negative.<br /> The third, forth, fifth and sixth numbers are the nodes connected to the present node, or &quot;END&quot; if none. An intersection of more than four ways can be handled by introducing a helper node at the same location.<br /> <br /> Distances are given in mm so that they can be stored in a 32-bit integer and will not overflow until the distance is over 1000 km. Arithmetic in integers is much faster than floating point, especially on micro-controllers that do not have hardware floating point.<br /> <br /> The last four numbers are the relative costs of the paths linking the nodes. Path planning is done with A*, which makes the assumption that the distance between nodes is Euclidean. If this is not the case, due to road curvature or speed restriction, the multiplier should be modified.<br /> <br /> The vehicle will find a path that goes from node to node until it reaches the destination that was entered. To do so, it finds the closest road (where roads are the lines connecting nodes and takes the shortest path to that road. It then follows the road network from node to node until it gets close to the destination. If the destination is not on a road, the vehicle will follow a path to the origin that is perpendicular to the nearest road.<br /> <br /> The map should be laid out to give preferred robot paths that do not contain any fixed obstacles. Nodes should be provided to approximate road curvature.<br /> <br /> This basic map structure should be augmented by a secondary file that describes the road. This supplemental file may include road curvature, number of lanes, lane width, lane markings, and speed.<br /> <br /> The SD card has a simple files system where only one file can be open at a time. After MAP_DEFS.TXT is read, that file is closed, and the file for the directed graph is read into memory and then closed. A road supplemental file could be read as needed.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Mapping_System&diff=361 2020-08-05T00:19:31Z

<p>Tfolsom: </p> <hr /> <div>The Sensor Hub has a low-definition digital map of its operating area. That map is a directed graph of intersections. The files system on the SD card is organized at the original PC MS-DOS system: file names of up to 8 characters, a dot, and an extension of up to three characters.<br /> <br /> The master files is named MAP_DEFS.TXT<br /> It may look like this:<br /> <br /> 47.758949, -122.190746, UWB_CAMP.TXT<br /> <br /> 47.6213 , -122.3509 , SEATTCEN.TXT<br /> <br /> 47.662 , -122.115 , MARYMOOE.TXT<br /> <br /> 47.660 , -122.185 , BRIDLETR.TXT<br /> <br /> 47.760854, -122.190033, UWB_SCCR.TXT<br /> <br /> 49, 8, CARLA.TXT<br /> <br /> The first two numbers are the latitude and longitude of the origin of the map file. The third item is the name of the file.<br /> When the robot powers up, it will acquire a GPS fix for its present position. It will find the closest latitude and longitude to its position and load that file.<br /> <br /> For instance, the first few entries of MARYMOOE.TXT are<br /> <br /> -775855, -78948, 1 , END, END, END, 1, 1, 1, 1<br /> -598367, 16679, 0 , 2 , END, END, 1, 1, 1, 1<br /> -426121, 137882, 3 , 17, 19, END, 1, 1, 1, 1<br /> -345240, 149001, 4 , 18, END, END, 1, 1, 1, 1<br /> -216431, 154561, 18, 15, END, END, 1, 1, 1, 1<br /> -34449, 174576, 4 , 6 , 14, END, 1, 1, 1, 1<br /> 89118, 116792, 5 , 7 , 13, END, 1, 1, 1, 1<br /> 148281, 165680, 6 , 8 , 12, END, 1, 1, 1, 1<br /> <br /> [[File:Marymoor.png]]<br /> <br /> Each line corresponds to one of the numbered intersections (nodes) in the figure, starting at 0 and increasing by 1. The fist number is the distance north from the origin in millimeters (or distance south for a negative number). The second number is the distance east in mm if positive or distance west if negative.<br /> The third, forth, fifth and sixth numbers are the nodes connected to the present node, or &quot;END&quot; if none. An intersection of more than four ways can be handled by introducing a helper node at the same location.<br /> <br /> Distances are given in mm so that they can be stored in a 32-bit integer and will not overflow until the distance is over 1000 km. Arithmetic in integers is much faster than floating point, especially on micro-controllers that do not have hardware floating point.<br /> <br /> The last four numbers are the relative costs of the paths linking the nodes. Path planning is done with A*, which makes the assumption that the distance between nodes is Euclidean. If this is not the case, due to road curvature or speed restriction, the multiplier should be modified.<br /> <br /> The vehicle will find a path that goes from node to node until it reaches the destination that was entered. To do so, it finds the closest road (where roads are the lines connecting nodes and takes the shortest path to that road. It then follows the road network from node to node until it gets close to the destination. If the destination is not on a road, the vehicle will follow a path to the origin that is perpendicular to the nearest road.<br /> <br /> The map should be laid out to give preferred robot paths that do not contain any fixed obstacles. Nodes should be provided to approximate road curvature.<br /> <br /> This basic map structure should be augmented by a secondary file that describes the road. This supplemental file may include road curvature, number of lanes, lane width, lane markings, and speed.<br /> <br /> The SD card has a simple files system where only one file can be open at a time. After MAP_DEFS.TXT is read, that file is closed, and the file for the directed graph is read into memory and then closed. A road supplemental file could be read as needed.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=File:Marymoor.PNG&diff=360 2020-08-05T00:17:04Z

<p>Tfolsom: Marymoor Park, Redmond, WA</p> <hr /> <div>== Summary ==<br /> Marymoor Park, Redmond, WA</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Mapping_System&diff=359 2020-08-05T00:08:57Z

<p>Tfolsom: </p> <hr /> <div>The Sensor Hub has a low-definition digital map of its operating area. That map is a directed graph of intersections. The files system on the SD card is organized at the original PC MS-DOS system: file names of up to 8 characters, a dot, and an extension of up to three characters.<br /> <br /> The master files is named MAP_DEFS.TXT<br /> It may look like this:<br /> <br /> 47.758949, -122.190746, UWB_CAMP.TXT<br /> <br /> 47.6213 , -122.3509 , SEATTCEN.TXT<br /> <br /> 47.662 , -122.115 , MARYMOOE.TXT<br /> <br /> 47.660 , -122.185 , BRIDLETR.TXT<br /> <br /> 47.760854, -122.190033, UWB_SCCR.TXT<br /> <br /> 49, 8, CARLA.TXT<br /> <br /> The first two numbers are the latitude and longitude of the origin of the map file. The third item is the name of the file.<br /> When the robot powers up, it will acquire a GPS fix for its present position. It will find the closest latitude and longitude to its position and load that file.<br /> <br /> For instance, the first few entries of MARYMOOE.TXT are<br /> <br /> -775855, -78948, 1 , END, END, END, 1, 1, 1, 1<br /> -598367, 16679, 0 , 2 , END, END, 1, 1, 1, 1<br /> -426121, 137882, 3 , 17, 19, END, 1, 1, 1, 1<br /> -345240, 149001, 4 , 18, END, END, 1, 1, 1, 1<br /> -216431, 154561, 18, 15, END, END, 1, 1, 1, 1<br /> -34449, 174576, 4 , 6 , 14, END, 1, 1, 1, 1<br /> 89118, 116792, 5 , 7 , 13, END, 1, 1, 1, 1<br /> 148281, 165680, 6 , 8 , 12, END, 1, 1, 1, 1<br /> <br /> Each line corresponds to one of the numbered intersections (nodes) in the figure, starting at 0 and increasing by 1. The fist number is the distance north from the origin in millimeters (or distance south for a negative number). The second number is the distance east in mm if positive or distance west if negative.<br /> The third, forth, fifth and sixth numbers are the nodes connected to the present node, or &quot;END&quot; if none. An intersection of more than four ways can be handled by introducing a helper node at the same location.<br /> <br /> Distances are given in mm so that they can be stored in a 32-bit integer and will not overflow until the distance is over 1000 km. Arithmetic in integers is much faster than floating point, especially on micro-controllers that do not have hardware floating point.<br /> <br /> The last four numbers are the relative costs of the paths linking the nodes. Path planning is done with A*, which makes the assumption that the distance between nodes is Euclidean. If this is not the case, due to road curvature or speed restriction, the multiplier should be modified.<br /> <br /> The vehicle will find a path that goes from node to node until it reaches the destination that was entered. To do so, it finds the closest road (where roads are the lines connecting nodes and takes the shortest path to that road. It then follows the road network from node to node until it gets close to the destination. If the destination is not on a road, the vehicle will follow a path to the origin that is perpendicular to the nearest road.<br /> <br /> The map should be laid out to give preferred robot paths that do not contain any fixed obstacles. Nodes should be provided to approximate road curvature.<br /> <br /> This basic map structure should be augmented by a secondary file that describes the road. This supplemental file may include road curvature, number of lanes, lane width, lane markings, and speed.<br /> <br /> The SD card has a simple files system where only one file can be open at a time. After MAP_DEFS.TXT is read, that file is closed, and the file for the directed graph is read into memory and then closed. A road supplemental file could be read as needed.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Mapping_System&diff=358 2020-08-05T00:01:50Z

<p>Tfolsom: </p> <hr /> <div>The Sensor Hub has a low-definition digital map of its operating area. That map is a directed graph of intersections. The files system on the SD card is organized at the original PC MS-DOS system: file names of up to 8 characters, a dot, and an extension of up to three characters.<br /> <br /> The master files is named MAP_DEFS.TXT<br /> It may look like this:<br /> <br /> 47.758949, -122.190746, UWB_CAMP.TXT<br /> <br /> 47.6213 , -122.3509 , SEATTCEN.TXT<br /> <br /> 47.662 , -122.115 , MARYMOOE.TXT<br /> <br /> 47.660 , -122.185 , BRIDLETR.TXT<br /> <br /> 47.760854, -122.190033, UWB_SCCR.TXT<br /> <br /> 49, 8, CARLA.TXT<br /> <br /> The first two numbers are the latitude and longitude of the origin of the map file. The third item is the name of the file.<br /> When the robot powers up, it will acquire a GPS fix for its present position. It will find the closest latitude and longitude to its position and load that file.<br /> <br /> For instance, the first few entries of MARYMOOE.TXT are<br /> <br /> -775855, -78948, 1 , END, END, END, 1, 1, 1, 1<br /> -598367, 16679, 0 , 2 , END, END, 1, 1, 1, 1<br /> -426121, 137882, 3 , 17, 19, END, 1, 1, 1, 1<br /> -345240, 149001, 4 , 18, END, END, 1, 1, 1, 1<br /> -216431, 154561, 18, 15, END, END, 1, 1, 1, 1<br /> -34449, 174576, 4 , 6 , 14, END, 1, 1, 1, 1<br /> 89118, 116792, 5 , 7 , 13, END, 1, 1, 1, 1<br /> 148281, 165680, 6 , 8 , 12, END, 1, 1, 1, 1<br /> <br /> Each line corresponds to one of the numbered intersections (nodes) in the figure, starting at 0 and increasing by 1. The fist number is the distance north from the origin in millimeters (or distance south for a negative number). The second number is the distance east in mm if positive or distance west if negative.<br /> The third, forth, fifth and sixth numbers are the nodes connected to the present node, or &quot;END&quot; if none. An intersection of more than four ways can be handled by introducing a helper node at the same location.<br /> <br /> The last four numbers are the relative costs of the paths linking the nodes. Path planning is done with A*, which makes the assumption that the distance between nodes is Euclidean. If this is not the case, due to road curvature or speed restriction, the multiplier should be modified.<br /> <br /> The vehicle will find a path that goes from node to node until it reaches the destination that was entered. To do so, it finds the closest road (where roads are the lines connecting nodes and takes the shortest path to that road. It then follows the road network from node to node until it gets close to the destination. If the destination is not on a road, the vehicle will follow a path to the origin that is perpendicular to the nearest road.<br /> <br /> The map should be laid out to give preferred robot paths that do not contain any fixed obstacles. Nodes should be provided to approximate road curvature.<br /> <br /> This basic map structure should be augmented by a secondary file that describes the road. This supplemental file may include road curvature, number of lanes, lane width, lane markings, and speed.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Mapping_System&diff=357 2020-08-04T23:50:19Z

<p>Tfolsom: Created page with &quot;The Sensor Hub has a low-definition digital map of its operating area. That map is a directed graph of intersections. The files system on the SD card is organized at the origi...&quot;</p> <hr /> <div>The Sensor Hub has a low-definition digital map of its operating area. That map is a directed graph of intersections. The files system on the SD card is organized at the original PC MS-DOS system: file names of up to 8 characters, a dot, and an extension of up to three characters.<br /> <br /> The master files is named MAP_DEFS.TXT<br /> It may look like this:<br /> <br /> 47.758949, -122.190746, UWB_CAMP.TXT<br /> <br /> 47.6213 , -122.3509 , SEATTCEN.TXT<br /> <br /> 47.662 , -122.115 , MARYMOOE.TXT<br /> <br /> 47.660 , -122.185 , BRIDLETR.TXT<br /> <br /> 47.760854, -122.190033, UWB_SCCR.TXT<br /> <br /> 49, 8, CARLA.TXT<br /> <br /> The first two numbers are the latitude and longitude of the origin of the map file. The third item is the name of the file.<br /> When the robot powers up, it will acquire a GPS fix for its present position. It will find the closest latitude and longitude to its position and load that file.<br /> <br /> For instance, the first few entries of MARYMOOE.TXT are<br /> <br /> -775855, -78948, 1 , END, END, END, 1, 1, 1, 1<br /> -598367, 16679, 0 , 2 , END, END, 1, 1, 1, 1<br /> -426121, 137882, 3 , 17, 19, END, 1, 1, 1, 1<br /> -345240, 149001, 4 , 18, END, END, 1, 1, 1, 1<br /> -216431, 154561, 18, 15, END, END, 1, 1, 1, 1<br /> -34449, 174576, 4 , 6 , 14, END, 1, 1, 1, 1<br /> 89118, 116792, 5 , 7 , 13, END, 1, 1, 1, 1<br /> 148281, 165680, 6 , 8 , 12, END, 1, 1, 1, 1<br /> <br /> Each line corresponds to one of the numbered intersections (nodes) in the figure, starting at 0 and increasing by 1. The fist number is the distance north from the origin in millimeters (or distance south for a negative number). The second number is the distance east in mm if positive or distance west if negative.<br /> The third, forth, fifth and sixth numbers are the nodes connected to the present node, or &quot;END&quot; if none. An intersection of more than four ways can be handled by introducing a helper node at the same location.<br /> <br /> The last four numbers are the relative costs of the paths linking the nodes. Path planning is done with A*, which makes the assumption that the distance between nodes is Euclidean. If this is not the case, due to road curvature or speed restriction, the multiplier should be modified.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=High_Level&diff=356 2020-08-04T23:17:40Z

<p>Tfolsom: </p> <hr /> <div>The High Level system has been renamed &quot;Sensor Hub&quot;. Documentation in divided into the software and hardware.<br /> <br /> ==[[HighLevelSWv3]]==<br /> ==[[HighLevelHWv3]]==<br /> [[File:HighLevel.JPG|1000px]]<br /> <br /> ==[[Mapping System]]==<br /> <br /> NEXT &gt; [[SensorsPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Simulator&diff=342 2020-07-14T04:35:13Z

<p>Tfolsom: </p> <hr /> <div>= Elcano Carla Simulation External Specification =<br /> <br /> CARLA &lt;http://carla.org/&gt; is an open-source driving simulator. During 2019-20 students develop3e a go-between circuit board to transfer data between CARLA simulation and the sensor slots of the Elcano hardware. The CARLA software allows users to emulate trike parameters under controlled conditions within a virtual world, providing an efficient system for testing sensor behavior, design implementation, and benchmarking overall vehicle progress. The CARLA software can simulate a variety of road conditions such as traffic patterns, inclines, and weather as well as provide users control over vehicle parameters including weight, engine power, and aerodynamic properties.<br /> <br /> <br /> An Arduino Due serves as a router to transfer data from vehicle systems to CARLA under a variety of test conditions, enabling the software to replicate responses and return sensor data to be reevaluated for accuracy. The CARLA Micro-AV Bridge includes the Router, Sensor Hub and Drive-by-wire Arduinos. It permits testing the Elcano trike software, including camera, sonar, throttle, steering and brake systems. Simulation allows users to immediately see the results of adjustments to vehicle parameters and highlight physical aspects of the trike within the virtual environment. This project enables users to efficiently implement improvements and track the immediate effects of design changes without spending the time and resources it would take to transport or operate the trike in real world test scenarios. It enables developers to improve the software without needing to invest in a vehicle.<br /> <br /> [[File:Architecture_CAN_Sim_7_7_20.png|1000px]]<br /> <br /> <br /> <br /> == Purpose: ==<br /> The following is a generalized list of the desired functionality of the simulator.<br /> * Simulate data for all sensors associated with Elcano Trike.<br /> * Simulate Elcano behavior to throttle, brake, and steering.<br /> * Have low and high-level boards function normally with the simulated sensor data without knowing data is being simulated.<br /> * Allow low and high-level board interaction to be tested.<br /> * Allow autonomous driving to be tested.<br /> <br /> == Components: ==<br /> ''' Simulation:''' <br /> Code to be executed by a computer that has access to a Carla server, either locally, or through a network. Controls all objects in Carla simulation. Retrieves sensor data from Carla, and sends router board. Also retrieves actuation instructions from the router board and sends to Carla.<br /> <br /> '''Sensor Hub [aka High Level] Processor''' <br /> The same code is used for the virtual or physical vehicle, sending and receiving messages over the CAN Bus. The CARLA Bridge replaces sensor data that would normally come from instruments.<br /> <br /> '''Drive-by-wire [aks C2 LowLevel] Processor''' <br /> Current Elcano Drive-by-wirel code. Actuator data is routed to CARLA.<br /> <br /> '''Router Board:''' <br /> Code is executed on the Arduino Due that functions as the router board. Routes commands from Drive-by-wire to Carla via Python scripts. Also routes sensor data from Carla to Sensor Hub processor.<br /> <br /> [[File:RouterBoard2020A.jpg|800px|]]<br /> <br /> [[File:RouterBoard2020B.jpg|800px|]]<br /> <br /> == Current Functionality of Simulation: ==<br /> At the end our Autumn 2019 Capstone, we were able to deliver a demo that demonstrated communication between all components; high-level board (Arduino Due), low-level board (Arduino Mega 2560) with shield running low level code, router board (Arduino Due), and the instance of Carla. The instructions on how to reproduce the demo will be given later in this document. The primary roadblock that prevented further development into this project was the state of the CAN system of the Elcano trike (particularly the transceiver board which seems to have a flawed design). These are the current features of the simulator.<br /> * Implementation of USB serial communication between router board and computer running simulator.py. Both entities (Computer and ArduinoDue) can send and receive data through USB connection.<br /> * Implementation of a cyclometer. Router board can receive the current speed of the simulated vehicle in Carla and convert it into an interrupt-based cyclometer pulse, based on the wheel dimension of the Elcano. Also considers the random error of cyclometer present on the Elcano trike. This can be debugged with the built-in LED on the router board.<br /> * Implementation of NMEA GPS sensor. Carla is able the output NMEA GPS data to the router board 10 times per second, effectively simulating the GPS sensor on the high-level board. Router board is successfully able to output it to UART serial which is how it is transmitted to the high-level board.<br /> * Implementation of timing structure. Computer running simulator.py waits for data to be interpreted from the router board while the router board executes its update 10 times per second. This is the desired speed for both sensor data and actuation data to be updated.<br /> * Implementation of vehicle control updaters through throttle, brake, and steering data. The computer running simulator.py can take desired throttle, brake, and steering and convert them into corresponding commands for Carla using Carla API. These commands move the vehicle within Carla. This is the primarily what the demo shows.<br /> <br /> == Demo Guide (How to Set-Up) ==<br /> The following is a guide to set up the Elcano simulator.<br /> <br /> ===''' Materials '''===<br /> * 1 Assembled Elcano Simulator Printed Circuit Board (PCB)<br /> * 2 Arduino Due<br /> * 1 Arduino Mega 2560<br /> * 1 Box (200 x 150 x 70 mm)<br /> * 2 Voltage Level Converter (included w/Simulator PCB)<br /> * 1 SD Card (w/map files)<br /> * 1 USB AB Cable (for Arduino Mega)<br /> * 1 USB Micro Cable (for Arduino Due)<br /> * 1 computer capable of running Carla<br /> <br /> ===''' Pre-installation '''===<br /> Use the following instructions to install the required software to run the simulation.<br /> <br /> #&lt;u&gt;''''' Python '''''&lt;/u&gt;<br /> #* Install Python 3 (if not installed already)<br /> #::-experiments used version 3.7.6<br /> #* In a terminal, move to .\Simulation\<br /> #* Run the command “pip3 install -r requirements.txt” to have pip install all the required python libraries for the simulator<br /> #&lt;u&gt;''''' CARLA '''''&lt;/u&gt;<br /> #*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]<br /> #*CARLA requirements:&lt;br /&gt;[[File:Carla_Requirements.jpg|500px|]]<br /> #&lt;u&gt;''''' Arduino Libraries '''''&lt;/u&gt;&lt;br /&gt;Download these Arduino libraries prior to running the simulation:<br /> #* [https://github.com/Seeed-Studio/CAN_BUS_Shield CAN_BUS_SHIELD by Seeed-Studio]<br /> #* [https://github.com/br3ttb/Arduino-PID-Library PID by Brett Beauregard]<br /> #* [https://github.com/NicoHood/PinChangeInterrupt Pin Change Interrupt by Nico Hood]<br /> #* [https://github.com/SweBarre/MCP48x2 MCP48x2 DAC by Jonas Forsberg]<br /> #* [https://github.com/ivanseidel/DueTimer Arduino Due Timer Interrupts by Ivan Seidel]<br /> #* Previous version of [https://github.com/collin80/due_can Arduino Due CAN Bus library] is used but the necessary files are included within the repository.<br /> #&lt;u&gt;''''' Elcano Repositories '''''&lt;/u&gt;&lt;br /&gt;The Elcano repositories are needed to run the simulation:<br /> #*[https://github.com/elcano/HighLevel High Level]<br /> #*[https://github.com/elcano/Simulator Simulator (Router Board &amp; Simulator Script)]<br /> #*[https://github.com/elcano/Drive-by-wire Drive-by-wire (Low Level)]<br /> ===''' Run Simulation '''===<br /> Once all the requirements are installed, use the following instructions to run the simulation. <br /> &lt;br /&gt;[[File:Router_PCB_Connections.jpg|500px]]<br /> &lt;br /&gt;&lt;br /&gt;'''''Step 1: Program all Arduinos'''''<br /> #Upload &lt;b&gt;router_board_v1.ino&lt;/b&gt; to the router Arduino Due programming port <br /> #Upload &lt;b&gt;High_Level.ino&lt;/b&gt; to the high level Arduino Due programming port<br /> #Upload &lt;b&gt;Drive_By_Wire.ino&lt;/b&gt; to the low level Arduino Mega 2560<br /> '''''Step 2: Run CARLA'''''<br /> #Open a command prompt (type cmd in the windows search box)<br /> #Go to the directory where CARLA is installed (CARLAUE4.exe)<br /> #:&lt;code&gt;cd C:\Users\bobross\Documents\ElcanoInstaller\CARLA\WindowsNoEditor&lt;/code&gt;<br /> #::-You may have it saved to a different directory<br /> #From the CARLA directory, type:<br /> #:&lt;code&gt;CARLAUE4.exe&lt;/code&gt;<br /> #:Or, to run in low resolution mode:<br /> #:&lt;code&gt;CARLAUE4.exe -ResX=720 -ResY=480 -quality-level=Low&lt;/code&gt;<br /> '''''Step 3: Run Simulation'''''<br /> #Connect your PC to the native port on the Router Board Due <br /> #Open a command prompt (type cmd in the windows search box)<br /> #Go to the Simulation directory <br /> #:&lt;code&gt;cd C:\Users\bobross\Documents\Simulator\Simulation&lt;/code&gt;<br /> #::-You may have it saved to a different directory<br /> #From Simulation directory, start the Simulator UI <br /> #:&lt;code&gt;.\Simulation\start.bat&lt;/code&gt;<br /> #By default, the Simulator UI will populate local running CARLA settings<br /> #*For control via the router board, leave mode as Auto<br /> #*To control via manual keyboard input, change mode to Manual.<br /> #*If running a network-based CARLA server, enter IP and Port of CARLA into the respective boxes. (i.e. 192.168.1.1, 2010)<br /> #Click &quot;Connect to CARLA&quot;<br /> #*If Auto mode, it will pop up a selection of COM devices, select routerboard native port COM to begin and press go. <br /> #*If Manual mode, client will start with keyboard controls (WASD)<br /> #Observe behavior in simulator. <br /> #If car gets stuck, kill current simulator.py process and restart.<br /> ===''' Debug/Logging '''===<br /> *High Level uses the Programming Port to display debug messages over serial monitor<br /> *Router Board uses the Programming Port to display debug messages over serial monitor<br /> <br /> == Out of Scope Functionality Tested/Implemented ==<br /> * Our project required us to delve into pieces of code within the Elcano project outside of our scope. Understanding of how sensors are read by the high and low-level boards is necessary for the simulation of the sensors. We were able to fix some issues regarding the CAN communication between the high and low-level boards. The modified low-level code was not pushed to the main low-level code folder in the repository on Github, however, it is included within the simulator documentation. The following were implemented.<br /> * Unification of the proposed CAN message structure and the actual CAN message processing on the low-level code for CAN messages with ID 0x350 (High-level drive instructions). These are CAN messages the high-level will send to the low level to facilitate autonomy.<br /> * Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.<br /> == To Do (Software): ==<br /> ''' High Priority: '''<br /> * Simulate gyro sensor<br /> * Simulate accelerometer/magnetometer sensor.<br /> * Simulate wheel angle sensor.<br /> * Implement steering actuation when low-level CAN processing of steering command is fixed.<br /> * Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.<br /> ''' Medium Priority: '''<br /> * Simulate ScanseSweep.<br /> * Implement receiver board when board is fully fixed.<br /> * Incorporate Elcano trike physics to simulated vehicle.<br /> ''' Low Priority '''<br /> * Simulate camera sensor.<br /> == Bugs Within Simulator ==<br /> * Occasionally the simulator and router board will desync and the NMEA GPS messages received by the router board will be faulty. This is usually followed by a crash of simulator.py. If not, simply press Ctrl^C and restart simulator.py.<br /> * If simulator.py unexpectedly terminates, the created actors and sensors in Carla will not be properly destroyed. This usually does not cause problems for the simulation but proper termination in the future would be safer. For now if it is causing problems simply restart Carla.<br /> * Carla will never stop outputting sensor data even if asked to stop. This is a bug with Carla and not in our scope.<br /> * Most malfunctions can be temporarily fixed by restarting the simulator.py instance.<br /> == Other Elcano Bugs Found ==<br /> * While we were able to fix the code for the low-level CAN interpretation of the throttle and brake commands from high-level CAN messages, the PWM steering response was not fully tested. We were unable to get the low-level board to output the correct PWM for the sent CAN messages and this needs more testing.<br /> * The receiver board cannot get CAN to initialize. Voltage testing confirmed that the CAN components (MCP2515 and MCP 2550) are receiving the correct operating voltages (5v). Also, multiple CAN libraries besides the suggested Seeed Studio library were tested with no success (SparkFun CAN library was one of the tested libraries). Possible problem is incompatibility between the 5v CAN components and the 3.3V SAMD21 board. Another possible problem is design flaw of pcb.<br /> * Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.<br /> == Additional Notes ==<br /> * Currently, the order that you output data from the router board to the computer running simulator.py is non-trivial. Data is interpreted based on the order which it is received.<br /> * Carla sensor listening was flawed at the time this was made; .stop() would not stop the sensor from executing its attached function at each tick of Carla. Therefore speed was implemented without the use of sensors, and instead uses a command that accesses the speed only when needed. This is the suggested method until sensors are fixed. Certain sensors such as NMEA GPS, however, are only implementable using Carla sensors. Additional information can be found on Carla Documentation.<br /> * In PowerShell, in CarlaUE4 path, run Carla as: ***Start-Process CarlaUE4 -ArgumentList “—quality-level=Low”*** to lower gpu load.<br /> * Headless mode can be enabled for complete removal of graphics rendering, however, visual debugging is extremely useful.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Simulator&diff=341 2020-07-14T04:14:57Z

<p>Tfolsom: </p> <hr /> <div>= Elcano Carla Simulation External Specification =<br /> <br /> CARLA &lt;http://carla.org/&gt; is an open-source driving simulator. During Q4 2019 we will be developing a go-between circuit board to transfer data between CARLA simulation and the sensor slots of the Elcano hardware. The CARLA software allows users to emulate trike parameters under controlled conditions within a virtual world, providing an efficient system for testing sensor behavior, design implementation, and benchmarking overall vehicle progression. The CARLA software can simulate a variety of road conditions such as traffic patterns, inclines, and weather as well as provide users control over vehicle parameters including weight, engine power, and aerodynamic properties.<br /> <br /> <br /> A go-between circuit board will transfer data from vehicle systems to CARLA under a variety of test conditions, enabling the software to replicate responses and return sensor data to be reevaluated for accuracy. Connecting the simulation software to components on both the high and low level boards of the Elcano trike including lidar, sonar, throttle, and brake systems, will allow users to immediately see the results of adjustments to vehicle parameters and highlight physical aspects of the trike within the virtual simulation. This project will enable users to efficiently implement improvements and track the immediate effects of design changes without spending the time and resources it would take to transport or operate the trike in real world test scenarios. It enables developers to improve the software without needing to invest in a vehicle.<br /> <br /> [[File:Architecture_CAN_Sim_7_7_20.png|1000px]]<br /> <br /> <br /> <br /> == Purpose: ==<br /> The following is a generalized list of the desired functionality of the simulator.<br /> * Simulate data for all sensors associated with Elcano Trike.<br /> * Simulate Elcano behavior to throttle, brake, and steering.<br /> * Have low and high-level boards function normally with the simulated sensor data without knowing data is being simulated.<br /> * Allow low and high-level board interaction to be tested.<br /> * Allow autonomous driving to be tested.<br /> <br /> == Components: ==<br /> ''' Simulation:''' <br /> Code to be executed by a computer that has access to a Carla server, either locally, or through a network. Controls all objects in Carla simulation. Retrieves sensor data from Carla, and sends router board. Also retrieves actuation instructions from the router board and sends to Carla.<br /> <br /> '''High Level CAN Demo''' <br /> Simple demo code for high-level board that sends drive CAN messages repeatedly to the CAN Bus.<br /> <br /> '''Elcano C2 LowLevel''' <br /> Current Elcano low-level code with minor adjustments. Adjustments discussed in detail later in doc.<br /> <br /> '''Router Board:''' <br /> Code to be executed on the Arduino Due that functions as the router board. Routes drive commands from low-level to Carla. Also routes sensor data from Carla to high/low-level boards.<br /> <br /> [[File:RouterBoard2020A.jpg|800px|]]<br /> <br /> [[File:RouterBoard2020B.jpg|800px|]]<br /> <br /> == Current Functionality of Simulation: ==<br /> At the end our Autumn 2019 Capstone, we were able to deliver a demo that demonstrated communication between all components; high-level board (Arduino Due), low-level board (Arduino Mega 2560) with shield running low level code, router board (Arduino Due), and the instance of Carla. The instructions on how to reproduce the demo will be given later in this document. The primary roadblock that prevented further development into this project was the state of the CAN system of the Elcano trike (particularly the transceiver board which seems to have a flawed design). These are the current features of the simulator.<br /> * Implementation of USB serial communication between router board and computer running simulator.py. Both entities (Computer and ArduinoDue) can send and receive data through USB connection.<br /> * Implementation of a cyclometer. Router board can receive the current speed of the simulated vehicle in Carla and convert it into an interrupt-based cyclometer pulse, based on the wheel dimension of the Elcano. Also considers the random error of cyclometer present on the Elcano trike. This can be debugged with the built-in LED on the router board.<br /> * Implementation of NMEA GPS sensor. Carla is able the output NMEA GPS data to the router board 10 times per second, effectively simulating the GPS sensor on the high-level board. Router board is successfully able to output it to UART serial which is how it is transmitted to the high-level board.<br /> * Implementation of timing structure. Computer running simulator.py waits for data to be interpreted from the router board while the router board executes its update 10 times per second. This is the desired speed for both sensor data and actuation data to be updated.<br /> * Implementation of vehicle control updaters through throttle, brake, and steering data. The computer running simulator.py can take desired throttle, brake, and steering and convert them into corresponding commands for Carla using Carla API. These commands move the vehicle within Carla. This is the primarily what the demo shows.<br /> <br /> == Demo Guide (How to Set-Up) ==<br /> The following is a guide to set up the Elcano simulator.<br /> <br /> ===''' Materials '''===<br /> * 1 Assembled Elcano Simulator Printed Circuit Board (PCB)<br /> * 2 Arduino Due<br /> * 1 Arduino Mega 2560<br /> * 1 Box (200 x 150 x 70 mm)<br /> * 2 Voltage Level Converter (included w/Simulator PCB)<br /> * 1 SD Card (w/map files)<br /> * 1 USB AB Cable (for Arduino Mega)<br /> * 1 USB Micro Cable (for Arduino Due)<br /> * 1 computer capable of running Carla<br /> <br /> ===''' Pre-installation '''===<br /> Use the following instructions to install the required software to run the simulation.<br /> <br /> #&lt;u&gt;''''' Python '''''&lt;/u&gt;<br /> #* Install Python 3 (if not installed already)<br /> #::-experiments used version 3.7.6<br /> #* In a terminal, move to .\Simulation\<br /> #* Run the command “pip3 install -r requirements.txt” to have pip install all the required python libraries for the simulator<br /> #&lt;u&gt;''''' CARLA '''''&lt;/u&gt;<br /> #*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]<br /> #*CARLA requirements:&lt;br /&gt;[[File:Carla_Requirements.jpg|500px|]]<br /> #&lt;u&gt;''''' Arduino Libraries '''''&lt;/u&gt;&lt;br /&gt;Download these Arduino libraries prior to running the simulation:<br /> #* [https://github.com/Seeed-Studio/CAN_BUS_Shield CAN_BUS_SHIELD by Seeed-Studio]<br /> #* [https://github.com/br3ttb/Arduino-PID-Library PID by Brett Beauregard]<br /> #* [https://github.com/NicoHood/PinChangeInterrupt Pin Change Interrupt by Nico Hood]<br /> #* [https://github.com/SweBarre/MCP48x2 MCP48x2 DAC by Jonas Forsberg]<br /> #* [https://github.com/ivanseidel/DueTimer Arduino Due Timer Interrupts by Ivan Seidel]<br /> #* Previous version of [https://github.com/collin80/due_can Arduino Due CAN Bus library] is used but the necessary files are included within the repository.<br /> #&lt;u&gt;''''' Elcano Repositories '''''&lt;/u&gt;&lt;br /&gt;The Elcano repositories are needed to run the simulation:<br /> #*[https://github.com/elcano/HighLevel High Level]<br /> #*[https://github.com/elcano/Simulator Simulator (Router Board &amp; Simulator Script)]<br /> #*[https://github.com/elcano/Drive-by-wire Drive-by-wire (Low Level)]<br /> ===''' Run Simulation '''===<br /> Once all the requirements are installed, use the following instructions to run the simulation. <br /> &lt;br /&gt;[[File:Router_PCB_Connections.jpg|500px]]<br /> &lt;br /&gt;&lt;br /&gt;'''''Step 1: Program all Arduinos'''''<br /> #Upload &lt;b&gt;router_board_v1.ino&lt;/b&gt; to the router Arduino Due programming port <br /> #Upload &lt;b&gt;High_Level.ino&lt;/b&gt; to the high level Arduino Due programming port<br /> #Upload &lt;b&gt;Drive_By_Wire.ino&lt;/b&gt; to the low level Arduino Mega 2560<br /> '''''Step 2: Run CARLA'''''<br /> #Open a command prompt (type cmd in the windows search box)<br /> #Go to the directory where CARLA is installed (CARLAUE4.exe)<br /> #:&lt;code&gt;cd C:\Users\bobross\Documents\ElcanoInstaller\CARLA\WindowsNoEditor&lt;/code&gt;<br /> #::-You may have it saved to a different directory<br /> #From the CARLA directory, type:<br /> #:&lt;code&gt;CARLAUE4.exe&lt;/code&gt;<br /> #:Or, to run in low resolution mode:<br /> #:&lt;code&gt;CARLAUE4.exe -ResX=720 -ResY=480 -quality-level=Low&lt;/code&gt;<br /> '''''Step 3: Run Simulation'''''<br /> #Connect your PC to the native port on the Router Board Due <br /> #Open a command prompt (type cmd in the windows search box)<br /> #Go to the Simulation directory <br /> #:&lt;code&gt;cd C:\Users\bobross\Documents\Simulator\Simulation&lt;/code&gt;<br /> #::-You may have it saved to a different directory<br /> #From Simulation directory, start the Simulator UI <br /> #:&lt;code&gt;.\Simulation\start.bat&lt;/code&gt;<br /> #By default, the Simulator UI will populate local running CARLA settings<br /> #*For control via the router board, leave mode as Auto<br /> #*To control via manual keyboard input, change mode to Manual.<br /> #*If running a network-based CARLA server, enter IP and Port of CARLA into the respective boxes. (i.e. 192.168.1.1, 2010)<br /> #Click &quot;Connect to CARLA&quot;<br /> #*If Auto mode, it will pop up a selection of COM devices, select routerboard native port COM to begin and press go. <br /> #*If Manual mode, client will start with keyboard controls (WASD)<br /> #Observe behavior in simulator. <br /> #If car gets stuck, kill current simulator.py process and restart.<br /> ===''' Debug/Logging '''===<br /> *High Level uses the Programming Port to display debug messages over serial monitor<br /> *Router Board uses the Programming Port to display debug messages over serial monitor<br /> <br /> == Out of Scope Functionality Tested/Implemented ==<br /> * Our project required us to delve into pieces of code within the Elcano project outside of our scope. Understanding of how sensors are read by the high and low-level boards is necessary for the simulation of the sensors. We were able to fix some issues regarding the CAN communication between the high and low-level boards. The modified low-level code was not pushed to the main low-level code folder in the repository on Github, however, it is included within the simulator documentation. The following were implemented.<br /> * Unification of the proposed CAN message structure and the actual CAN message processing on the low-level code for CAN messages with ID 0x350 (High-level drive instructions). These are CAN messages the high-level will send to the low level to facilitate autonomy.<br /> * Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.<br /> == To Do (Software): ==<br /> ''' High Priority: '''<br /> * Simulate gyro sensor<br /> * Simulate accelerometer/magnetometer sensor.<br /> * Simulate wheel angle sensor.<br /> * Implement steering actuation when low-level CAN processing of steering command is fixed.<br /> * Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.<br /> ''' Medium Priority: '''<br /> * Simulate ScanseSweep.<br /> * Implement receiver board when board is fully fixed.<br /> * Incorporate Elcano trike physics to simulated vehicle.<br /> ''' Low Priority '''<br /> * Simulate camera sensor.<br /> == Bugs Within Simulator ==<br /> * Occasionally the simulator and router board will desync and the NMEA GPS messages received by the router board will be faulty. This is usually followed by a crash of simulator.py. If not, simply press Ctrl^C and restart simulator.py.<br /> * If simulator.py unexpectedly terminates, the created actors and sensors in Carla will not be properly destroyed. This usually does not cause problems for the simulation but proper termination in the future would be safer. For now if it is causing problems simply restart Carla.<br /> * Carla will never stop outputting sensor data even if asked to stop. This is a bug with Carla and not in our scope.<br /> * Most malfunctions can be temporarily fixed by restarting the simulator.py instance.<br /> == Other Elcano Bugs Found ==<br /> * While we were able to fix the code for the low-level CAN interpretation of the throttle and brake commands from high-level CAN messages, the PWM steering response was not fully tested. We were unable to get the low-level board to output the correct PWM for the sent CAN messages and this needs more testing.<br /> * The receiver board cannot get CAN to initialize. Voltage testing confirmed that the CAN components (MCP2515 and MCP 2550) are receiving the correct operating voltages (5v). Also, multiple CAN libraries besides the suggested Seeed Studio library were tested with no success (SparkFun CAN library was one of the tested libraries). Possible problem is incompatibility between the 5v CAN components and the 3.3V SAMD21 board. Another possible problem is design flaw of pcb.<br /> * Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.<br /> == Additional Notes ==<br /> * Currently, the order that you output data from the router board to the computer running simulator.py is non-trivial. Data is interpreted based on the order which it is received.<br /> * Carla sensor listening was flawed at the time this was made; .stop() would not stop the sensor from executing its attached function at each tick of Carla. Therefore speed was implemented without the use of sensors, and instead uses a command that accesses the speed only when needed. This is the suggested method until sensors are fixed. Certain sensors such as NMEA GPS, however, are only implementable using Carla sensors. Additional information can be found on Carla Documentation.<br /> * In PowerShell, in CarlaUE4 path, run Carla as: ***Start-Process CarlaUE4 -ArgumentList “—quality-level=Low”*** to lower gpu load.<br /> * Headless mode can be enabled for complete removal of graphics rendering, however, visual debugging is extremely useful.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=File:Architecture_CAN_Sim_7_7_20.png&diff=340 2020-07-14T04:13:07Z

<p>Tfolsom: Revised simulator diagram; omits sensors.</p> <hr /> <div>== Summary ==<br /> Revised simulator diagram; omits sensors.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Simulator&diff=339 2020-07-14T04:10:45Z

<p>Tfolsom: </p> <hr /> <div>= Elcano Carla Simulation External Specification =<br /> <br /> CARLA &lt;http://carla.org/&gt; is an open-source driving simulator. During Q4 2019 we will be developing a go-between circuit board to transfer data between CARLA simulation and the sensor slots of the Elcano hardware. The CARLA software allows users to emulate trike parameters under controlled conditions within a virtual world, providing an efficient system for testing sensor behavior, design implementation, and benchmarking overall vehicle progression. The CARLA software can simulate a variety of road conditions such as traffic patterns, inclines, and weather as well as provide users control over vehicle parameters including weight, engine power, and aerodynamic properties.<br /> <br /> <br /> A go-between circuit board will transfer data from vehicle systems to CARLA under a variety of test conditions, enabling the software to replicate responses and return sensor data to be reevaluated for accuracy. Connecting the simulation software to components on both the high and low level boards of the Elcano trike including lidar, sonar, throttle, and brake systems, will allow users to immediately see the results of adjustments to vehicle parameters and highlight physical aspects of the trike within the virtual simulation. This project will enable users to efficiently implement improvements and track the immediate effects of design changes without spending the time and resources it would take to transport or operate the trike in real world test scenarios. It enables developers to improve the software without needing to invest in a vehicle.<br /> <br /> [[File:Simulator_Block_Diagram_V2.png|1000px]]<br /> <br /> <br /> <br /> == Purpose: ==<br /> The following is a generalized list of the desired functionality of the simulator.<br /> * Simulate data for all sensors associated with Elcano Trike.<br /> * Simulate Elcano behavior to throttle, brake, and steering.<br /> * Have low and high-level boards function normally with the simulated sensor data without knowing data is being simulated.<br /> * Allow low and high-level board interaction to be tested.<br /> * Allow autonomous driving to be tested.<br /> <br /> == Components: ==<br /> ''' Simulation:''' <br /> Code to be executed by a computer that has access to a Carla server, either locally, or through a network. Controls all objects in Carla simulation. Retrieves sensor data from Carla, and sends router board. Also retrieves actuation instructions from the router board and sends to Carla.<br /> <br /> '''High Level CAN Demo''' <br /> Simple demo code for high-level board that sends drive CAN messages repeatedly to the CAN Bus.<br /> <br /> '''Elcano C2 LowLevel''' <br /> Current Elcano low-level code with minor adjustments. Adjustments discussed in detail later in doc.<br /> <br /> '''Router Board:''' <br /> Code to be executed on the Arduino Due that functions as the router board. Routes drive commands from low-level to Carla. Also routes sensor data from Carla to high/low-level boards.<br /> <br /> [[File:RouterBoard2020A.jpg|800px|]]<br /> <br /> [[File:RouterBoard2020B.jpg|800px|]]<br /> <br /> == Current Functionality of Simulation: ==<br /> At the end our Autumn 2019 Capstone, we were able to deliver a demo that demonstrated communication between all components; high-level board (Arduino Due), low-level board (Arduino Mega 2560) with shield running low level code, router board (Arduino Due), and the instance of Carla. The instructions on how to reproduce the demo will be given later in this document. The primary roadblock that prevented further development into this project was the state of the CAN system of the Elcano trike (particularly the transceiver board which seems to have a flawed design). These are the current features of the simulator.<br /> * Implementation of USB serial communication between router board and computer running simulator.py. Both entities (Computer and ArduinoDue) can send and receive data through USB connection.<br /> * Implementation of a cyclometer. Router board can receive the current speed of the simulated vehicle in Carla and convert it into an interrupt-based cyclometer pulse, based on the wheel dimension of the Elcano. Also considers the random error of cyclometer present on the Elcano trike. This can be debugged with the built-in LED on the router board.<br /> * Implementation of NMEA GPS sensor. Carla is able the output NMEA GPS data to the router board 10 times per second, effectively simulating the GPS sensor on the high-level board. Router board is successfully able to output it to UART serial which is how it is transmitted to the high-level board.<br /> * Implementation of timing structure. Computer running simulator.py waits for data to be interpreted from the router board while the router board executes its update 10 times per second. This is the desired speed for both sensor data and actuation data to be updated.<br /> * Implementation of vehicle control updaters through throttle, brake, and steering data. The computer running simulator.py can take desired throttle, brake, and steering and convert them into corresponding commands for Carla using Carla API. These commands move the vehicle within Carla. This is the primarily what the demo shows.<br /> <br /> == Demo Guide (How to Set-Up) ==<br /> The following is a guide to set up the Elcano simulator.<br /> <br /> ===''' Materials '''===<br /> * 1 Assembled Elcano Simulator Printed Circuit Board (PCB)<br /> * 2 Arduino Due<br /> * 1 Arduino Mega 2560<br /> * 1 Box (200 x 150 x 70 mm)<br /> * 2 Voltage Level Converter (included w/Simulator PCB)<br /> * 1 SD Card (w/map files)<br /> * 1 USB AB Cable (for Arduino Mega)<br /> * 1 USB Micro Cable (for Arduino Due)<br /> * 1 computer capable of running Carla<br /> <br /> ===''' Pre-installation '''===<br /> Use the following instructions to install the required software to run the simulation.<br /> <br /> #&lt;u&gt;''''' Python '''''&lt;/u&gt;<br /> #* Install Python 3 (if not installed already)<br /> #::-experiments used version 3.7.6<br /> #* In a terminal, move to .\Simulation\<br /> #* Run the command “pip3 install -r requirements.txt” to have pip install all the required python libraries for the simulator<br /> #&lt;u&gt;''''' CARLA '''''&lt;/u&gt;<br /> #*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]<br /> #*CARLA requirements:&lt;br /&gt;[[File:Carla_Requirements.jpg|500px|]]<br /> #&lt;u&gt;''''' Arduino Libraries '''''&lt;/u&gt;&lt;br /&gt;Download these Arduino libraries prior to running the simulation:<br /> #* [https://github.com/Seeed-Studio/CAN_BUS_Shield CAN_BUS_SHIELD by Seeed-Studio]<br /> #* [https://github.com/br3ttb/Arduino-PID-Library PID by Brett Beauregard]<br /> #* [https://github.com/NicoHood/PinChangeInterrupt Pin Change Interrupt by Nico Hood]<br /> #* [https://github.com/SweBarre/MCP48x2 MCP48x2 DAC by Jonas Forsberg]<br /> #* [https://github.com/ivanseidel/DueTimer Arduino Due Timer Interrupts by Ivan Seidel]<br /> #* Previous version of [https://github.com/collin80/due_can Arduino Due CAN Bus library] is used but the necessary files are included within the repository.<br /> #&lt;u&gt;''''' Elcano Repositories '''''&lt;/u&gt;&lt;br /&gt;The Elcano repositories are needed to run the simulation:<br /> #*[https://github.com/elcano/HighLevel High Level]<br /> #*[https://github.com/elcano/Simulator Simulator (Router Board &amp; Simulator Script)]<br /> #*[https://github.com/elcano/Drive-by-wire Drive-by-wire (Low Level)]<br /> ===''' Run Simulation '''===<br /> Once all the requirements are installed, use the following instructions to run the simulation. <br /> &lt;br /&gt;[[File:Router_PCB_Connections.jpg|500px]]<br /> &lt;br /&gt;&lt;br /&gt;'''''Step 1: Program all Arduinos'''''<br /> #Upload &lt;b&gt;router_board_v1.ino&lt;/b&gt; to the router Arduino Due programming port <br /> #Upload &lt;b&gt;High_Level.ino&lt;/b&gt; to the high level Arduino Due programming port<br /> #Upload &lt;b&gt;Drive_By_Wire.ino&lt;/b&gt; to the low level Arduino Mega 2560<br /> '''''Step 2: Run CARLA'''''<br /> #Open a command prompt (type cmd in the windows search box)<br /> #Go to the directory where CARLA is installed (CARLAUE4.exe)<br /> #:&lt;code&gt;cd C:\Users\bobross\Documents\ElcanoInstaller\CARLA\WindowsNoEditor&lt;/code&gt;<br /> #::-You may have it saved to a different directory<br /> #From the CARLA directory, type:<br /> #:&lt;code&gt;CARLAUE4.exe&lt;/code&gt;<br /> #:Or, to run in low resolution mode:<br /> #:&lt;code&gt;CARLAUE4.exe -ResX=720 -ResY=480 -quality-level=Low&lt;/code&gt;<br /> '''''Step 3: Run Simulation'''''<br /> #Connect your PC to the native port on the Router Board Due <br /> #Open a command prompt (type cmd in the windows search box)<br /> #Go to the Simulation directory <br /> #:&lt;code&gt;cd C:\Users\bobross\Documents\Simulator\Simulation&lt;/code&gt;<br /> #::-You may have it saved to a different directory<br /> #From Simulation directory, start the Simulator UI <br /> #:&lt;code&gt;.\Simulation\start.bat&lt;/code&gt;<br /> #By default, the Simulator UI will populate local running CARLA settings<br /> #*For control via the router board, leave mode as Auto<br /> #*To control via manual keyboard input, change mode to Manual.<br /> #*If running a network-based CARLA server, enter IP and Port of CARLA into the respective boxes. (i.e. 192.168.1.1, 2010)<br /> #Click &quot;Connect to CARLA&quot;<br /> #*If Auto mode, it will pop up a selection of COM devices, select routerboard native port COM to begin and press go. <br /> #*If Manual mode, client will start with keyboard controls (WASD)<br /> #Observe behavior in simulator. <br /> #If car gets stuck, kill current simulator.py process and restart.<br /> ===''' Debug/Logging '''===<br /> *High Level uses the Programming Port to display debug messages over serial monitor<br /> *Router Board uses the Programming Port to display debug messages over serial monitor<br /> <br /> == Out of Scope Functionality Tested/Implemented ==<br /> * Our project required us to delve into pieces of code within the Elcano project outside of our scope. Understanding of how sensors are read by the high and low-level boards is necessary for the simulation of the sensors. We were able to fix some issues regarding the CAN communication between the high and low-level boards. The modified low-level code was not pushed to the main low-level code folder in the repository on Github, however, it is included within the simulator documentation. The following were implemented.<br /> * Unification of the proposed CAN message structure and the actual CAN message processing on the low-level code for CAN messages with ID 0x350 (High-level drive instructions). These are CAN messages the high-level will send to the low level to facilitate autonomy.<br /> * Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.<br /> == To Do (Software): ==<br /> ''' High Priority: '''<br /> * Simulate gyro sensor<br /> * Simulate accelerometer/magnetometer sensor.<br /> * Simulate wheel angle sensor.<br /> * Implement steering actuation when low-level CAN processing of steering command is fixed.<br /> * Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.<br /> ''' Medium Priority: '''<br /> * Simulate ScanseSweep.<br /> * Implement receiver board when board is fully fixed.<br /> * Incorporate Elcano trike physics to simulated vehicle.<br /> ''' Low Priority '''<br /> * Simulate camera sensor.<br /> == Bugs Within Simulator ==<br /> * Occasionally the simulator and router board will desync and the NMEA GPS messages received by the router board will be faulty. This is usually followed by a crash of simulator.py. If not, simply press Ctrl^C and restart simulator.py.<br /> * If simulator.py unexpectedly terminates, the created actors and sensors in Carla will not be properly destroyed. This usually does not cause problems for the simulation but proper termination in the future would be safer. For now if it is causing problems simply restart Carla.<br /> * Carla will never stop outputting sensor data even if asked to stop. This is a bug with Carla and not in our scope.<br /> * Most malfunctions can be temporarily fixed by restarting the simulator.py instance.<br /> == Other Elcano Bugs Found ==<br /> * While we were able to fix the code for the low-level CAN interpretation of the throttle and brake commands from high-level CAN messages, the PWM steering response was not fully tested. We were unable to get the low-level board to output the correct PWM for the sent CAN messages and this needs more testing.<br /> * The receiver board cannot get CAN to initialize. Voltage testing confirmed that the CAN components (MCP2515 and MCP 2550) are receiving the correct operating voltages (5v). Also, multiple CAN libraries besides the suggested Seeed Studio library were tested with no success (SparkFun CAN library was one of the tested libraries). Possible problem is incompatibility between the 5v CAN components and the 3.3V SAMD21 board. Another possible problem is design flaw of pcb.<br /> * Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.<br /> == Additional Notes ==<br /> * Currently, the order that you output data from the router board to the computer running simulator.py is non-trivial. Data is interpreted based on the order which it is received.<br /> * Carla sensor listening was flawed at the time this was made; .stop() would not stop the sensor from executing its attached function at each tick of Carla. Therefore speed was implemented without the use of sensors, and instead uses a command that accesses the speed only when needed. This is the suggested method until sensors are fixed. Certain sensors such as NMEA GPS, however, are only implementable using Carla sensors. Additional information can be found on Carla Documentation.<br /> * In PowerShell, in CarlaUE4 path, run Carla as: ***Start-Process CarlaUE4 -ArgumentList “—quality-level=Low”*** to lower gpu load.<br /> * Headless mode can be enabled for complete removal of graphics rendering, however, visual debugging is extremely useful.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=File:Architecture_CAN.png&diff=338 2020-07-14T03:40:28Z

<p>Tfolsom: Tfolsom uploaded a new version of File:Architecture CAN.png</p> <hr /> <div>== Summary ==<br /> System Architecture connected by CAN bus</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=File:Architecture_CAN.png&diff=337 2020-07-14T03:32:26Z

<p>Tfolsom: Tfolsom uploaded a new version of File:Architecture CAN.png</p> <hr /> <div>== Summary ==<br /> System Architecture connected by CAN bus</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Camera&diff=336 2020-06-25T22:42:46Z

<p>Tfolsom: /* Hardware */</p> <hr /> <div><br /> <br /> = Camera Sensor =<br /> <br /> == Hardware ==<br /> <br /> Elcano system uses a Pi Cam version 2 camera designed to connect to the Raspberry Pi CSI camera port. The Raspberry Pi connected to the camera is the vision processor in the Elcano system and communicates with other processors and boards using CAN bus. We use https://copperhilltech.com/pican-2-can-bus-interface-for-raspberry-pi/ The Pi Cam mounts on the front of the Elcano trike and software on the Raspberry Pi performs visual functions like lane detection and cone detection.<br /> <br /> == Functions ==<br /> <br /> === Visual Traffic Cone Ranging ===<br /> <br /> The Camera sensor is an essential part of optical object detection and ranging. In order to know the distance to an object like a traffic cone, traffic cone detection software running on a Raspberry Pi can identify the outline of a traffic cone and determine distance of the cone using the cone outline's height in the image. It is possible to know the range to an object of known height using the camera's known characteristics.<br /> <br /> {|<br /> |-<br /> |*Camera Model*||*Focal length (mm)*||*Pixel dimensions (um)*<br /> |-<br /> |Pi Cam v1.x||3.5||1.4 x 1.4<br /> |-<br /> |Pi Cam v2.x||3.0||1.12 x 1.12<br /> |}<br /> <br /> ''These are values provided in Pi Cam documentation. These are designed dimensions and may not be accurate from camera to camera.''<br /> <br /> The vision processor is a Raspberry PI, and the camera is the Pi camera.<br /> Raspberry Pi v1.x camera has focal length of 3.6 mm and pixel size of 1.4 x 1.4 um. Cone height is 0.46 m. If cone height in image is N pixels, then by similar triangles,<br /> 3.6 mm / (N * 0.0014 mm) = range / 0.46 m.<br /> <br /> range = 3.6 * 0.46 m / (N * 0.0014)<br /> <br /> === Visual Traffic Cone Angle ===<br /> <br /> Calculating angle relies on similar principles as calculating range. Before converting horizontal or vertical position into angle, we have to know the camera's real focal length and pixel size. From this we can use trigonometry to calculate degrees per pixel.<br /> <br /> Optional: first estimate degrees per pixel by dividing the horizontal field of view (often available in the device's documentation) by the camera's horizontal pixel count:<br /> <br /> Degrees / pixel = (horizontal field of view) / (horizontal pixel count)<br /> <br /> Example: 62.2 degrees / 3280 pixels = 0.0190 degrees per pixel, equivalent to 52.7 pixels per degree.<br /> <br /> Now calculate the degrees per pixel using the focal length, pixel size, and data from the range calculations described in &quot;Visual Traffic Cone Ranging&quot;:<br /> <br /> Tan(degrees) = (Object height in meters) / (Object range in meters)<br /> <br /> Degrees = Tanh( height / range)<br /> <br /> Pixels = (focal length * height) / (pixel size * range)<br /> <br /> Degrees / pixel = Degrees / pixel<br /> <br /> Compare your calculated deg / px to the estimated deg / px. The numbers should be similar but will not be the same unless your image is corrected for lens distortion.<br /> <br /> To find the horizontal degree offset of an object using its center point, first find the object's offset from center:<br /> <br /> Horizontal offset in pixels= (object horizontal center in image) - (image width / 2)<br /> <br /> Horizontal offset in degrees = (Horizontal Offset) * (degrees / pixel) <br /> <br /> The horizontal offset in degrees will be positive when the object is right of center and negative when the object is left of center. <br /> <br /> ==== Experimentally finding focal length and pixel size ====<br /> <br /> Pi Cam and other similar products have designed focal length and pixel size dimensions in their respective specification sheets. These documented numbers are nominal (official) values that may be different from real (actual) values. If these nominal values are used in range calculations, the returned range values can be bigger or smaller than in reality. To correct for this, we can calculate a camera's ratio of focal length to pixel size using a formula derived from the similar triangles ratios.<br /> <br /> The ratio of a Camera's focal length to its pixel size is part of the similar triangles formula:<br /> <br /> focal_length / (N * pixel_size) = range / 0.46 m<br /> <br /> We can characterize the ratio of focal length to pixel size by taking a picture of a traffic cone (or other object of known height) at a known distance. Using the known distance, height, and number of pixels in our calibration image, we can calculate focal length and pixel size as a ratio:<br /> <br /> focal_length / pixel_size = N * range / 0.46 m<br /> <br /> A camera with a focal length of 3.5mm and pixel size of 1.4um has a focal_length / pixel_size of 2500. This is unit-less because we divide meters by meters. We used the method described above to determine an actual Pi Cam version 1.x camera had a focal_length / pixel_size ratio of ~1900, equal to a 1.4um pixel size and 2.7mm focal length. This real value allows accurate range calculations with a specific camera and does not transfer to other hardware of the same version.<br /> <br /> === Expected world coordinates ===<br /> <br /> The C6 Arduino communicates with the Raspberry Pi over serial lines. The Arduino sends the expected world coordinate position of the cone in the format <br /> <br /> G {n Num} {p EPosMeters,NPosMeters} {b Deg}<br /> <br /> and the current position of the trike as <br /> <br /> S {p EPosMeters,NPosMeters} {b Deg}<br /> <br /> The Pi returns the position of the cone as<br /> <br /> G {n Num} {p EPosMeters,NPosMeters} {b Deg} {r Probability}<br /> <br /> These formats are documented in GitHub under Documentation / SerialCmd.html.<br /> <br /> The Pi needs to translate world coordinates to pixel coordinates (and back) using the 3D matrix transformations given in Computer Graphics: Principles and Practice (2nd ed. Foley, Van Dam, Feiner, Hughes; or 3rd ed. Hughes et al.)<br /> <br /> <br /> -- Main.TylerCFolsom - 2017-06-16<br /> <br /> ALSO &gt; [[VisionPage]]<br /> <br /> NEXT &gt; [[ActuatorPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=High_Level&diff=335 2020-06-08T21:03:17Z

<p>Tfolsom: </p> <hr /> <div>The High Level system has been renamed &quot;Sensor Hub&quot;. Documentation in divided into the software and hardware.<br /> <br /> ==[[HighLevelSWv3]]==<br /> ==[[HighLevelHWv3]]==<br /> [[File:HighLevel.JPG|1000px]]<br /> <br /> NEXT &gt; [[SensorsPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Low_Level&diff=334 2020-06-08T21:00:00Z

<p>Tfolsom: </p> <hr /> <div><br /> =LowLevel v3.1 PCB =<br /> <br /> <br /> ==Functionality: ==<br /> <br /> * The LowLevel Board (LLB) is a daughter board (shield) for an Arduino Mega microcontroller. It has been renamed &quot;Drive-By-Wire&quot;. It implements drive-by-wire, turning a trike into a CAN-bus based vehicle compatible with commercial self-driving equipment. The LLB communicates over the CAN bus with the higher-level autonomous system or manual control from the receiver system. It directly manages the actuators: the throttle to the motor, the turning servo, and the brakes. <br /> <br /> <br /> * Motion directives are received on a CAN bus interface, processed, and articulated.<br /> * System status (turn angle, wheel linear velocity) is reported back to CAN bus.<br /> <br /> * LLB v3.x has the following interfaces:<br /> ** One CANbus channel on two connectors; a DB9-M and a three-pin screw terminal. The board includes a 120 ohm terminating resistor.<br /> ** X3 Motor (DB-15M): Interface to E-bike controller<br /> *** Analog voltage (approximately 0v to 4v) output to hub motor throttle<br /> *** Digital outputs for activating reverse and regenerative braking.<br /> *** PWM output for PWM-operated braking (no longer used)<br /> *** Analog inputs for hall sensor feedback from motor controllers supporting this feature. These inputs are NOT 5V SAFE. They absolutely require external supporting circuitry.<br /> *** A few spare connections for future expandability, such as a second DAC output and one digital GPIO.<br /> <br /> DETAILS &gt; [[DB15M]]<br /> <br /> ** Steering Header (RJ45): <br /> *** Two sets of pins to support analog potentiometers (5v, signal input, ground) giving angle of front wheels<br /> *** One PWM output (with its own ground) to drive the steering actuator.<br /> *** This cable is broken out into its component signals using an RJ45 patch jack, mounted near the steering actuator.<br /> ** X4 (ODO): Cyclometer (reed switch) input jack. This is pulled high by default, and brought low when the magnet passes the sensor.<br /> ** High current pluggable terminal for solenoid brakes:<br /> *** Connections for ground, 12v, and 24v.<br /> *** Two relay outputs to solenoids: on/off and 12/24V.<br /> <br /> * The LowLevel runs on 5V power, and provides outputs for sensors. Note that the Arduino Mega 2560's regulator has a fairly low current limit, and should not be used for any significant current supply. The Arduino's DC input jack accepts 12V, and its USB port may be connected to a typical USB power supply. The 12V is provided by a DC-DC converter from the main battery (36 to 50V).<br /> <br /> ==Image: [[File:LowLevel.JPG|1000px]] ==<br /> <br /> <br /> NEXT &gt; [[High Level]]<br /> <br /> =LowLevel v2.1 PCB =<br /> <br /> <br /> <br /> ==Functionality: ==<br /> <br /> * Version 2.1 used UART serial connections to other boards instead of the CAN bus. It interprets messages from higher-level autonomous systems or manual controls (RC, joystick). It directly manages the state of the actuators; the hub motor, the turning servo, and the brakes. <br /> <br /> <br /> * Depending on the current firmware or operating mode, motion directives are received on one of three interfaces;<br /> ** [[ElcanoSerial]] from the combined [[PilotPage | C3]]/[[PlannerPage | C4]]/[[NavigatorPage | C6]] High Level board <br /> ** RC receiver<br /> ** Manual Joystick<br /> <br /> * LLB v2.x has the following low-level interfaces:<br /> ** X2 Cruise (DB-25F) - [[ElcanoSerial]] messages from High Level.<br /> ** X3 Motor ([[DB15M | DB-15M]]): Analog voltage (0,4v) output hub motor.<br /> ** X1/X5 Turn Sensors (RJ45): SPI wheel angle sensor digital inputs. (Digital urn sensors were never implemented.)<br /> ** X4 (ODO): Cyclometer (reed switch) input jack. Board layout was incorrect. This signal needs to be jumpered to Arduino pin D2.<br /> ** JP9 (8 pin): Joystick analog input signals. <br /> ** JP12 (3 pin): Pulse output signal to steer. <br /> ** JP11 (3 pin): Pulse output signal to apply main brakes. (No longer used)<br /> ** JP5 (4 pin): Left wheel angle sensor analog input. (Little used since it covers 360 degrees and is less accurate)<br /> ** JP6 (4 pin): Right wheel angle sensor analog input. (Trike prefer this, since it is +/- 30 degrees, and more accurate)<br /> <br /> * LLB v3.x makes significant wiring changes:<br /> ** Removes the ElcanoSerial connection and the DB-25F.<br /> ** Removes JP9, joystick analog inputs.<br /> ** Removes headers used to interface the RC receiver.<br /> ** Adds one CANbus interface on a DE-9F socket. For legacy compatibility UART serial is be available on this interface as well.<br /> <br /> <br /> =LowLevel v1.0 PCB =<br /> <br /> * The first version of the LLB was called MegaShieldDB. It had similar functionality, but different connectors. It had five DB connectors.<br /> <br /> <br /> NEXT &gt; [[High Level]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Main_Page&diff=333 2020-06-08T20:57:34Z

<p>Tfolsom: </p> <hr /> <div><br /> <br /> = Welcome to the Elcano Project Wiki =<br /> As the title says, WELCOME TO THE ELCANO PROJECT! Over the past few years many different teams have been working hard to create Cheap and Modular autonomy at the University of Washington Bothell. We are currently working on our first two prototypes which are now in the form of tricycles. With the use of affordable microcontrollers, such as the Arduino Mega 2560 and Raspberry PI, we are working towards creating Autonomy for anyone to rebuild anywhere, and that under $2000 and fully open-source. But we don't plan to stop there, no. That is just the first step in reaching our ultimate goal, which is making our systems applicable to any desired ground vehicles, such as cars and other vehicles. Autonomy is nothing new, in fact it has been around for over 40 years, the difference is that now we have the ability to make it available for anyone who desires furthering their knowledge or simply finding a safer way to work.<br /> <br /> To '''edit articles''' or '''upload files''', please create an account and request editing rights from a [//www.elcanoproject.org/wiki/index.php?title=Special:ListUsers&amp;group=bureaucrat member of the &quot;bureaucrat&quot; group].<br /> <br /> For editing help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.<br /> --------<br /> [[File:Catrikes.JPG|1000px]]<br /> == [[ElcanoIntro | Overview]] ==<br /> Basic concept of how the Elcano Project vehicle works.<br /> <br /> == [[System Architecture]] ==<br /> How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.<br /> <br /> == [[Communication | Communication (CAN Bus)]] ==<br /> How processors exchange data on the vehicle and a description of data packet contents.<br /> <br /> == [[Power System]] ==<br /> How different modules connect to the batteries or power subsystem hardware.<br /> <br /> == [[Low Level]] ==<br /> How the Low Level system (aka Drive-By_Wire) uses inputs to control actuators to steer, move, and stop the vehicle.<br /> <br /> == [[High Level]] ==<br /> How the High Level (aka Sensor Hub) system uses stored maps and inputs from navigational sensors to formulate movement instructions sent to Low Level.<br /> <br /> == [[RemoteControl]] ==<br /> Human control of trike movements through Low Level using hardware connected to Low Level by a radio communication link (drive by radio). Includes on-board controls (drive by wire).<br /> <br /> == [[ Simulator]] ==<br /> Using Open-source CARLA platform with a go-between board allows simulation.<br /> <br /> == [[SensorsPage]] ==<br /> <br /> === [[SteeringSensor]] ===<br /> The front wheel angle detector.<br /> <br /> === [[Sonar]] === <br /> How the sonar subsystem connected to High Level works.<br /> <br /> === [[Lidar]] ===<br /> How the lidar subsystem connected to High Level works.<br /> <br /> === [[ Camera]] ===<br /> How the camera and vision subsystem connected to High Level works.<br /> <br /> == [[ActuatorPage]] ==<br /> <br /> == [[ Board Diagrams]] ==<br /> Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].<br /> <br /> == Software development procedures ==<br /> <br /> === [[Software repositories]] ===<br /> What's in each of our GitHub repositories.<br /> <br /> === [[Arduino software]] ===<br /> Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.<br /> <br /> === [[Using Git and GitHub]] ===<br /> Practices for maintaining code and source files on Elcano Project's GitHub repositories.<br /> <br /> ==[[FilesPage | Files]] ==<br /> These are media files (pictures, videos, etc.) that are part of the project, but are not maintained under version control.<br /> <br /> == Elcano Project Main Website ==<br /> * [//www.elcanoproject.org]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=ElcanoSerial&diff=325 2020-05-29T18:13:59Z

<p>Tfolsom: </p> <hr /> <div><br /> <br /> == OBSOLETE ==<br /> <br /> UART Serial communication has been replaced by CAN bus serial communication.<br /> <br /> Tyler Folsom May 30, 2020<br /> <br /> <br /> == Abstract ==<br /> <br /> The library is meant to send a packet of data from one Arduino in the system to the next over serial connections.<br /> <br /> When a connection is normally made, the Arduino must block until it has finished reading a continuous block of text. However, as these are nearly-real time embedded systems, we cannot do this, and it must read the data asynchronously.<br /> <br /> The way that we chose to do this was with a state machine that can update one character at a time without loosing track of where it is in the processing stage. As a result, the data is updated in such a way that no blocking is required between reads, and if a batch of data is not fully read at the right time, the device can come back and keep going later.<br /> <br /> The &lt;tt&gt;ParseState&lt;/tt&gt; data structure contains a pointer to the resulting data (where it places information it has read from the input), and a flag that tells the state machine what part of the structure it is currently at.<br /> <br /> The Arduinos are arranged into a ring, so that all data will eventually reach its target, as the Arduinos pass data they don't need back into the ring.<br /> <br /> == Data Format ==<br /> <br /> A message shall always begin with 1 header character ('D', 'S', 'G', or 'X').<br /> <br /> The message body shall consist of 0 or more flags, up to a maximum of 7 (which is the number of distinct attribute types). No single attribute type can be used for 2 or more flags in 1 message.<br /> <br /> Flags shall consist of the left curly bracket ('{'), followed in order by an attribute type character ('n', 's', 'a', 'o', 'b', 'r', 'p'), and by 1 value (in the case of 'n', 's', 'a', 'o', 'b', 'r') or by 2 values (in the case of 'p'). The order of given flags is not significant. For the number, sensor, angle, bearing, and probability attribute types, the value is a single decimal number composed of, optionally, an ASCII hyphen-minus character ('-') (for negative integers), followed by the ASCII characters '0' through '9'. For the &quot;Position&quot; attribute type, the values are 2 such decimal numbers separated by a comma (',').<br /> <br /> Each message type uses a subset of the available attribute types. Any flag that contains an attribute that is incompatible with the given message type will be ignored.<br /> <br /> The message ends with an 8-bit SMBUS CRC checksum, followed by a newline ('\n') character. Other space characters have no significance to the message.<br /> <br /> === Header Types ===<br /> <br /> {| cellpadding=&quot;5&quot; cellspacing=&quot;0&quot; border=&quot;1&quot;<br /> |-<br /> || *Header Type* || *Character* || *Purpose* || *Used Attribute Types* <br /> |-<br /> || Drive || 'D' || Sends data to [[C2]] || Speed, Angle <br /> |-<br /> || Sensor || 'S' || Sends data to [[C3]] and [[C6]] || Speed, Angle, Obstacle, Bearing, Position <br /> |-<br /> || Goal || 'G' || Communicates the location of an object to [[C4]] || Number, Bearing, Probability, Position <br /> |-<br /> || Segment || 'X' || Communicates part of the navigation path to [[C3]] || Number, Speed, Bearing, Position <br /> <br /> |}<br /> <br /> === Attribute Types ===<br /> <br /> {| cellpadding=&quot;5&quot; cellspacing=&quot;0&quot; border=&quot;1&quot;<br /> |-<br /> || *Attribute Type* || *Character* <br /> |-<br /> || Number || 'n' <br /> |-<br /> || Speed || 's' <br /> |-<br /> || Angle || 'a' <br /> |-<br /> || Obstacle || 'o' <br /> |-<br /> || Bearing || 'b' <br /> |-<br /> || Probability || 'r' <br /> |-<br /> || Position || 'p' <br /> <br /> |}<br /> <br /> === Message Examples ===<br /> <br /> (Without checksums)<br /> <br /> &lt;pre&gt;<br /> D{s 300}{a 0}\n<br /> &lt;/pre&gt;<br /> <br /> In the above example, 'D' is the header, followed by a body which contains the flags '{s 300}' and '{a 0}'.<br /> <br /> &lt;pre&gt;<br /> S {s 256} {b45} {a30} {p 0, 0} {r 56} \n<br /> &lt;/pre&gt;<br /> In the above example, the spaces and the order of the flags do not matter. Because the Sensor message type does not use the Probability attribute type, the Probability flag is ignored.<br /> <br /> &lt;pre&gt;<br /> X\n<br /> &lt;/pre&gt;<br /> The above example is a valid message, but it is useless.<br /> <br /> === Parsing Expression Grammar ===<br /> <br /> '''Note:''' This section does not take into account space characters or the checksum.<br /> <br /> A PEG for the data that gets passed around is as follows:<br /> <br /> &lt;pre&gt;<br /> ('D' / 'S' / 'G' / 'X') ('{' ('n' / 's' / 'a' / 'o' / 'b' / 'r') '-'? [0-9]+ '}')+<br /> \--------header-------/ \-------------------------body---------------------------/<br /> \------------attribute------------/ \value(s)-/<br /> &lt;/pre&gt;<br /> <br /> The various components of the string have been labeled for your convenience.<br /> <br /> This PEG does not include the Position attribute type ('p'), which sends a pair of numbers. Replace the body section of the PEG with this:<br /> <br /> &lt;tt&gt;'{' 'p' '-'? [0-9]+ ',' '-'? [0-9]+ '}'&lt;/tt&gt;<br /> <br /> Any spaces sent are ignored by the parser. Given all of the above, a complete PEG would look like the following:<br /> <br /> &lt;pre&gt;<br /> Message = ('D' / 'S' / 'G' / 'X') ('{' (<br /> ('n' / 's' / 'a' / 'o' / 'b' / 'r') '-'? [0-9]+<br /> / 'p' '-'? [0-9]+ ',' '-'? [0-9]+<br /> ) '}')+<br /> &lt;/pre&gt;<br /> <br /> This may be of use to you if you need to re-implement this in the future.<br /> <br /> == Code Skeleton ==<br /> <br /> Here is some example code, which you can use as a skeleton for writing your own stuff.<br /> <br /> &lt;pre&gt;<br /> #include &lt;ElcanoSerial.h&gt;<br /> <br /> elcano::ParseState ps;<br /> elcano::SerialData dt;<br /> <br /> void setup() {<br /> Serial1.begin(elcano::baudrate);<br /> Serial2.begin(elcano::baudrate);<br /> <br /> ps.dt = &amp;dt;<br /> ps.input = &amp;Serial1;<br /> ps.output = &amp;Serial2;<br /> ps.capture = elcano::MsgType::DESIRED_TYPE;<br /> dt.clear();<br /> <br /> // Any other initialization code goes here<br /> }<br /> <br /> void loop1() {<br /> // Update code here that depends on having received a data set<br /> }<br /> <br /> void loop2() {<br /> // Update code here that does not depend on having received a data set<br /> }<br /> <br /> void loop() {<br /> elcano::ParseStateError r = ps.update();<br /> if (r == elcano::ParseStateError::success) {<br /> loop1();<br /> }<br /> <br /> loop2();<br /> }<br /> &lt;/pre&gt;<br /> <br /> Replace &lt;tt&gt;DESIRED_TYPE&lt;/tt&gt; with &lt;tt&gt;drive&lt;/tt&gt;, &lt;tt&gt;sensor&lt;/tt&gt;, &lt;tt&gt;goal&lt;/tt&gt;, or &lt;tt&gt;seg&lt;/tt&gt; depending on your component. The specific serial port used by your component may vary, so you may have to change &lt;tt&gt;Serial1&lt;/tt&gt; and &lt;tt&gt;Serial2&lt;/tt&gt; around.<br /> <br /> The error handling code in the skeleton is enough to get you started, but may be a little bit lacking if you want more fine grained control, especially if you are debugging. That can be accomplished with a switch statement in the &lt;tt&gt;loop&lt;/tt&gt; function:<br /> <br /> &lt;pre&gt;<br /> void loop() {<br /> elcano::ParseStateError r = ps.update();<br /> switch (r) {<br /> case elcano::ParseStateError::success:<br /> loop1();<br /> break;<br /> &lt;other cases go here&gt;<br /> }<br /> <br /> loop2();<br /> }<br /> &lt;/pre&gt;<br /> <br /> == Limitations ==<br /> <br /> The Arduino has a hard limit of 32 characters which it can store at a time from the serial port. It can also only write to the serial far faster than it can read and parse. This combined leads to a situation where if you write too quickly, you will overwhelm the reader and get garbage results. This can be countered in 2 ways:<br /> <br /> # Put a wait between writes. Hold on, I hear you say! Isn't the point of the asynchronous system that no blocking is required? The difference between this and naive blocking serial usage is that this blocks on write, while the other blocks on read, and this is purely due to the memory constraints on the Arduinos.<br /> # Only write to the message loop after you have just recieved from the message loop. Based on our usage example above this, you would only write in loop1 and not in loop2. This ensures that nothing gets written until something is received, which forces all delay necessary to prevent a problem.<br /> <br /> If at some point in the future, the hardware gets updated to something without the hard Arduino requirements, then feel free to experiment with removing these limitations.<br /> <br /> == External Links ==<br /> <br /> !ElcanoSerial: https://github.com/elcano/elcano/tree/master/libraries/ElcanoSerial<br /> <br /> !FastCRC: https://github.com/FrankBoesing/FastCRC<br /> <br /> -- Main.JohnsonB - 2017-06-30</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Odometer&diff=317 2020-05-28T00:05:00Z

<p>Tfolsom: Created page with &quot;There is odometer hardware on both the Drive-By-Wire board and on the High Level board. Normally the speed and odometer will be computed on the Drive-By-Wire board and passed...&quot;</p> <hr /> <div>There is odometer hardware on both the Drive-By-Wire board and on the High Level board. Normally the speed and odometer will be computed on the Drive-By-Wire board and passed to the HighLevel board as a CAM message. However, there is the capability for either board to process the signal and compute speed and distance traveled.<br /> The odometer sensor is a reed switch positioned so that it detects a magnet attached to a spoke of the vehicle. The magnet opens and closes a switch once per revolution. The hardware on the circuit board has a pull-up resistor that converts the open/closed switch to a high or low voltage. This signal is input to an interrupt pin of the Arduino. There is an edge transition that occurs once per wheel revolution. This signal triggers an interrupt that logs the time of the signal. Speed is computed from the time that it takes to make one wheel revolution.<br /> This is the same system used on a standard bicycle cyclometer. The odometer is constructed from a cyclometer pick-up where the wire has been cut and soldered to a barrel plug connecting to the circuit board. Most trike have two speedometers. One goes to a standard human readable cyclometer, and the other goes to an Arduino. They should be calibrated to give the same reading. Cyclometers are calibrated based on wheel diameter or circumference.<br /> When computing speed, thee should be a reasonable limit on how fast the trike can go. Any signal edge that would make it too fast is a glitch and should be rejected.<br /> The instrument is incapable of telling whether the trike has stopped or is just moving slowly. It should time-out to zero speed instead of staying at the last measured speed forever. It may help to extrapolate slowing speeds and set speed to zero at the right time.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=RemoteControl&diff=277 2019-11-10T02:07:37Z

<p>Tfolsom: /* Current System */</p> <hr /> <div>= Historic Systems =<br /> <br /> The Elcano system can run autonomously or by remote control. There have been four systems built for manual or remote control.<br /> <br /> == Joystick ==<br /> The first system used an APEM 9000 joystick. The part has five wires: 5V power, ground, and three analog lines. The joystick has two axes. The vertical axis is used for throttle (up) and brakes (down). The third analog signal is the voltage of the joystick when centered. The joystick was used in 2014 and is described in http://www.elcanoproject.org/tutorial/lab2.php. The Low-level code may still contain inputs and processing for an analog joystick.<br /> <br /> == Bluetooth ==<br /> In 2015 students built a control system using a Bluetooth receiver to the Arduino. The transmitter was a TI Sitara running Android. <br /> <br /> == Amplitude Shift Keying (ASK) RC Controller ==<br /> <br /> Elcano project used a custom-built radio control system with two arduinos, one in the remote control that collects manual inputs and transmits them with a 433MHz ASK radio transmitter, and one on the Elcano vehicle which receives the information sent over radio and converts it into an ElcanoSerial drive packet which is transmitted to C2 over ElcanoSerial. This information is used to manually drive the trike, begin an autonomous routine, or activate the emergency brake and stop the trike. The RH_ASK system was limited to 40 feet (12 meters) in practice and was never use to drive the vehicle.<br /> <br /> = Current System =<br /> <br /> == CAN Bus and SAMD21 ==<br /> <br /> The RC transceiver board can be built five different ways:<br /> <br /> * Transmitter using Bluetooth<br /> <br /> * Receiver using Bluetooth<br /> <br /> * Transmitter using radio (RFM69HCW)<br /> <br /> * Receiver using radio (RFM69HCW)<br /> <br /> * Receiver using 5 or 6 channel radio control (RC)<br /> <br /> When configured as a receiver it is mounted on the vehicle and communicates drive commands over CAN bus. <br /> <br /> CAN is documented on [[Communication]]<br /> <br /> As a transmitter, it is packaged in a remote box with joysticks and switches. Functions and pins are explained in TranceiverPins_1_6.docx on https://github.com/elcano/Transceiver/tree/master/Transceiver%20Documents.<br /> <br /> <br /> The processor is an Arduino ARM SAMD21 mini dev board, which requires some special steps to install. These are detailed on https://learn.sparkfun.com/tutorials/samd21-minidev-breakout-hookup-guide/setting-up-arduino <br /> <br /> Reset requires two quick taps of the reset button. After a reset, the blue LED on the board will pulse slowly for a few seconds. If the board is unresponsive, try resetting this way first.'''<br /> <br /> == Setting up SAMD21 ==<br /> <br /> Follow the instructions on https://learn.sparkfun.com/tutorials/samd21-minidev-breakout-hookup-guide/setting-up-arduino<br /> <br /> Tools &gt; Board &gt; Boards Manager … Then find an entry for Arduino SAMD Boards (32-bits ARM Cortex-M0+). Select it, and install.<br /> <br /> Next, open your Arduino preferences (File &gt; Preferences). Then find the Additional Board Manager URLs text box, and paste the below link in:<br /> <br /> https://raw.githubusercontent.com/sparkfun/Arduino_Boards/master/IDE_Board_Manager/package_sparkfun_index.json<br /> <br /> Then hit &quot;OK&quot;, and travel back to the Board Manager menu. Find a new entry for SparkFun SAMD Boards.<br /> Once the board is installed, you should see new entries in your Tools &gt; Board list. Select SparkFun SAMD21 Mini Breakout.<br /> <br /> Next step is to find the needed files.<br /> <br /> #include &lt;RH_RF69.h&gt; // External; documented at <br /> http://www.airspayce.com/mikem/arduino/RadioHead/classRH__RF69.html<br /> <br /> Download the file from http://www.airspayce.com/mikem/arduino/RadioHead/RadioHead-1.97.zip<br /> <br /> Follow https://www.arduino.cc/en/Guide/Libraries to add the library. From Sketch &gt; Include Libraries select Add Zip Library and navigate to the right file. You should then see RadioHead in the list of included libraries.<br /> <br /> #include &lt;mcp_can_dfs.h&gt; // &lt;---- Import from another library: Seed-Studio/CAN-BUS-Shield<br /> <br /> #include &lt;mcp_can.h&gt; // (install Library from Arduino, search for &quot;Can-Bus-Shield&quot;)<br /> <br /> Download zip from<br /> <br /> https://github.com/Seeed-Studio/CAN_BUS_Shield<br /> <br /> From Sketch &gt; Include Libraries select Add Zip Library and navigate to the right file. You should see CAN_BUS-Shield-master in the Include Libraries.<br /> <br /> == 5- and 6-channel RC Controller ==<br /> <br /> The system has been run from either a Hitec Optics 5 2.4 five channel unit or a Spektrum DX6i six channel controller. The Low level circuit board has a3x7 pin socket in the corner to accommodate the receiver. Each channel needs to be on its own interrupt. Since the Arduino Mega has only 6 interrupts and the Arduino Micro has 5, this can be a problem, especially since we want another one or two interrupts to handle the speed. Low level code may still have software to handle these interrupts. The RC controllers send a 1.0 to 2.0 ms pulse on each channel at 30 Hz. Some controllers send these signals in turn. We have built a six-input OR circuit to combine all signals, which would allow processing with just one interrupt. Unfortunately, there is no good way to predict whether the RC unit will send pulses in turn or all at once. In fact, the behavior seems to be determined by the receive unit, not the transmitter. Thus a separate interrupt is required for each channel used. Interrupt processing consists of interrupting on a rising edge, then switching to a falling edge interrupt and logging the pulse width. A width of 1.0 ms typically means one extreme, 1.5 ms is centered, and 2.0 ms is the other extreme., This system can get confusing about which channel is assigned which behavior, and the two controllers assign their channels differently. To go beyond the Arduino interrupt limit, the V2 Low Level board has all RC inputs assigned to Analog Input 8 to 13 of the Arduino. These pins are used digitally. Pins A8-A15 on Arduino Mega, all go to the same port. Thus we can use the pin change interrupt, which is activated whenever any bit of the 8-bit port changes.<br /> <br /> <br /> == RFM69HCW and SAMD21 ==<br /> <br /> The RFM69HCW (915MHz) transceiver offers several benefits over the 433MHz ASK radios:<br /> * greater range with higher transmit power<br /> * much higher raw bitrate<br /> * half-duplex communication and received signal strength indicator (RSSI)<br /> * compatibility with higher-performance 3.3V ARM boards like SAMD21<br /> <br /> Using the RF69 RadioHead library, the RC system has expanded capabilities from the RH ASK implementation. Data is stored on both ends as a C struct, which is broken down and transmitted as bytes by the RF69 library. After successful transmission, the data is accessible directly from the struct and variables larger than one byte need no additional processing before use. After successfully receiving a packet from the remote control, the receiver sends a packet back with an RSSI value. The remote control uses this reply message to indicate radio communication is active. <br /> <br /> === Transmitted data to vehicle ===<br /> * unsigned 12-bit throttle (0-4095)<br /> * unsigned 12-bit turn <br /> * boolean emergency stop<br /> * boolean autonomous mode<br /> * signed RSSI of last received packet (from vehicle)<br /> <br /> === Received data from vehicle ===<br /> * signed RSSI of last received packet (from remote)<br /> <br /> <br /> <br /> <br /> NEXT . [[SensorsPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Board_Diagrams&diff=276 2019-11-09T05:30:40Z

<p>Tfolsom: </p> <hr /> <div>= Board Schematics =<br /> <br /> == Low Level Board ==<br /> <br /> * Documentation &gt; [[LowLevelBoard]]<br /> <br /> * Photo &gt; [[Low Level]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics/Low%20Level%20v3 <br /> <br /> * Should be migrated to: https://github.com/elcano/LowLevel/Electronics<br /> <br /> <br /> [[File:LowLevelV3.1_A.png]]<br /> [[File:LowLevelV3.1_B.png]]<br /> [[File:LowLevelV3.1_C.png]]<br /> [[File:LowLevelV3.1_brd.png]]<br /> <br /> == High Level Board ==<br /> <br /> * Documentation &gt; [[HighLevelHWv3]]<br /> <br /> * Photo &gt; [[High Level]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics/High%20Level <br /> <br /> * Should be migrated to: https://github.com/elcano/HighLevel/Electronics<br /> <br /> <br /> [[File:High-Level PCB v3.0.png]]<br /> [[File:High-Level PCB v3.0_brd.png]]<br /> <br /> == Sonar Array Board ==<br /> <br /> * Documentation and photo &gt; [[Sonar]]<br /> <br /> * Eagle CAD files on https://github.com/elcano/Sonar/tree/master/Electronics <br /> <br /> [[File:SonarBoardV2.png]]<br /> <br /> [[File:SonarBoardV2 brd.png]]<br /> <br /> == Scanse Sweep Board ==<br /> <br /> * Documentation &gt; [[Lidar]]<br /> <br /> * Eagle CAD files coming to https://github.com/elcano/Sweep<br /> <br /> [[File:ScanseSweep.png]]<br /> <br /> [[File:ScanseSweep_Brd.png]]<br /> <br /> <br /> == Transceiver Board ==<br /> <br /> * Documentation &gt; [[RemoteControl]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/Transceiver <br /> <br /> [[File:Transceiver.png]]<br /> <br /> [[File:Transceiver Brd.png]]<br /> <br /> Bill of Materials: Transceiver_BoM.xlxs on https://github.com/elcano/Transceiver/tree/master/Electronics<br /> <br /> == PowerOn Board ==<br /> <br /> <br /> * Documentation and photo &gt; [[Power System]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics <br /> <br /> <br /> <br /> [[File:PowerOn.png]]<br /> <br /> Cuts and jumpers to just use Kelly power-on circuit and DC-DC converters<br /> <br /> [[File:PowerOnOnly.png]]<br /> <br /> [[File:PowerOn_brd.png]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=File:ScanseSweep_Brd.png&diff=275 2019-11-09T05:19:30Z

<p>Tfolsom: Board layout for Scanse Sweep interface board.</p> <hr /> <div>== Summary ==<br /> Board layout for Scanse Sweep interface board.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=File:ScanseSweep.png&diff=274 2019-11-09T05:18:36Z

<p>Tfolsom: Schematic for Scanse Sweep interface board.</p> <hr /> <div>== Summary ==<br /> Schematic for Scanse Sweep interface board.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Board_Diagrams&diff=273 2019-11-09T05:08:56Z

<p>Tfolsom: /* Transceiver Board */</p> <hr /> <div>= Board Schematics =<br /> <br /> == Low Level Board ==<br /> <br /> * Documentation &gt; [[LowLevelBoard]]<br /> <br /> * Photo &gt; [[Low Level]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics/Low%20Level%20v3 <br /> <br /> * Should be migrated to: https://github.com/elcano/LowLevel/Electronics<br /> <br /> <br /> [[File:LowLevelV3.1_A.png]]<br /> [[File:LowLevelV3.1_B.png]]<br /> [[File:LowLevelV3.1_C.png]]<br /> [[File:LowLevelV3.1_brd.png]]<br /> <br /> == High Level Board ==<br /> <br /> * Documentation &gt; [[HighLevelHWv3]]<br /> <br /> * Photo &gt; [[High Level]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics/High%20Level <br /> <br /> * Should be migrated to: https://github.com/elcano/HighLevel/Electronics<br /> <br /> <br /> [[File:High-Level PCB v3.0.png]]<br /> [[File:High-Level PCB v3.0_brd.png]]<br /> <br /> == Sonar Array Board ==<br /> <br /> * Documentation and photo &gt; [[Sonar]]<br /> <br /> * Eagle CAD files on https://github.com/elcano/Sonar/tree/master/Electronics <br /> <br /> [[File:SonarBoardV2.png]]<br /> <br /> [[File:SonarBoardV2_brd.png]]<br /> <br /> <br /> == Transceiver Board ==<br /> <br /> * Documentation &gt; [[RemoteControl]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/Transceiver <br /> <br /> [[File:Transceiver.png]]<br /> <br /> [[File:Transceiver Brd.png]]<br /> <br /> Bill of Materials: Transceiver_BoM.xlxs on https://github.com/elcano/Transceiver/tree/master/Electronics<br /> <br /> == PowerOn Board ==<br /> <br /> <br /> * Documentation and photo &gt; [[Power System]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics <br /> <br /> <br /> <br /> [[File:PowerOn.png]]<br /> <br /> Cuts and jumpers to just use Kelly power-on circuit and DC-DC converters<br /> <br /> [[File:PowerOnOnly.png]]<br /> <br /> [[File:PowerOn_brd.png]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=RemoteControl&diff=272 2019-11-09T05:03:43Z

<p>Tfolsom: /* CAN Bus and SAMD21 */</p> <hr /> <div>= Historic Systems =<br /> <br /> The Elcano system can run autonomously or by remote control. There have been four systems built for manual or remote control.<br /> <br /> == Joystick ==<br /> The first system used an APEM 9000 joystick. The part has five wires: 5V power, ground, and three analog lines. The joystick has two axes. The vertical axis is used for throttle (up) and brakes (down). The third analog signal is the voltage of the joystick when centered. The joystick was used in 2014 and is described in http://www.elcanoproject.org/tutorial/lab2.php. The Low-level code may still contain inputs and processing for an analog joystick.<br /> <br /> == Bluetooth ==<br /> In 2015 students built a control system using a Bluetooth receiver to the Arduino. The transmitter was a TI Sitara running Android. <br /> <br /> == Amplitude Shift Keying (ASK) RC Controller ==<br /> <br /> Elcano project used a custom-built radio control system with two arduinos, one in the remote control that collects manual inputs and transmits them with a 433MHz ASK radio transmitter, and one on the Elcano vehicle which receives the information sent over radio and converts it into an ElcanoSerial drive packet which is transmitted to C2 over ElcanoSerial. This information is used to manually drive the trike, begin an autonomous routine, or activate the emergency brake and stop the trike. The RH_ASK system was limited to 40 feet (12 meters) in practice and was never use to drive the vehicle.<br /> <br /> = Current System =<br /> <br /> == CAN Bus and SAMD21 ==<br /> <br /> The RC transceiver board can be built five different ways:<br /> <br /> * Transmitter using Bluetooth<br /> <br /> * Receiver using Bluetooth<br /> <br /> * Transmitter using radio (RFM69HCW)<br /> <br /> * Receiver using radio (RFM69HCW)<br /> <br /> * Receiver using 5 or 6 channel radio control (RC)<br /> <br /> When configured as a receiver it is mounted on the vehicle and communicates drive commands over CAN bus. <br /> <br /> CAN is documented on [[Communication]]<br /> <br /> As a transmitter, it is packaged in a remote box with joysticks and switches. Functions and pins are explained in TranceiverPins_1_6.docx on https://github.com/elcano/Transceiver/tree/master/Transceiver%20Documents.<br /> <br /> <br /> The processor is an Arduino ARM SAMD21 mini dev board, which requires some special steps to install. These are detailed on https://learn.sparkfun.com/tutorials/samd21-minidev-breakout-hookup-guide/setting-up-arduino <br /> <br /> Reset requires two quick taps of the reset button. After a reset, the blue LED on the board will pulse slowly for a few seconds. If the board is unresponsive, try resetting this way first.'''<br /> <br /> == 5- and 6-channel RC Controller ==<br /> The system has been run from either a Hitec Optics 5 2.4 five channel unit or a Spektrum DX6i six channel controller. The Low level circuit board has a3x7 pin socket in the corner to accommodate the receiver. Each channel needs to be on its own interrupt. Since the Arduino Mega has only 6 interrupts and the Arduino Micro has 5, this can be a problem, especially since we want another one or two interrupts to handle the speed. Low level code may still have software to handle these interrupts. The RC controllers send a 1.0 to 2.0 ms pulse on each channel at 30 Hz. Some controllers send these signals in turn. We have built a six-input OR circuit to combine all signals, which would allow processing with just one interrupt. Unfortunately, there is no good way to predict whether the RC unit will send pulses in turn or all at once. In fact, the behavior seems to be determined by the receive unit, not the transmitter. Thus a separate interrupt is required for each channel used. Interrupt processing consists of interrupting on a rising edge, then switching to a falling edge interrupt and logging the pulse width. A width of 1.0 ms typically means one extreme, 1.5 ms is centered, and 2.0 ms is the other extreme., This system can get confusing about which channel is assigned which behavior, and the two controllers assign their channels differently. To go beyond the Arduino interrupt limit, the V2 Low Level board has all RC inputs assigned to Analog Input 8 to 13 of the Arduino. These pins are used digitally. Pins A8-A15 on Arduino Mega, all go to the same port. Thus we can use the pin change interrupt, which is activated whenever any bit of the 8-bit port changes.<br /> <br /> <br /> <br /> == RFM69HCW and SAMD21 ==<br /> <br /> The RFM69HCW (915MHz) transceiver offers several benefits over the 433MHz ASK radios:<br /> * greater range with higher transmit power<br /> * much higher raw bitrate<br /> * half-duplex communication and received signal strength indicator (RSSI)<br /> * compatibility with higher-performance 3.3V ARM boards like SAMD21<br /> <br /> Using the RF69 RadioHead library, the RC system has expanded capabilities from the RH ASK implementation. Data is stored on both ends as a C struct, which is broken down and transmitted as bytes by the RF69 library. After successful transmission, the data is accessible directly from the struct and variables larger than one byte need no additional processing before use. After successfully receiving a packet from the remote control, the receiver sends a packet back with an RSSI value. The remote control uses this reply message to indicate radio communication is active. <br /> <br /> === Transmitted data to vehicle ===<br /> * unsigned 12-bit throttle (0-4095)<br /> * unsigned 12-bit turn <br /> * boolean emergency stop<br /> * boolean autonomous mode<br /> * signed RSSI of last received packet (from vehicle)<br /> <br /> === Received data from vehicle ===<br /> * signed RSSI of last received packet (from remote)<br /> <br /> <br /> <br /> <br /> NEXT . [[SensorsPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=RemoteControl&diff=271 2019-11-09T05:02:54Z

<p>Tfolsom: /* CAN Bus and SAMD21 */</p> <hr /> <div>= Historic Systems =<br /> <br /> The Elcano system can run autonomously or by remote control. There have been four systems built for manual or remote control.<br /> <br /> == Joystick ==<br /> The first system used an APEM 9000 joystick. The part has five wires: 5V power, ground, and three analog lines. The joystick has two axes. The vertical axis is used for throttle (up) and brakes (down). The third analog signal is the voltage of the joystick when centered. The joystick was used in 2014 and is described in http://www.elcanoproject.org/tutorial/lab2.php. The Low-level code may still contain inputs and processing for an analog joystick.<br /> <br /> == Bluetooth ==<br /> In 2015 students built a control system using a Bluetooth receiver to the Arduino. The transmitter was a TI Sitara running Android. <br /> <br /> == Amplitude Shift Keying (ASK) RC Controller ==<br /> <br /> Elcano project used a custom-built radio control system with two arduinos, one in the remote control that collects manual inputs and transmits them with a 433MHz ASK radio transmitter, and one on the Elcano vehicle which receives the information sent over radio and converts it into an ElcanoSerial drive packet which is transmitted to C2 over ElcanoSerial. This information is used to manually drive the trike, begin an autonomous routine, or activate the emergency brake and stop the trike. The RH_ASK system was limited to 40 feet (12 meters) in practice and was never use to drive the vehicle.<br /> <br /> = Current System =<br /> <br /> == CAN Bus and SAMD21 ==<br /> <br /> The RC transceiver board can be built five different ways:<br /> <br /> * Transmitter using Bluetooth<br /> <br /> * Receiver using Bluetooth<br /> <br /> * Transmitter using radio (RFM69HCW)<br /> <br /> * Receiver using radio (RFM69HCW)<br /> <br /> * Receiver using 5 or 6 channel radio control (RC)<br /> <br /> When configured as a receiver it is mounted on the vehicle and communicates drive commands over CAN bus. <br /> <br /> CAN is documented on [[Communication]]<br /> <br /> As a transmitter, it is packaged in a remote box with joysticks and switches. Functions and pins are explained in TranceiverPins_1_6.docx on https://github.com/elcano/Transceiver/tree/master/Transceiver Documents.<br /> <br /> <br /> The processor is an Arduino ARM SAMD21 mini dev board, which requires some special steps to install. These are detailed on https://learn.sparkfun.com/tutorials/samd21-minidev-breakout-hookup-guide/setting-up-arduino <br /> <br /> Reset requires two quick taps of the reset button. After a reset, the blue LED on the board will pulse slowly for a few seconds. If the board is unresponsive, try resetting this way first.'''<br /> <br /> == 5- and 6-channel RC Controller ==<br /> The system has been run from either a Hitec Optics 5 2.4 five channel unit or a Spektrum DX6i six channel controller. The Low level circuit board has a3x7 pin socket in the corner to accommodate the receiver. Each channel needs to be on its own interrupt. Since the Arduino Mega has only 6 interrupts and the Arduino Micro has 5, this can be a problem, especially since we want another one or two interrupts to handle the speed. Low level code may still have software to handle these interrupts. The RC controllers send a 1.0 to 2.0 ms pulse on each channel at 30 Hz. Some controllers send these signals in turn. We have built a six-input OR circuit to combine all signals, which would allow processing with just one interrupt. Unfortunately, there is no good way to predict whether the RC unit will send pulses in turn or all at once. In fact, the behavior seems to be determined by the receive unit, not the transmitter. Thus a separate interrupt is required for each channel used. Interrupt processing consists of interrupting on a rising edge, then switching to a falling edge interrupt and logging the pulse width. A width of 1.0 ms typically means one extreme, 1.5 ms is centered, and 2.0 ms is the other extreme., This system can get confusing about which channel is assigned which behavior, and the two controllers assign their channels differently. To go beyond the Arduino interrupt limit, the V2 Low Level board has all RC inputs assigned to Analog Input 8 to 13 of the Arduino. These pins are used digitally. Pins A8-A15 on Arduino Mega, all go to the same port. Thus we can use the pin change interrupt, which is activated whenever any bit of the 8-bit port changes.<br /> <br /> <br /> <br /> == RFM69HCW and SAMD21 ==<br /> <br /> The RFM69HCW (915MHz) transceiver offers several benefits over the 433MHz ASK radios:<br /> * greater range with higher transmit power<br /> * much higher raw bitrate<br /> * half-duplex communication and received signal strength indicator (RSSI)<br /> * compatibility with higher-performance 3.3V ARM boards like SAMD21<br /> <br /> Using the RF69 RadioHead library, the RC system has expanded capabilities from the RH ASK implementation. Data is stored on both ends as a C struct, which is broken down and transmitted as bytes by the RF69 library. After successful transmission, the data is accessible directly from the struct and variables larger than one byte need no additional processing before use. After successfully receiving a packet from the remote control, the receiver sends a packet back with an RSSI value. The remote control uses this reply message to indicate radio communication is active. <br /> <br /> === Transmitted data to vehicle ===<br /> * unsigned 12-bit throttle (0-4095)<br /> * unsigned 12-bit turn <br /> * boolean emergency stop<br /> * boolean autonomous mode<br /> * signed RSSI of last received packet (from vehicle)<br /> <br /> === Received data from vehicle ===<br /> * signed RSSI of last received packet (from remote)<br /> <br /> <br /> <br /> <br /> NEXT . [[SensorsPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Board_Diagrams&diff=270 2019-11-08T23:20:42Z

<p>Tfolsom: </p> <hr /> <div>= Board Schematics =<br /> <br /> == Low Level Board ==<br /> <br /> * Documentation &gt; [[LowLevelBoard]]<br /> <br /> * Photo &gt; [[Low Level]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics/Low%20Level%20v3 <br /> <br /> * Should be migrated to: https://github.com/elcano/LowLevel/Electronics<br /> <br /> <br /> [[File:LowLevelV3.1_A.png]]<br /> [[File:LowLevelV3.1_B.png]]<br /> [[File:LowLevelV3.1_C.png]]<br /> [[File:LowLevelV3.1_brd.png]]<br /> <br /> == High Level Board ==<br /> <br /> * Documentation &gt; [[HighLevelHWv3]]<br /> <br /> * Photo &gt; [[High Level]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics/High%20Level <br /> <br /> * Should be migrated to: https://github.com/elcano/HighLevel/Electronics<br /> <br /> <br /> [[File:High-Level PCB v3.0.png]]<br /> [[File:High-Level PCB v3.0_brd.png]]<br /> <br /> == Sonar Array Board ==<br /> <br /> * Documentation and photo &gt; [[Sonar]]<br /> <br /> * Eagle CAD files on https://github.com/elcano/Sonar/tree/master/Electronics <br /> <br /> [[File:SonarBoardV2.png]]<br /> <br /> [[File:SonarBoardV2_brd.png]]<br /> <br /> <br /> == Transceiver Board ==<br /> <br /> * Documentation &gt; [[RemoteControl]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/Transceiver <br /> <br /> [[File:Transceiver.png]]<br /> <br /> [[File:Transceiver Brd.png]]<br /> <br /> == PowerOn Board ==<br /> <br /> <br /> * Documentation and photo &gt; [[Power System]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics <br /> <br /> <br /> <br /> [[File:PowerOn.png]]<br /> <br /> Cuts and jumpers to just use Kelly power-on circuit and DC-DC converters<br /> <br /> [[File:PowerOnOnly.png]]<br /> <br /> [[File:PowerOn_brd.png]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=File:Transceiver_Brd.png&diff=269 2019-11-08T23:15:40Z

<p>Tfolsom: Graphic of Transceiver board layout.</p> <hr /> <div>== Summary ==<br /> Graphic of Transceiver board layout.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=File:Transceiver.png&diff=268 2019-11-08T22:53:05Z

<p>Tfolsom: Graphic of transceiver schematic.</p> <hr /> <div>== Summary ==<br /> Graphic of transceiver schematic.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=RemoteControl&diff=267 2019-11-08T22:40:28Z

<p>Tfolsom: </p> <hr /> <div>= Historic Systems =<br /> <br /> The Elcano system can run autonomously or by remote control. There have been four systems built for manual or remote control.<br /> <br /> == Joystick ==<br /> The first system used an APEM 9000 joystick. The part has five wires: 5V power, ground, and three analog lines. The joystick has two axes. The vertical axis is used for throttle (up) and brakes (down). The third analog signal is the voltage of the joystick when centered. The joystick was used in 2014 and is described in http://www.elcanoproject.org/tutorial/lab2.php. The Low-level code may still contain inputs and processing for an analog joystick.<br /> <br /> == Bluetooth ==<br /> In 2015 students built a control system using a Bluetooth receiver to the Arduino. The transmitter was a TI Sitara running Android. <br /> <br /> == Amplitude Shift Keying (ASK) RC Controller ==<br /> <br /> Elcano project used a custom-built radio control system with two arduinos, one in the remote control that collects manual inputs and transmits them with a 433MHz ASK radio transmitter, and one on the Elcano vehicle which receives the information sent over radio and converts it into an ElcanoSerial drive packet which is transmitted to C2 over ElcanoSerial. This information is used to manually drive the trike, begin an autonomous routine, or activate the emergency brake and stop the trike. The RH_ASK system was limited to 40 feet (12 meters) in practice and was never use to drive the vehicle.<br /> <br /> = Current System =<br /> <br /> == CAN Bus and SAMD21 ==<br /> <br /> The RC transceiver board can be built five different ways:<br /> <br /> * Transmitter using Bluetooth<br /> <br /> * Receiver using Bluetooth<br /> <br /> * Transmitter using radio (RFM69HCW)<br /> <br /> * Receiver using radio (RFM69HCW)<br /> <br /> * Receiver using 5 or 6 channel radio control (RC)<br /> <br /> When configured as a receiver it is mounted on the vehicle and communicates drive commands over CAN bus. <br /> <br /> CAN is documented on . [[Communication]]<br /> <br /> As a transmitter, it is packaged in a remote box with joysticks and switches. Functions and pins are explained in TranceiverPins.<br /> <br /> <br /> The processor is an Arduino ARM SAMD21 mini dev board, which requires some special steps to install. These are detailed on https://learn.sparkfun.com/tutorials/samd21-minidev-breakout-hookup-guide/setting-up-arduino <br /> <br /> Reset requires two quick taps of the reset button. After a reset, the blue LED on the board will pulse slowly for a few seconds. If the board is unresponsive, try resetting this way first.'''<br /> <br /> == 5- and 6-channel RC Controller ==<br /> The system has been run from either a Hitec Optics 5 2.4 five channel unit or a Spektrum DX6i six channel controller. The Low level circuit board has a3x7 pin socket in the corner to accommodate the receiver. Each channel needs to be on its own interrupt. Since the Arduino Mega has only 6 interrupts and the Arduino Micro has 5, this can be a problem, especially since we want another one or two interrupts to handle the speed. Low level code may still have software to handle these interrupts. The RC controllers send a 1.0 to 2.0 ms pulse on each channel at 30 Hz. Some controllers send these signals in turn. We have built a six-input OR circuit to combine all signals, which would allow processing with just one interrupt. Unfortunately, there is no good way to predict whether the RC unit will send pulses in turn or all at once. In fact, the behavior seems to be determined by the receive unit, not the transmitter. Thus a separate interrupt is required for each channel used. Interrupt processing consists of interrupting on a rising edge, then switching to a falling edge interrupt and logging the pulse width. A width of 1.0 ms typically means one extreme, 1.5 ms is centered, and 2.0 ms is the other extreme., This system can get confusing about which channel is assigned which behavior, and the two controllers assign their channels differently. To go beyond the Arduino interrupt limit, the V2 Low Level board has all RC inputs assigned to Analog Input 8 to 13 of the Arduino. These pins are used digitally. Pins A8-A15 on Arduino Mega, all go to the same port. Thus we can use the pin change interrupt, which is activated whenever any bit of the 8-bit port changes.<br /> <br /> <br /> <br /> == RFM69HCW and SAMD21 ==<br /> <br /> The RFM69HCW (915MHz) transceiver offers several benefits over the 433MHz ASK radios:<br /> * greater range with higher transmit power<br /> * much higher raw bitrate<br /> * half-duplex communication and received signal strength indicator (RSSI)<br /> * compatibility with higher-performance 3.3V ARM boards like SAMD21<br /> <br /> Using the RF69 RadioHead library, the RC system has expanded capabilities from the RH ASK implementation. Data is stored on both ends as a C struct, which is broken down and transmitted as bytes by the RF69 library. After successful transmission, the data is accessible directly from the struct and variables larger than one byte need no additional processing before use. After successfully receiving a packet from the remote control, the receiver sends a packet back with an RSSI value. The remote control uses this reply message to indicate radio communication is active. <br /> <br /> === Transmitted data to vehicle ===<br /> * unsigned 12-bit throttle (0-4095)<br /> * unsigned 12-bit turn <br /> * boolean emergency stop<br /> * boolean autonomous mode<br /> * signed RSSI of last received packet (from vehicle)<br /> <br /> === Received data from vehicle ===<br /> * signed RSSI of last received packet (from remote)<br /> <br /> <br /> <br /> <br /> NEXT . [[SensorsPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=RemoteControl&diff=266 2019-11-08T22:35:33Z

<p>Tfolsom: /* CAN Bus and SAMD21 */</p> <hr /> <div>= Historic Systems =<br /> <br /> The Elcano system can run autonomously or by remote control. There have been four systems built for manual or remote control.<br /> <br /> == Joystick ==<br /> The first system used an APEM 9000 joystick. The part has five wires: 5V power, ground, and three analog lines. The joystick has two axes. The vertical axis is used for throttle (up) and brakes (down). The third analog signal is the voltage of the joystick when centered. The joystick was used in 2014 and is described in http://www.elcanoproject.org/tutorial/lab2.php. The Low-level code may still contain inputs and processing for an analog joystick.<br /> <br /> == Bluetooth ==<br /> In 2015 students built a control system using a Bluetooth receiver to the Arduino. The transmitter was a TI Sitara running Android. <br /> <br /> == Amplitude Shift Keying (ASK) RC Controller ==<br /> <br /> Elcano project used a custom-built radio control system with two arduinos, one in the remote control that collects manual inputs and transmits them with a 433MHz ASK radio transmitter, and one on the Elcano vehicle which receives the information sent over radio and converts it into an ElcanoSerial drive packet which is transmitted to C2 over ElcanoSerial. This information is used to manually drive the trike, begin an autonomous routine, or activate the emergency brake and stop the trike. The RH_ASK system was limited to 40 feet (12 meters) in practice and was never use to drive the vehicle.<br /> <br /> = Current System =<br /> <br /> == CAN Bus and SAMD21 ==<br /> <br /> The RC transceiver board can be built five different ways:<br /> <br /> * Transmitter using Bluetooth<br /> <br /> * Receiver using Bluetooth<br /> <br /> * Transmitter using radio (RFM69HCW)<br /> <br /> * Receiver using radio (RFM69HCW)<br /> <br /> * Receiver using 5 or 6 channel radio control (RC)<br /> <br /> When configured as a receiver it is mounted on the vehicle and communicates drive commands over CAN bus. [[Elcano CAN Commands]]<br /> <br /> As a transmitter, it is packaged in a remote box with joysticks and switches. Functions and pins are explained in TranceiverPins.<br /> <br /> <br /> The processor is an Arduino ARM SAMD21 mini dev board, which requires some special steps to install. These are detailed on https://learn.sparkfun.com/tutorials/samd21-minidev-breakout-hookup-guide/setting-up-arduino <br /> <br /> Reset requires two quick taps of the reset button. After a reset, the blue LED on the board will pulse slowly for a few seconds. If the board is unresponsive, try resetting this way first.'''<br /> <br /> == 5- and 6-channel RC Controller ==<br /> The system has been run from either a Hitec Optics 5 2.4 five channel unit or a Spektrum DX6i six channel controller. The Low level circuit board has a3x7 pin socket in the corner to accommodate the receiver. Each channel needs to be on its own interrupt. Since the Arduino Mega has only 6 interrupts and the Arduino Micro has 5, this can be a problem, especially since we want another one or two interrupts to handle the speed. Low level code may still have software to handle these interrupts. The RC controllers send a 1.0 to 2.0 ms pulse on each channel at 30 Hz. Some controllers send these signals in turn. We have built a six-input OR circuit to combine all signals, which would allow processing with just one interrupt. Unfortunately, there is no good way to predict whether the RC unit will send pulses in turn or all at once. In fact, the behavior seems to be determined by the receive unit, not the transmitter. Thus a separate interrupt is required for each channel used. Interrupt processing consists of interrupting on a rising edge, then switching to a falling edge interrupt and logging the pulse width. A width of 1.0 ms typically means one extreme, 1.5 ms is centered, and 2.0 ms is the other extreme., This system can get confusing about which channel is assigned which behavior, and the two controllers assign their channels differently. To go beyond the Arduino interrupt limit, the V2 Low Level board has all RC inputs assigned to Analog Input 8 to 13 of the Arduino. These pins are used digitally. Pins A8-A15 on Arduino Mega, all go to the same port. Thus we can use the pin change interrupt, which is activated whenever any bit of the 8-bit port changes.<br /> <br /> <br /> <br /> == RFM69HCW and SAMD21 ==<br /> <br /> The RFM69HCW (915MHz) transceiver offers several benefits over the 433MHz ASK radios:<br /> * greater range with higher transmit power<br /> * much higher raw bitrate<br /> * half-duplex communication and received signal strength indicator (RSSI)<br /> * compatibility with higher-performance 3.3V ARM boards like SAMD21<br /> <br /> Using the RF69 RadioHead library, the RC system has expanded capabilities from the RH ASK implementation. Data is stored on both ends as a C struct, which is broken down and transmitted as bytes by the RF69 library. After successful transmission, the data is accessible directly from the struct and variables larger than one byte need no additional processing before use. After successfully receiving a packet from the remote control, the receiver sends a packet back with an RSSI value. The remote control uses this reply message to indicate radio communication is active. <br /> <br /> === Transmitted data to vehicle ===<br /> * unsigned 12-bit throttle (0-4095)<br /> * unsigned 12-bit turn <br /> * boolean emergency stop<br /> * boolean autonomous mode<br /> * signed RSSI of last received packet (from vehicle)<br /> <br /> === Received data from vehicle ===<br /> * signed RSSI of last received packet (from remote)<br /> <br /> <br /> <br /> <br /> NEXT . [[SensorsPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=RemoteControl&diff=265 2019-11-08T22:25:10Z

<p>Tfolsom: /* CAN Bus and SAMD21 */</p> <hr /> <div>= Historic Systems =<br /> <br /> The Elcano system can run autonomously or by remote control. There have been four systems built for manual or remote control.<br /> <br /> == Joystick ==<br /> The first system used an APEM 9000 joystick. The part has five wires: 5V power, ground, and three analog lines. The joystick has two axes. The vertical axis is used for throttle (up) and brakes (down). The third analog signal is the voltage of the joystick when centered. The joystick was used in 2014 and is described in http://www.elcanoproject.org/tutorial/lab2.php. The Low-level code may still contain inputs and processing for an analog joystick.<br /> <br /> == Bluetooth ==<br /> In 2015 students built a control system using a Bluetooth receiver to the Arduino. The transmitter was a TI Sitara running Android. <br /> <br /> == Amplitude Shift Keying (ASK) RC Controller ==<br /> <br /> Elcano project used a custom-built radio control system with two arduinos, one in the remote control that collects manual inputs and transmits them with a 433MHz ASK radio transmitter, and one on the Elcano vehicle which receives the information sent over radio and converts it into an ElcanoSerial drive packet which is transmitted to C2 over ElcanoSerial. This information is used to manually drive the trike, begin an autonomous routine, or activate the emergency brake and stop the trike. The RH_ASK system was limited to 40 feet (12 meters) in practice and was never use to drive the vehicle.<br /> <br /> = Current System =<br /> <br /> == CAN Bus and SAMD21 ==<br /> <br /> The RC transceiver board can be built five different ways:<br /> <br /> * Transmitter using Bluetooth<br /> <br /> * Receiver using Bluetooth<br /> <br /> * Transmitter using radio (RFM69HCW)<br /> <br /> * Receiver using radio (RFM69HCW)<br /> <br /> * Receiver using 5 or 6 channel radio control (RC)<br /> <br /> When configured as a receiver it is mounted on the vehicle and communicates drive commands over CAN bus.<br /> As a transmitter, it is packaged in a remote box with joysticks and switches. Functions and pins are explained in TranceiverPins.<br /> <br /> <br /> The processor is an Arduino ARM SAMD21 mini dev board, which requires some special steps to install. These are detailed on https://learn.sparkfun.com/tutorials/samd21-minidev-breakout-hookup-guide/setting-up-arduino <br /> <br /> Reset requires two quick taps of the reset button. After a reset, the blue LED on the board will pulse slowly for a few seconds. If the board is unresponsive, try resetting this way first.'''<br /> <br /> == 5- and 6-channel RC Controller ==<br /> The system has been run from either a Hitec Optics 5 2.4 five channel unit or a Spektrum DX6i six channel controller. The Low level circuit board has a3x7 pin socket in the corner to accommodate the receiver. Each channel needs to be on its own interrupt. Since the Arduino Mega has only 6 interrupts and the Arduino Micro has 5, this can be a problem, especially since we want another one or two interrupts to handle the speed. Low level code may still have software to handle these interrupts. The RC controllers send a 1.0 to 2.0 ms pulse on each channel at 30 Hz. Some controllers send these signals in turn. We have built a six-input OR circuit to combine all signals, which would allow processing with just one interrupt. Unfortunately, there is no good way to predict whether the RC unit will send pulses in turn or all at once. In fact, the behavior seems to be determined by the receive unit, not the transmitter. Thus a separate interrupt is required for each channel used. Interrupt processing consists of interrupting on a rising edge, then switching to a falling edge interrupt and logging the pulse width. A width of 1.0 ms typically means one extreme, 1.5 ms is centered, and 2.0 ms is the other extreme., This system can get confusing about which channel is assigned which behavior, and the two controllers assign their channels differently. To go beyond the Arduino interrupt limit, the V2 Low Level board has all RC inputs assigned to Analog Input 8 to 13 of the Arduino. These pins are used digitally. Pins A8-A15 on Arduino Mega, all go to the same port. Thus we can use the pin change interrupt, which is activated whenever any bit of the 8-bit port changes.<br /> <br /> <br /> <br /> == RFM69HCW and SAMD21 ==<br /> <br /> The RFM69HCW (915MHz) transceiver offers several benefits over the 433MHz ASK radios:<br /> * greater range with higher transmit power<br /> * much higher raw bitrate<br /> * half-duplex communication and received signal strength indicator (RSSI)<br /> * compatibility with higher-performance 3.3V ARM boards like SAMD21<br /> <br /> Using the RF69 RadioHead library, the RC system has expanded capabilities from the RH ASK implementation. Data is stored on both ends as a C struct, which is broken down and transmitted as bytes by the RF69 library. After successful transmission, the data is accessible directly from the struct and variables larger than one byte need no additional processing before use. After successfully receiving a packet from the remote control, the receiver sends a packet back with an RSSI value. The remote control uses this reply message to indicate radio communication is active. <br /> <br /> === Transmitted data to vehicle ===<br /> * unsigned 12-bit throttle (0-4095)<br /> * unsigned 12-bit turn <br /> * boolean emergency stop<br /> * boolean autonomous mode<br /> * signed RSSI of last received packet (from vehicle)<br /> <br /> === Received data from vehicle ===<br /> * signed RSSI of last received packet (from remote)<br /> <br /> <br /> <br /> <br /> NEXT . [[SensorsPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=RemoteControl&diff=264 2019-11-08T22:23:14Z

<p>Tfolsom: /* Elcano Remote Control */</p> <hr /> <div>= Historic Systems =<br /> <br /> The Elcano system can run autonomously or by remote control. There have been four systems built for manual or remote control.<br /> <br /> == Joystick ==<br /> The first system used an APEM 9000 joystick. The part has five wires: 5V power, ground, and three analog lines. The joystick has two axes. The vertical axis is used for throttle (up) and brakes (down). The third analog signal is the voltage of the joystick when centered. The joystick was used in 2014 and is described in http://www.elcanoproject.org/tutorial/lab2.php. The Low-level code may still contain inputs and processing for an analog joystick.<br /> <br /> == Bluetooth ==<br /> In 2015 students built a control system using a Bluetooth receiver to the Arduino. The transmitter was a TI Sitara running Android. <br /> <br /> == Amplitude Shift Keying (ASK) RC Controller ==<br /> <br /> Elcano project used a custom-built radio control system with two arduinos, one in the remote control that collects manual inputs and transmits them with a 433MHz ASK radio transmitter, and one on the Elcano vehicle which receives the information sent over radio and converts it into an ElcanoSerial drive packet which is transmitted to C2 over ElcanoSerial. This information is used to manually drive the trike, begin an autonomous routine, or activate the emergency brake and stop the trike. The RH_ASK system was limited to 40 feet (12 meters) in practice and was never use to drive the vehicle.<br /> <br /> = Current System =<br /> <br /> == CAN Bus and SAMD21 ==<br /> <br /> The RC transceiver board can be built five different ways:<br /> <br /> * Transmitter using Bluetooth<br /> <br /> * Receiver using Bluetooth<br /> <br /> * Transmitter using radio<br /> <br /> * Receiver using radio<br /> <br /> * Receiver using radio control (RC)<br /> <br /> When configured as a receiver it is mounted on the vehicle and communicates drive commands over CAN bus.<br /> As a transmitter, it is packaged in a remote box with joysticks and switches. Functions and pins are explained in TranceiverPins.<br /> <br /> <br /> The processor is an Arduino ARM SAMD21 mini dev board, which requires some special steps to install. These are detailed on https://learn.sparkfun.com/tutorials/samd21-minidev-breakout-hookup-guide/setting-up-arduino <br /> <br /> Reset requires two quick taps of the reset button. After a reset, the blue LED on the board will pulse slowly for a few seconds. If the board is unresponsive, try resetting this way first.'''<br /> <br /> == 5- and 6-channel RC Controller ==<br /> The system has been run from either a Hitec Optics 5 2.4 five channel unit or a Spektrum DX6i six channel controller. The Low level circuit board has a3x7 pin socket in the corner to accommodate the receiver. Each channel needs to be on its own interrupt. Since the Arduino Mega has only 6 interrupts and the Arduino Micro has 5, this can be a problem, especially since we want another one or two interrupts to handle the speed. Low level code may still have software to handle these interrupts. The RC controllers send a 1.0 to 2.0 ms pulse on each channel at 30 Hz. Some controllers send these signals in turn. We have built a six-input OR circuit to combine all signals, which would allow processing with just one interrupt. Unfortunately, there is no good way to predict whether the RC unit will send pulses in turn or all at once. In fact, the behavior seems to be determined by the receive unit, not the transmitter. Thus a separate interrupt is required for each channel used. Interrupt processing consists of interrupting on a rising edge, then switching to a falling edge interrupt and logging the pulse width. A width of 1.0 ms typically means one extreme, 1.5 ms is centered, and 2.0 ms is the other extreme., This system can get confusing about which channel is assigned which behavior, and the two controllers assign their channels differently. To go beyond the Arduino interrupt limit, the V2 Low Level board has all RC inputs assigned to Analog Input 8 to 13 of the Arduino. These pins are used digitally. Pins A8-A15 on Arduino Mega, all go to the same port. Thus we can use the pin change interrupt, which is activated whenever any bit of the 8-bit port changes.<br /> <br /> <br /> <br /> == RFM69HCW and SAMD21 ==<br /> <br /> The RFM69HCW (915MHz) transceiver offers several benefits over the 433MHz ASK radios:<br /> * greater range with higher transmit power<br /> * much higher raw bitrate<br /> * half-duplex communication and received signal strength indicator (RSSI)<br /> * compatibility with higher-performance 3.3V ARM boards like SAMD21<br /> <br /> Using the RF69 RadioHead library, the RC system has expanded capabilities from the RH ASK implementation. Data is stored on both ends as a C struct, which is broken down and transmitted as bytes by the RF69 library. After successful transmission, the data is accessible directly from the struct and variables larger than one byte need no additional processing before use. After successfully receiving a packet from the remote control, the receiver sends a packet back with an RSSI value. The remote control uses this reply message to indicate radio communication is active. <br /> <br /> === Transmitted data to vehicle ===<br /> * unsigned 12-bit throttle (0-4095)<br /> * unsigned 12-bit turn <br /> * boolean emergency stop<br /> * boolean autonomous mode<br /> * signed RSSI of last received packet (from vehicle)<br /> <br /> === Received data from vehicle ===<br /> * signed RSSI of last received packet (from remote)<br /> <br /> <br /> <br /> <br /> NEXT . [[SensorsPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=RemoteControl&diff=263 2019-11-08T21:42:15Z

<p>Tfolsom: /* CAN Bus and SAMD21 */</p> <hr /> <div>= Elcano Remote Control =<br /> <br /> The Elcano system can run autonomously or by remote control. There have been four systems built for manual or remote control.<br /> <br /> == Joystick ==<br /> The first system used an APEM 9000 joystick. The part has five wires: 5V power, ground, and three analog lines. The joystick has two axes. The vertical axis is used for throttle (up) and brakes (down). The third analog signal is the voltage of the joystick when centered. The joystick was used in 2014 and is described in http://www.elcanoproject.org/tutorial/lab2.php. The Low-level code may still contain inputs and processing for an analog joystick.<br /> <br /> == Bluetooth ==<br /> In 2015 students built a control system using a Bluetooth receiver to the Arduino. The transmitter was a TI Sitara running Android. <br /> <br /> == 5- and 6-channel RC Controller ==<br /> The system has been run from either a Hitec Optics 5 2.4 five channel unit or a Spektrum DX6i six channel controller. The Low level circuit board has a3x7 pin socket in the corner to accommodate the receiver. Each channel needs to be on its own interrupt. Since the Arduino Mega has only 6 interrupts and the Arduino Micro has 5, this can be a problem, especially since we want another one or two interrupts to handle the speed. Low level code may still have software to handle these interrupts. The RC controllers send a 1.0 to 2.0 ms pulse on each channel at 30 Hz. Some controllers send these signals in turn. We have built a six-input OR circuit to combine all signals, which would allow processing with just one interrupt. Unfortunately, there is no good way to predict whether the RC unit will send pulses in turn or all at once. In fact, the behavior seems to be determined by the receive unit, not the transmitter. Thus a separate interrupt is required for each channel used. Interrupt processing consists of interrupting on a rising edge, then switching to a falling edge interrupt and logging the pulse width. A width of 1.0 ms typically means one extreme, 1.5 ms is centered, and 2.0 ms is the other extreme., This system can get confusing about which channel is assigned which behavior, and the two controllers assign their channels differently. To go beyond the Arduino interrupt limit, the V2 Low Level board has all RC inputs assigned to Analog Input 8 to 13 of the Arduino. These pins are used digitally. Pins A8-A15 on Arduino Mega, all go to the same port. Thus we can use the pin change interrupt, which is activated whenever any bit of the 8-bit port changes.<br /> <br /> == Amplitude Shift Keying (ASK) RC Controller ==<br /> <br /> Elcano project used a custom-built radio control system with two arduinos, one in the remote control that collects manual inputs and transmits them with a 433MHz ASK radio transmitter, and one on the Elcano vehicle which receives the information sent over radio and converts it into an ElcanoSerial drive packet which is transmitted to C2 over ElcanoSerial. This information is used to manually drive the trike, begin an autonomous routine, or activate the emergency brake and stop the trike. The RH_ASK system was limited to 40 feet (12 meters) in practice and was never use to drive the vehicle.<br /> <br /> == RFM69HCW and SAMD21 ==<br /> <br /> The RFM69HCW (915MHz) transceiver offers several benefits over the 433MHz ASK radios:<br /> * greater range with higher transmit power<br /> * much higher raw bitrate<br /> * half-duplex communication and received signal strength indicator (RSSI)<br /> * compatibility with higher-performance 3.3V ARM boards like SAMD21<br /> <br /> Using the RF69 RadioHead library, the RC system has expanded capabilities from the RH ASK implementation. Data is stored on both ends as a C struct, which is broken down and transmitted as bytes by the RF69 library. After successful transmission, the data is accessible directly from the struct and variables larger than one byte need no additional processing before use. After successfully receiving a packet from the remote control, the receiver sends a packet back with an RSSI value. The remote control uses this reply message to indicate radio communication is active. <br /> <br /> === Transmitted data to vehicle ===<br /> * unsigned 12-bit throttle (0-4095)<br /> * unsigned 12-bit turn <br /> * boolean emergency stop<br /> * boolean autonomous mode<br /> * signed RSSI of last received packet (from vehicle)<br /> <br /> === Received data from vehicle ===<br /> * signed RSSI of last received packet (from remote)<br /> <br /> == CAN Bus and SAMD21 ==<br /> <br /> The RC transceiver board can be built five different ways:<br /> <br /> * Transmitter using Bluetooth<br /> <br /> * Receiver using Bluetooth<br /> <br /> * Transmitter using radio<br /> <br /> * Receiver using radio<br /> <br /> * Receiver using radio control (RC)<br /> <br /> When configured as a receiver it is mounted on the vehicle and communicates drive commands over CAN bus.<br /> As a transmitter, it is packaged in a remote box with joysticks and switches. Functions and pins are explained in TranceiverPins.<br /> <br /> <br /> The processor is an Arduino ARM SAMD21 mini dev board, which requires some special steps to install. These are detailed on https://learn.sparkfun.com/tutorials/samd21-minidev-breakout-hookup-guide/setting-up-arduino <br /> <br /> Reset requires two quick taps of the reset button. After a reset, the blue LED on the board will pulse slowly for a few seconds. If the board is unresponsive, try resetting this way first.'''<br /> <br /> <br /> NEXT . [[SensorsPage]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Main_Page&diff=245 2019-10-02T23:31:40Z

<p>Tfolsom: </p> <hr /> <div><br /> <br /> = Welcome to the Elcano Project Wiki =<br /> As the title says, WELCOME TO THE ELCANO PROJECT! Over the past few years many different teams have been working hard to create Cheap and Modular autonomy at the University of Washington Bothell. We are currently working on our first two prototypes which are now in the form of tricycles. With the use of affordable microcontrollers, such as the Arduino Mega 2560 and Raspberry PI, we are working towards creating Autonomy for anyone to rebuild anywhere, and that under $2000 and fully open-source. But we don't plan to stop there, no. That is just the first step in reaching our ultimate goal, which is making our systems applicable to any desired ground vehicles, such as cars and other vehicles. Autonomy is nothing new, in fact it has been around for over 40 years, the difference is that now we have the ability to make it available for anyone who desires furthering their knowledge or simply finding a safer way to work.<br /> <br /> To '''edit articles''' or '''upload files''', please create an account and request editing rights from a [//www.elcanoproject.org/wiki/index.php?title=Special:ListUsers&amp;group=bureaucrat member of the &quot;bureaucrat&quot; group].<br /> <br /> For editing help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.<br /> --------<br /> [[File:Catrikes.JPG|1000px]]<br /> == [[ElcanoIntro | Overview]] ==<br /> Basic concept of how the Elcano Project vehicle works.<br /> <br /> == [[System Architecture]] ==<br /> How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.<br /> <br /> == [[Communication | Communication (CAN Bus)]] ==<br /> How processors exchange data on the vehicle and a description of data packet contents.<br /> <br /> == [[Power System]] ==<br /> How different modules connect to the batteries or power subsystem hardware.<br /> <br /> == [[Low Level]] ==<br /> How the Low Level system uses inputs to control actuators to steer, move, and stop the vehicle.<br /> <br /> == [[High Level]] ==<br /> How the High Level system uses stored maps and inputs from navigational sensors to formulate movement instructions sent to Low Level.<br /> <br /> == [[RemoteControl]] ==<br /> Human control of trike movements through Low Level using hardware connected to Low Level by a radio communication link (drive by radio). Includes on-board controls (drive by wire).<br /> <br /> == [[SensorsPage]] ==<br /> <br /> === [[SteeringSensor]] ===<br /> The front wheel angle detector.<br /> <br /> === [[Sonar]] === <br /> How the sonar subsystem connected to High Level works.<br /> <br /> === [[Lidar]] ===<br /> How the lidar subsystem connected to High Level works.<br /> <br /> === [[ Camera]] ===<br /> How the camera and vision subsystem connected to High Level works.<br /> <br /> == [[ActuatorPage]] ==<br /> <br /> == [[ Board Diagrams]] ==<br /> Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].<br /> <br /> == [[ Simulator]] ==<br /> Using Open-source CARLA platform with a go-between board allows simulation.<br /> <br /> == [[GitUsage | Using Git and GitHub]] ==<br /> Practices for maintaining code and source files on Elcano Project's Github.<br /> <br /> ==[[FilesPage | Files]] ==<br /> These are media files (pictures, videos, etc.) that are part of the project, but are not maintained under version control.<br /> <br /> == Elcano Project Main Website ==<br /> * [//www.elcanoproject.org]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Using_Git_and_GitHub&diff=244 2019-10-02T23:30:16Z

<p>Tfolsom: Created page with &quot;The Elcano repositories are on https://github.com/elcano There is a separate repository for each microprocessor: * LowLevel: Drive by wire * HighLevel: Localization, mapping a...&quot;</p> <hr /> <div>The Elcano repositories are on https://github.com/elcano<br /> There is a separate repository for each microprocessor:<br /> * LowLevel: Drive by wire<br /> * HighLevel: Localization, mapping and path planning<br /> * Transceiver: Remote control transmitter and receiver<br /> * Sonar: Obstacle detection from ultra-sound<br /> * Sweep: Obstacle detection by laser<br /> * QDED: Raspberry Pi Vision based on quadrature disambiguation edge detection<br /> * General: for items that are shared between processors.<br /> <br /> In the past, all code was in the single repository Elcano/Elcano. That repository has been archived. Any useful files from it should be copied to the appropriate repository.<br /> Working with Git<br /> <br /> See the tutorial: https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners<br /> <br /> Typically, you will start with an Elcano repository, and then fork it to your own repository. For instance, fork Elcano/Transceiver to Jane/Transceiver. Both of these repositories live in the cloud. You would then download Jane/Transceiver to your PC. You can do a lot of work in that repository on your PC. When you have code on your PC that has been tested, the next st ep is to upload it.<br /> Suppose that on your PC you have updated the file xmit/ RadioControl_rf69/ RadioControl_rf69.ino.<br /> You need to get into a bash shell window on your PC, and use cd to make xmit the current directory.<br /> <br /> git status // should show nothing changed<br /> <br /> git add RadioControl_rf69/ RadioControl_rf69.ino<br /> <br /> git commit -m “Removed a delay statement that blocked while waiting for an ack”<br /> <br /> Be sure to make your messages reflect what you did for this particular fix. Git supports small incremental changes, and make it possible to roll then back if needed. Please do not wait until the end of the quarter to dump all your changes into the main repository. <br /> <br /> git push origin master<br /> <br /> This command assumes that you have set origin to the URL for xmit and master to the URL for Jane/Transceiver. It puts your new code into your repository on the cloud.<br /> <br /> The next stage is to make a pull request. You are asking to have your code made part of the official Elcano/Transceiver. You are not allowed to directly push to Elcano repositories. If your pull request is accepted, your code becomes part of the Elcano project. A pull request is made from a web browser on Elcano/Transceiver, or whatever repository you are working with.<br /> <br /> === Settings.h ===<br /> This file is required by most processors, but is not kept in any repository. It is meant to include individual vehicle features. All the rest of the code should be written to be portable across a wide variety of vehicles. Specific attributes of a trike (such as wheel diameter, turning radius, etc.) should be kept in a settings.h file for that vehicle. The file SettingsTemplate.h is kept in the General repository. This file should be used to set up an individual setting.h file.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Main_Page&diff=243 2019-10-02T23:25:19Z

<p>Tfolsom: /* Using Git and GitHub */</p> <hr /> <div><br /> <br /> = Welcome to the Elcano Project Wiki =<br /> As the title says, WELCOME TO THE ELCANO PROJECT! Over the past few years many different teams have been working hard to create Cheap and Modular autonomy at the University of Washington Bothell. We are currently working on our first two prototypes which are now in the form of tricycles. With the use of affordable microcontrollers, such as the Arduino Mega 2560 and Raspberry PI, we are working towards creating Autonomy for anyone to rebuild anywhere, and that under $2000 and fully open-source. But we don't plan to stop there, no. That is just the first step in reaching our ultimate goal, which is making our systems applicable to any desired ground vehicles, such as cars and other vehicles. Autonomy is nothing new, in fact it has been around for over 40 years, the difference is that now we have the ability to make it available for anyone who desires furthering their knowledge or simply finding a safer way to work.<br /> <br /> To '''edit articles''' or '''upload files''', please create an account and request editing rights from a [//www.elcanoproject.org/wiki/index.php?title=Special:ListUsers&amp;group=bureaucrat member of the &quot;bureaucrat&quot; group].<br /> <br /> For editing help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.<br /> --------<br /> [[File:Catrikes.JPG|1000px]]<br /> == [[ElcanoIntro | Overview]] ==<br /> Basic concept of how the Elcano Project vehicle works.<br /> <br /> == [[System Architecture]] ==<br /> How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.<br /> <br /> == [[Communication | Communication (CAN Bus)]] ==<br /> How processors exchange data on the vehicle and a description of data packet contents.<br /> <br /> == [[Power System]] ==<br /> How different modules connect to the batteries or power subsystem hardware.<br /> <br /> == [[Low Level]] ==<br /> How the Low Level system uses inputs to control actuators to steer, move, and stop the vehicle.<br /> <br /> == [[High Level]] ==<br /> How the High Level system uses stored maps and inputs from navigational sensors to formulate movement instructions sent to Low Level.<br /> <br /> == [[RemoteControl]] ==<br /> Human control of trike movements through Low Level using hardware connected to Low Level by a radio communication link (drive by radio). Includes on-board controls (drive by wire).<br /> <br /> == [[SensorsPage]] ==<br /> <br /> === [[SteeringSensor]] ===<br /> The front wheel angle detector.<br /> <br /> === [[Sonar]] === <br /> How the sonar subsystem connected to High Level works.<br /> <br /> === [[Lidar]] ===<br /> How the lidar subsystem connected to High Level works.<br /> <br /> === [[ Camera]] ===<br /> How the camera and vision subsystem connected to High Level works.<br /> <br /> == [[ActuatorPage]] ==<br /> <br /> == [[ Board Diagrams]] ==<br /> Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].<br /> <br /> == [[ Simulator]] ==<br /> Using Open-source CARLA platform with a go-between board allows simulation.<br /> <br /> == [[GitUsage | Using Git and GitHub]] ==<br /> Practices for maintaining code and source files on Elcano Project's Github.<br /> <br /> The Elcano repositories are on https://github.com/elcano<br /> There is a separate repository for each microprocessor:<br /> • LowLevel: Drive by wire<br /> • HighLevel: Localization, mapping and path planning<br /> • Transceiver: Remote control transmitter and receiver<br /> • Sonar: Obstacle detection from ultra-sound<br /> • Sweep: Obstacle detection by laser<br /> • QDED: Raspberry Pi Vision based on quadrature disambiguation edge detection<br /> • General: for items that are shared between processors.<br /> In the past, all code was in the single repository Elcano/Elcano. That repository has been archived. Any useful files from it should be copied to the appropriate repository.<br /> Working with Git<br /> See the tutorial: https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners<br /> Typically, you will start with an Elcano repository, and then fork it to your own repository. For instance, fork Elcano/Transceiver to Jane/Transceiver. Both of these repositories live in the cloud. You would then download Jane/Transceiver to your PC. You can do a lot of work in that repository on your PC. When you have code on your PC that has been tested, the next st ep is to upload it.<br /> Suppose that on your PC you have updated the file xmit/ RadioControl_rf69/ RadioControl_rf69.ino.<br /> You need to get into a bash shell window on your PC, and use cd to make xmit the current directory.<br /> git status // should show nothing changed<br /> git add RadioControl_rf69/ RadioControl_rf69.ino<br /> git commit -m “Removed a delay statement that blocked while waiting for an ack”<br /> Be sure to make your messages reflect what you did for this particular fix. Git supports small incremental changes, and make it possible to roll then back if needed. Please do not wait until the end of the quarter to dump all your changes into the main repository. <br /> git push origin master<br /> This command assumes that you have set origin to the URL for xmit and master to the URL for Jane/Transceiver. It puts your new code into your repository on the cloud.<br /> The next stage is to make a pull request. You are asking to have your code made part of the official Elcano/Transceiver. You are not allowed to directly push to Elcano repositories. If your pull request is accepted, your code becomes part of the Elcano project. A pull request is made from a web browser on Elcano/Transceiver, or whatever repository you are working with.<br /> <br /> === Settings.h ===<br /> This file is required by most processors, but is not kept in any repository. It is meant to include individual vehicle features. All the rest of the code should be written to be portable across a wide variety of vehicles. Specific attributes of a trike (such as wheel diameter, turning radius, etc.) should be kept in a settings.h file for that vehicle. The file SettingsTemplate.h is kept in the General repository. This file should be used to set up an individual setting.h file.<br /> <br /> ==[[FilesPage | Files]] ==<br /> These are media files (pictures, videos, etc.) that are part of the project, but are not maintained under version control.<br /> <br /> == Elcano Project Main Website ==<br /> * [//www.elcanoproject.org]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Low_Level&diff=240 2019-08-13T04:07:44Z

<p>Tfolsom: 5V safe (not 36V safe)</p> <hr /> <div><br /> =LowLevel v3.1 PCB =<br /> <br /> <br /> ==Functionality: ==<br /> <br /> * The LowLevel Board (LLB) is a daughter board (shield) for an Arduino Mega microcontroller. It implements drive-by-wire, turning a trike into a CAN-bus based vehicle compatible with commercial self-driving equipment. The LLB communicates over the CAN bus with the higher-level autonomous system or manual control from the receiver system. It directly manages the actuators: the throttle to the motor, the turning servo, and the brakes. <br /> <br /> <br /> * Motion directives are received on a CAN bus interface, processed, and articulated.<br /> * System status (turn angle, wheel linear velocity) is reported back to CAN bus.<br /> <br /> * LLB v3.x has the following interfaces:<br /> ** One CANbus channel on two connectors; a DB9-M and a three-pin screw terminal. The board includes a 120 ohm terminating resistor.<br /> ** X3 Motor (DB-15M): Interface to E-bike controller<br /> *** Analog voltage (approximately 0v to 4v) output to hub motor throttle<br /> *** Digital outputs for activating reverse and regenerative braking.<br /> *** PWM output for PWM-operated braking (no longer used)<br /> *** Analog inputs for hall sensor feedback from motor controllers supporting this feature. These inputs are NOT 5V SAFE. They absolutely require external supporting circuitry.<br /> *** A few spare connections for future expandability, such as a second DAC output and one digital GPIO.<br /> <br /> DETAILS &gt; [[DB15M]]<br /> <br /> ** Steering Header (RJ45): <br /> *** Two sets of pins to support analog potentiometers (5v, signal input, ground) giving angle of front wheels<br /> *** One PWM output (with its own ground) to drive the steering actuator.<br /> *** This cable is broken out into its component signals using an RJ45 patch jack, mounted near the steering actuator.<br /> ** X4 (ODO): Cyclometer (reed switch) input jack. This is pulled high by default, and brought low when the magnet passes the sensor.<br /> ** High current pluggable terminal for solenoid brakes:<br /> *** Connections for ground, 12v, and 24v.<br /> *** Two relay outputs to solenoids: on/off and 12/24V.<br /> <br /> * The LowLevel runs on 5V power, and provides outputs for sensors. Note that the Arduino Mega 2560's regulator has a fairly low current limit, and should not be used for any significant current supply. The Arduino's DC input jack accepts 12V, and its USB port may be connected to a typical USB power supply. The 12V is provided by a DC-DC converter from the main battery (36 to 50V).<br /> <br /> ==Image: [[File:LowLevel.JPG|1000px]] ==<br /> <br /> <br /> NEXT &gt; [[High Level]]<br /> <br /> <br /> =LowLevel v2.1 PCB =<br /> <br /> <br /> <br /> ==Functionality: ==<br /> <br /> * Version 2.1 used UART serial connections to other boards instead of the CAN bus. It interprets messages from higher-level autonomous systems or manual controls (RC, joystick). It directly manages the state of the actuators; the hub motor, the turning servo, and the brakes. <br /> <br /> <br /> * Depending on the current firmware or operating mode, motion directives are received on one of three interfaces;<br /> ** [[ElcanoSerial]] from the combined [[PilotPage | C3]]/[[PlannerPage | C4]]/[[NavigatorPage | C6]] High Level board <br /> ** RC receiver<br /> ** Manual Joystick<br /> <br /> * LLB v2.x has the following low-level interfaces:<br /> ** X2 Cruise (DB-25F) - [[ElcanoSerial]] messages from High Level.<br /> ** X3 Motor ([[DB15M | DB-15M]]): Analog voltage (0,4v) output hub motor.<br /> ** X1/X5 Turn Sensors (RJ45): SPI wheel angle sensor digital inputs. (Digital urn sensors were never implemented.)<br /> ** X4 (ODO): Cyclometer (reed switch) input jack. Board layout was incorrect. This signal needs to be jumpered to Arduino pin D2.<br /> ** JP9 (8 pin): Joystick analog input signals. <br /> ** JP12 (3 pin): Pulse output signal to steer. <br /> ** JP11 (3 pin): Pulse output signal to apply main brakes. (No longer used)<br /> ** JP5 (4 pin): Left wheel angle sensor analog input. (Little used since it covers 360 degrees and is less accurate)<br /> ** JP6 (4 pin): Right wheel angle sensor analog input. (Trike prefer this, since it is +/- 30 degrees, and more accurate)<br /> <br /> * LLB v3.x makes significant wiring changes:<br /> ** Removes the ElcanoSerial connection and the DB-25F.<br /> ** Removes JP9, joystick analog inputs.<br /> ** Removes headers used to interface the RC receiver.<br /> ** Adds one CANbus interface on a DE-9F socket. For legacy compatibility UART serial is be available on this interface as well.<br /> <br /> <br /> =LowLevel v1.0 PCB =<br /> <br /> * The first version of the LLB was called MegaShieldDB. It had similar functionality, but different connectors. It had five DB connectors.<br /> <br /> <br /> NEXT &gt; [[High Level]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Simulator&diff=239 2019-08-03T21:22:12Z

<p>Tfolsom: </p> <hr /> <div>= Elcano Carla Simulation External Specification =<br /> <br /> CARLA &lt;http://carla.org/&gt; is an open-source driving simulator. During Q4 2019 we will be developing a go-between circuit board to transfer data between CARLA simulation and the sensor slots of the Elcano hardware. The CARLA software allows users to emulate trike parameters under controlled conditions within a virtual world, providing an efficient system for testing sensor behavior, design implementation, and benchmarking overall vehicle progression. The CARLA software can simulate a variety of road conditions such as traffic patterns, inclines, and weather as well as provide users control over vehicle parameters including weight, engine power, and aerodynamic properties.<br /> <br /> <br /> A go-between circuit board will transfer data from vehicle systems to CARLA under a variety of test conditions, enabling the software to replicate responses and return sensor data to be reevaluated for accuracy. Connecting the simulation software to components on both the high and low level boards of the Elcano trike including lidar, sonar, throttle, and brake systems, will allow users to immediately see the results of adjustments to vehicle parameters and highlight physical aspects of the trike within the virtual simulation. This project will enable users to efficiently implement improvements and track the immediate effects of design changes without spending the time and resources it would take to transport or operate the trike in real world test scenarios. It enables developers to improve the software without needing to invest in a vehicle.<br /> <br /> [[File:Full_Block_Diagram.JPG|1000px]]<br /> <br /> == How to Set-up ==<br /> <br /> The components involved in the simulation of the Elcano trike vehicle will be a computer running an instance of CARLA along with our framework and any additional user scripts along with a go-between board to direct data from the trike system to CARLA and back. The flow of data between components can be seen in the project block diagram. The following is an overview of the simulation equipment and necessary connections to be made.<br /> <br /> <br /> '''Hardware''' <br /> * A computer with a mid level graphics card and a display monitor.<br /> * The computer should have the latest stable version of CARLA installed and be able to run it at an acceptable level of performance.<br /> * The computer should have Elcano test framework installed.<br /> * Parallel cable<br /> * Go-between board (Type of board TBD)<br /> * Elcano circuit boards.<br /> * Wires.<br /> <br /> '''Software''' <br /> * CARLA Simulator<br /> * Framework to manage the trike model along with manipulating and transporting data between the board and the simulator.<br /> * User scripts defining whatever conditions will be added to the simulation<br /> * Standard Elcano software runs on microcontrollers.<br /> <br /> == CARLA User Guide ==<br /> <br /> * Connect the USB port on the computer to the one on the go-between board<br /> <br /> * Wire the go-between board to the CAN bus and whatever sensors you would like to replace with simulation input<br /> <br /> * Attach the output from the low level board to the go-between board<br /> <br /> * Run CARLAUE4.exe to spawn a new instance of the CARLA Simulator<br /> <br /> * (Optional) open trike.py and under the line “##TRIKE ATTRIBUTES” adjust or add any of the attributes in the CARLA Trike Model on the wiki to the object assigned to the “trikeControl” object<br /> <br /> * Open a new command window<br /> <br /> * Run framework.py <br /> <br /> * Follow the prompt to insert the trike into the simulation<br /> <br /> * (Optional) Provide a logging file that will contain the output sensor data from the simulation<br /> <br /> * The trike will now await actuating control inputs from the parallel port while outputting the sensor data along the same port as well as to the log file if enabled<br /> <br /> * Open a new command window and run whatever CARLA scripts you would like to test the trike with for example “dynamic_weather.py” included in the CARLA examples will enable different dynamic weather patterns at random within the simulation</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Main_Page&diff=214 2019-07-23T19:15:37Z

<p>Tfolsom: </p> <hr /> <div><br /> <br /> = Welcome to the Elcano Project Wiki =<br /> As the title says, WELCOME TO THE ELCANO PROJECT! Over the past few years many different teams have been working hard to create Cheap and Modular autonomy at the University of Washington Bothell. We are currently working on our first two prototypes which are now in the form of tricycles. With the use of affordable microcontrollers, such as the Arduino Mega 2560 and Raspberry PI, we are working towards creating Autonomy for anyone to rebuild anywhere, and that under $2000 and fully open-source. But we don't plan to stop there, no. That is just the first step in reaching our ultimate goal, which is making our systems applicable to any desired ground vehicles, such as cars and other vehicles. Autonomy is nothing new, in fact it has been around for over 40 years, the difference is that now we have the ability to make it available for anyone who desires furthering their knowledge or simply finding a safer way to work.<br /> <br /> To '''edit articles''' or '''upload files''', please create an account and request editing rights from a [//www.elcanoproject.org/wiki/index.php?title=Special:ListUsers&amp;group=bureaucrat member of the &quot;bureaucrat&quot; group].<br /> <br /> For editing help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.<br /> --------<br /> [[File:Catrikes.JPG|1000px]]<br /> == [[ElcanoIntro | Overview]] ==<br /> Basic concept of how the Elcano Project vehicle works.<br /> <br /> == [[System Architecture]] ==<br /> How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.<br /> <br /> == [[Communication | Communication (CAN Bus)]] ==<br /> How processors exchange data on the vehicle and a description of data packet contents.<br /> <br /> == [[Power System]] ==<br /> How different modules connect to the batteries or power subsystem hardware.<br /> <br /> == [[Low Level]] ==<br /> How the Low Level system uses inputs to control actuators to steer, move, and stop the vehicle.<br /> <br /> == [[High Level]] ==<br /> How the High Level system uses stored maps and inputs from navigational sensors to formulate movement instructions sent to Low Level.<br /> <br /> == [[RemoteControl]] ==<br /> Human control of trike movements through Low Level using hardware connected to Low Level by a radio communication link (drive by radio). Includes on-board controls (drive by wire).<br /> <br /> == [[SensorsPage]] ==<br /> <br /> === [[SteeringSensor]] ===<br /> The front wheel angle detector.<br /> <br /> === [[Sonar]] === <br /> How the sonar subsystem connected to High Level works.<br /> <br /> === [[Lidar]] ===<br /> How the lidar subsystem connected to High Level works.<br /> <br /> === [[ Camera]] ===<br /> How the camera and vision subsystem connected to High Level works.<br /> <br /> == [[ActuatorPage]] ==<br /> <br /> == [[ Board Diagrams]] ==<br /> Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].<br /> <br /> == [[ Simulator]] ==<br /> Using Open-source CARLA platform with a go-between board allows simulation.<br /> <br /> == [[GitUsage | Using Git and GitHub]] ==<br /> Practices for maintaining code and source files on Elcano Project's Github.<br /> <br /> <br /> ==[[FilesPage | Files]] ==<br /> These are media files (pictures, videos, etc.) that are part of the project, but are not maintained under version control.<br /> <br /> == Elcano Project Main Website ==<br /> * [//www.elcanoproject.org]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Communication&diff=213 2019-07-12T19:43:26Z

<p>Tfolsom: Added introduction</p> <hr /> <div>==Elcano CAN Commands==<br /> <br /> === Introduction ===<br /> <br /> Controller Area Network (CAN) is a standard introduced by Bosch in the 1980s. It is widely used to link automotive microprocessors and is required on all cars sold in North America and Europe. Physically there are four wires: Ground, 12V, CanHi and CanLo. A dominant bit has a significant difference between CanHi and CanLo; for a recessive bit the two lines are essentially the same. The interesting parts of a CAN packet are given in the table. The message ID is 11 bits, with low numbers getting priority. A CAN packet contains 0 to 8 bytes of data. The size of a CAN packet is larger, since CAN has significant error detection capability. CAN is a host-less network with most of the work done in hardware.<br /> <br /> <br /> <br /> {| style=&quot;border-spacing:0;&quot;<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| CAN ID<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Origin<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Byte 1<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Byte 2<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Byte 3<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Byte 4<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Byte 5<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Byte 6<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Byte 7<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Byte 8<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Function<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x050<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Receiver<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x80<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| E-stop request<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x050<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Receiver<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x40<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Manual/Auto<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x050<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Receiver<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x0X<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Forward/Reverse<br /> <br /> |-<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x100<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Hi-Level<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x80<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| E-stop request<br /> <br /> |-<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x100<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Hi-Level<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x40<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Manual/Auto<br /> <br /> |-<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x100<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Hi-Level<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x0X<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Forward/Reverse<br /> <br /> |-<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x101<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Hi-Level<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Goal reached<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x200<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Lo-Level<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x80<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| E-stop active<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x200<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Lo-Level<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x40<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Manual/Auto<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x200<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Lo-Level<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x0X<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Forward/Reverse<br /> <br /> |-<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x300<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Receiver<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Throttle<br /> <br /> |-<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x300<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Receiver<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Brake<br /> <br /> |-<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x300<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Receiver<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Steer<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x350<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Hi-Level<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Drive Speed cm/s<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x350<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Hi-Level<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Brake<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x350<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Hi-Level<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Drive angle (10 times degrees)<br /> <br /> |-<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x400<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Lo-Level<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Actual Speed cm/s<br /> <br /> |-<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x400<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Lo-Level<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;background-color:#d0cece;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Actual angle (10 times degrees)<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x420<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Lidar<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| rr<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| rr<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| bb<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| bb<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ww<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| qq<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ss<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ss<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Obstacle Data<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x440<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Sonar<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| rr<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| rr<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| bb<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| bb<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ww<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| qq<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ss<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ss<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Obstacle Data<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x460<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Camera<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| rr<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| rr<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| bb<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| bb<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ww<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| qq<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ss<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ss<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Obstacle Data<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x480<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Camera<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| rr<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| rr<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| bb<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| bb<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ww<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| qq<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Cone Position<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x4A0<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Camera<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| zz<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| zz<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Right road edge<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x4A1<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Camera<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| zz<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| zz<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| <br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Left road edge<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x4C1<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ?<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Goal 1 Position<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x4C2<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ?<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Goal 2 Position<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x4C3<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ?<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Goal 3 Position<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x4C4<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ?<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Goal 4 Position<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x4C5<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ?<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Goal 5 Position<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 0x4C6<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| ?<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| xx<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| yy<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| Goal 6 Position<br /> <br /> |}<br /> '''&lt;nowiki&gt;** Please be aware of the initial CAN-Bus baud rate. If you use MCP2515 module for testing, the baud rate needs to be set to twice the due CAN baud rate&lt;/nowiki&gt;'''<br /> <br /> Not all commands will be implemented. All data are given in integer; floating point is not used.<br /> <br /> ===Command 0x50, 0x100, and 0x200 (status change) ===<br /> <br /> use Byte 1.<br /> <br /> If bit 0x80 is set, emergency stop is active. <br /> <br /> Bit 0x40 when set puts the trike in autonomous mode; reset puts it in manual mode.<br /> <br /> If bit 0x04 is zero, the trike is going forward. When the receiver (0x50) sets bit 0x04, it is requesting reverse. Low Level responds with a 0x200 message with bit 0x04 set meaning that reverse is active, bit 0x02 set meaning that reverse is pending or bit 0x01 set meaning that reverse is not available.<br /> <br /> The Receiver would output a 0x50 message only when the status changes. It expects to receive a 0x200 message for e-stop active shortly afterwards (maybe 100 ms), and will resend 0x50 until it receives a 0x200. <br /> <br /> ===Goal Reached (CANID 0x101)===<br /> <br /> One byte<br /> <br /> If 0x80 is set, all goals have been reached and the vehicle should stop.<br /> <br /> Bit 0x01: goal one has been reached and goal two is next.<br /> <br /> Bits 0x02, 0x04, 0x08, 0x10, 0x20: Reached goals 2, 3, 4, 5, and 6 respectively.<br /> <br /> ===Command 0x300===<br /> <br /> gives the relative amount to go, stop or turn. For each, 12 bits will suffice, and fewer bytes than indicated could be used. These are uncalibrated relative amounts from minimum to maximum. At present, positive values are throttle and negative values are brake, and it is impossible to accelerate of brake at the same time. In the future, we may want to allow both simultaneously. At present brakes are either on or off; we may use intermediate values to pulse the brakes. A negative steering value indicates left; positive value indicates right; 0 is straight.<br /> <br /> ===DRIVE (CANID 0x350) ===<br /> <br /> 0x350 ComandedSpeed, Brake, ComandedSteerAngle<br /> <br /> ID350 gives the command drive speed, brake and angle.<br /> <br /> This utilizes 6 of the 8 data bytes<br /> <br /> ComandedSpeed is a 16-bit signed integer giving the speed for the rear wheel in centimeters per second. It occupies data bytes 1 and 2. The value is the speed, in centimeters / second. Maximum value is 0x7FFF = 32767 cm/s = 730 mph.<br /> <br /> Brake is a 16-bit signed integer giving signal to brake. Currently brake is only on or off, but could have pulses added later to be different levels of braking.<br /> <br /> ComandedSteerAngle is a16-bit signed integer that specifies the steer angle (in degrees times 10) of the vehicle. Negative value indicates left; positive value indicates right; 0 is straight. It occupies data bytes 5 and 6. Maximum value is 1800; Minimum value is -1800. The trikes are not capable of turning more than ±30°, but other vehicles could be holomorphic.<br /> <br /> e.g. &amp;nbsp;commanding 1.5 m/s with a 2.1° left turn gives<br /> <br /> {| style=&quot;border-spacing:0;&quot;<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 288<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 1500<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| -21<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| decimal<br /> <br /> |-<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 120<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| 05 DC<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| FF EB<br /> | style=&quot;border:0.0007in solid #000000;padding-top:0in;padding-bottom:0in;padding-left:0.075in;padding-right:0.075in;&quot;| hex<br /> <br /> |}<br /> <br /> ===ACTUAL (CANID 0x400) ===<br /> <br /> 0x400 ActualSpeed, ActualAngle<br /> <br /> ID400 gives the reports the actual speed and angle from the low-level board to the high-level.<br /> <br /> This utilizes 4 of the 8 data bytes<br /> <br /> ActualSpeed is a 16-bit signed integer giving the speed for the rear wheel in centimeters per second. It occupies data bytes 1 and 2, formatted identically to ComandedSpeed in DRIVE(0x350) above.<br /> <br /> ActualAngle is a16-bit signed integer that specifies the steer angle (in degrees times 10) of the vehicle. It occupies data bytes 5 and 6, formatted identically to ComandedSteerAngle in DRIVE(0x350) above.<br /> <br /> ===Obstacle Data (0x420, 0x440, 0x460)===<br /> <br /> Uses 6 or 8 bytes<br /> <br /> Bytes 1,2: Range to obstacle centroid in cm.<br /> <br /> Bytes 3,4: Bearing to obstacle centroid in degrees times 10. Negative is left; positive is right.<br /> <br /> Byte 5: Obstacle half-width in degrees times 10. If bearing is b and half-width is w, obstacle extends from b-w to b+w. For sensors with limited resolution, byte 5 gives the resolution. For example, a sonar that covers 30 degrees would set byte 5 to 150.<br /> <br /> Byte 6: Quality of the signal/data. 0 = no data; 255 = highest quality<br /> <br /> Bytes 7,8: Obstacle slant in degrees times 10 (optional). If omitted or 0, the obstacle is perpendicular to the bearing. Otherwise a negative angle indicates that the left side of the obstacle is closer, and a positive angle means the left side is farther than the centroid.<br /> <br /> ===Cone Position (0x480)===<br /> <br /> Position of the next cone, using 6 bytes in the same format as obstacle data.<br /> <br /> Byte 5 is the half-width of the cone at the base.<br /> <br /> ===Road Edge (0x4A0, 0x4A1)===<br /> <br /> Estimated distance from vehicle edge to road edge in cm based on present trajectory.<br /> <br /> Bytes 1,2: At present vehicle position<br /> <br /> Bytes 3,4: At a near future position (to be defined)<br /> <br /> Bytes 5,6: At a farther future position (to be defined)<br /> <br /> ===Goal Positions (0x4C1 … 0x4C6)===<br /> <br /> Positions of cones or other goals. Not defined how this would be input; perhaps from a user interface. They can be hard coded for now.<br /> <br /> Bytes 1-4: East position in cm<br /> <br /> Bytes 5-8 North position in cm.</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=ActuatorPage&diff=205 2019-07-10T16:04:49Z

<p>Tfolsom: /* Rotary servos */</p> <hr /> <div><br /> <br /> = Actuators and Motor =<br /> <br /> ==Description and Function ==<br /> Elcano uses a linear servo (actuator) to control steering hardware. Brake control had used a linear servo, but in Spring 2018, brake control was replaced by a Solenoid system. An electric bicycle controller drives the rear wheel.The recumbent Catrikes use a hub motor. The ELF uses an electric motor that drives a chain on the left side of the vehicle. The ELF uses a rotary servo for steering.<br /> <br /> == Parts and Materials ==<br /> <br /> # Two solenoids and assembly for braking. See '''&quot;Creating and assembling a solenoid mount&quot;''')<br /> # 4 inch or 6&quot; linear steering servo (Catrikes) or rotary servo (ELF)<br /> # servo mounts<br /> # linkage hardware to connect servos to brakes and steering<br /> # electric bike conversion kit<br /> # power subsystems (batteries, connectors, wiring) for servos and motor<br /> <br /> Detailed bill of materials: https://github.com/elcano/elcano/blob/master/Documentation/Elcano_BOM.xls<br /> <br /> == Drive System ==<br /> <br /> The Catrikes have no pedaling or chain. The vehicle is powered by a hub motor.<br /> <br /> The ELF has two chains. One is driven by pedaling and the other by an electric motor. Both chains have freewheels, so they do not interfere with each other.<br /> <br /> The electric motor is powered by an e-bike controller. The ELF uses a Kelly controller. The Catrikes are scheduled to be upgraded to the same controller: https://www.kellycontroller.com/shop/kbs-e/<br /> <br /> The e-bike controller converts the main voltage (36 or 48V) from DC to three phase to power the motor. The power can draw 25 or 30 Amp and is potentially lethal. Interface to the e-bike controller is an analog signal from the low-level board that gives the throttle.<br /> <br /> The Kelly e-bike controller has some additional functionality that has not yet been used:<br /> <br /> -- There are phase signals from the hub motor that offer finer speed and position control since the signal occurs about 20 times per wheel revolution instead of the current once per revolution.<br /> <br /> -- It is possible to do regenerative braking.<br /> <br /> -- The controller supports driving the wheel in reverse.<br /> <br /> == Steering System ==<br /> There are two main steering signals: <br /> <br /> 1. Signal Out is a 1 to 2 ms pulse sent from the Arduino to control the steering actuator.<br /> <br /> 2. Signal In is a 5 V analog feedback signal that gives the pointing angle of the wheel. There is one such signal for each of the two front wheels. More details on [[SteeringSensor]].<br /> <br /> === Linear servos ===<br /> <br /> The linear steering servo on the Catrikes https://www.servocity.com/hdls-6-2-12v has 25 lb. thrust with 6&quot; throw. In the past we have used 4&quot; throw. A more suitable part may be https://www.servocity.com/motors-actuators/linear-actuators/heavy-duty-linear-actuators. The servo is powered by a pulse signal. The actuator would be powered by a relay to give it either +12V or -12V and use angle feedback to stop motion. Using the actuator requires hardware and software changes.<br /> <br /> The steering servo or actuator is powered by 12V DC. It produces 5V DC which can be used by other equipment. Steering is controlled by sending a pulse to the actuator. A pulse width of approximately 1 ms will cause the actuator to fully extend (right turn on Catrike). A pulse of about 2 ms will fully retract the actuator. A pulse of 1.5 ms will keep the vehicle pointed straight ahead. There is some variation in these voltages; thus the Catrikes have a mechanical adjustment for fine-tuning the position for going straight. Typically there are about 30 pulses per second; the exact rate does not matter. At 12V, servo operating speed is 56mm/s with no load or 35 mm/s at maximum load. <br /> <br /> The actuator interfaces to the Arduino over a three wire servo connector that is standard for RC planes and cars. The three wires are Signal Out, Ground, and Power. The power wire is not used since both the actuator and Arduino have their own sources of power. The actuator is fused for 5 Amps and has blown fuses. Be careful not to drive it beyond physical limits.<br /> <br /> === Servo Problems ===<br /> <br /> It is important to note that under certain circumstances the servo can critically damage itself. It is a $300 part and we have had ten of them fail. Most of the failed servos were used for braking; this poor performance was the motivation for changing to the solenoid braking system. It appears that the servo needs its power turned on only AFTER providing it a PWM signal. Further, providing it a signal corresponding to its current position will prevent it from trying to move during startup. The low-level firmware (early 2019) has been adapted to perform this, with an optional external relay board.<br /> <br /> Ben Rockhold (December 2018) wrote: <br /> <br /> So, worth noting that the linear actuators claim a duty cycle of 25%. I’ve just identified the driver chip, which has a duty cycle of 20% at 2A — with no thermal shutdown or safety. If you use the actuator continuously, it will just die. The driver is the Toshiba TB6612FNG, available from digikey.com TB6612FNG,C,8,EL Toshiba Semiconductor and Storage | Integrated Circuits (ICs) | DigiKeyMotor Driver Power MOSFET Parallel 24-SSOP<br /> <br /> Thinking about this some more; once we’re using a PID we can use the deltas — cap them to prevent long distance moves, and add them to an accumulator to keep track of total distance commanded. If the accumulator fills, we enter an error state and can’t steer. Then reduce the accumulator at a fixed rate, so that steering availability returns over time … or, probably easier… we could just use a different motor driver. Wire the driver to the DC motor in the servo that failed, and use the external feedback instead of the potentiometer inside the actuator. <br /> <br /> === Rotary servos ===<br /> <br /> The ELF uses a i00600 Torxis rotary servo.<br /> <br /> https://www.pololu.com/product/1390<br /> <br /> == Braking System ==<br /> Two solenoids (Johnson Electric 150 174432-024; available from Newark/Element14) connected directly to the brake cables control braking. This system has some advantages and disadvantages over connecting the brake cables to a servo. Advantages are that a solenoid provides full braking force in milliseconds. Disadvantages include a lack of control over braking force and brake failure on loss of power: a solenoid alone will not hold position without adequate current from the batteries. Using a solenoid instead of a servo also requires additional hardware and software to control the solenoid.<br /> <br /> === Building a solenoid mount for braking ===<br /> ==== Creating and assembling a solenoid mount ====<br /> <br /> # Select a solenoid according to required braking force and throw. Information like force as a function of throw is provided in product data sheets<br /> ## measure how much force is required to initially pull the brake cable from rest (against spring tension and friction) and to completely close the brake, stopping the loaded vehicle<br /> ## measure the distance the brake cable travels from rest to closed position; this is the required throw<br /> ## select a solenoid that provides adequate force over the entire throw <br /> ## be aware that a solenoid provides less force when heated by environment and electrical load<br /> # Because solenoids generate heat, select metal stock with enough area to radiate heat from the solenoid; this information may be contained in the solenoid's data sheet <br /> # If needed: use measurements from the solenoid or solenoid data sheet to modify the drilling template provided below to fit the mounting plate on the selected solenoid. Make sure holes are not too close to the edge of the material so there is enough room to drill<br /> # Adhere the printed drilling template to the metal stock using rubber cement. Work quickly (&lt; 30 seconds after application of rubber cement) to apply the paper template smoothly on the surface before the adhesive dries<br /> # Drill holes where shown on the template. Drill pilot holes using a small bit before using large drill bits <br /> # Check that all parts (including the solenoid) fit the drilled screw holes and use screws and nuts to attach the two angle bracket stops and the solenoid base plate to the solenoid mount<br /> # install the brake shield ends (threaded metal parts) to the brake shield end mount and thread the brake cable through<br /> # Screw the three bridle pieces together around the barrel end of the brake cable and attach to the solenoid arm with a screw and nut (or other hardware, depending on the solenoid arm end) <br /> # Check that the solenoid arm moves freely along its entire throw with the bridle and brake cable attached<br /> # Attach electrical connectors to the solenoid and attach the solenoid to the solenoid controller to test that brakes open and close when the solenoid is switched off and on<br /> <br /> ==== Supplies ====<br /> # existing bicycle braking system using barrel-ended brake cable (to use our brake cable bridle)<br /> # one solenoid for each brake (it may be possible to alter the design included on this page to use one solenoid for two brakes, but make sure it has enough force for two brakes)<br /> # metal stock large enough to create an entire mount for each solenoid; this mount doubles as a heat sink and should have enough total area to radiate heat<br /> # metal stock to create a bridle attaching the solenoid arm to the brake cable<br /> # metal stock to create a stop for the bridle on the solenoid arm and a mount for the brake cable end<br /> (have extra metal stock to recreate each drilled piece in case of mistakes)<br /> # material such as screws, plates, or u-bolts to attach the solenoid mount to the vehicle<br /> # screws and nuts to hold all solenoid mount parts together<br /> # a printed drilling template, modified to fit your hardware if needed, one for each solenoid mount (neatly cut out individual pieces)<br /> # rubber cement or other adhesive for adhering the drilling template<br /> # hand drill or drill press<br /> # clamps and disposable wood block(s) for drilling<br /> # files or other abrasive for removing metal burs and sharp edges<br /> # personal safety equipment such as gloves and eye protection for when cutting, drilling, and filing<br /> <br /> === Wiring the solenoid ===<br /> The solenoids are connected in parallel to the [[LowLevel]] board's relay outputs. This is a height current connection, and is mean to switch between 24v (for striking) and 12v (for maintaining). The solenoids only have a 25% duty cycle at 24v, so be careful not to leave them connected to power for too long. It is also critically important to include a snubbing diode in parallel with any inductive load. <br /> As of version 3.0 the [[LowLevel]] board includes one on its brake output. We are using a pair of 1N400x series diodes rated for &gt;50v and 1A (specifically 1N4001). This prevents extreme high voltage transients generated by switching the inductor from finding an inconvenient path to ground via our sensitive electronics. Quite a few relay shields have lost their driving transistors prior to the addition of these diodes.<br /> <br /> <br /> == Links and Resources ==<br /> See the attached solenoid data sheet for its specific characteristics.<br /> Other linear servos: https://www.servocity.com/servos/heavy-duty-linear-servos<br /> <br /> NEXT &gt; [[Board Diagrams]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=ActuatorPage&diff=204 2019-07-10T15:53:00Z

<p>Tfolsom: /* Drive System */</p> <hr /> <div><br /> <br /> = Actuators and Motor =<br /> <br /> ==Description and Function ==<br /> Elcano uses a linear servo (actuator) to control steering hardware. Brake control had used a linear servo, but in Spring 2018, brake control was replaced by a Solenoid system. An electric bicycle controller drives the rear wheel.The recumbent Catrikes use a hub motor. The ELF uses an electric motor that drives a chain on the left side of the vehicle. The ELF uses a rotary servo for steering.<br /> <br /> == Parts and Materials ==<br /> <br /> # Two solenoids and assembly for braking. See '''&quot;Creating and assembling a solenoid mount&quot;''')<br /> # 4 inch or 6&quot; linear steering servo (Catrikes) or rotary servo (ELF)<br /> # servo mounts<br /> # linkage hardware to connect servos to brakes and steering<br /> # electric bike conversion kit<br /> # power subsystems (batteries, connectors, wiring) for servos and motor<br /> <br /> Detailed bill of materials: https://github.com/elcano/elcano/blob/master/Documentation/Elcano_BOM.xls<br /> <br /> == Drive System ==<br /> <br /> The Catrikes have no pedaling or chain. The vehicle is powered by a hub motor.<br /> <br /> The ELF has two chains. One is driven by pedaling and the other by an electric motor. Both chains have freewheels, so they do not interfere with each other.<br /> <br /> The electric motor is powered by an e-bike controller. The ELF uses a Kelly controller. The Catrikes are scheduled to be upgraded to the same controller: https://www.kellycontroller.com/shop/kbs-e/<br /> <br /> The e-bike controller converts the main voltage (36 or 48V) from DC to three phase to power the motor. The power can draw 25 or 30 Amp and is potentially lethal. Interface to the e-bike controller is an analog signal from the low-level board that gives the throttle.<br /> <br /> The Kelly e-bike controller has some additional functionality that has not yet been used:<br /> <br /> -- There are phase signals from the hub motor that offer finer speed and position control since the signal occurs about 20 times per wheel revolution instead of the current once per revolution.<br /> <br /> -- It is possible to do regenerative braking.<br /> <br /> -- The controller supports driving the wheel in reverse.<br /> <br /> == Steering System ==<br /> There are two main steering signals: <br /> <br /> 1. Signal Out is a 1 to 2 ms pulse sent from the Arduino to control the steering actuator.<br /> <br /> 2. Signal In is a 5 V analog feedback signal that gives the pointing angle of the wheel. There is one such signal for each of the two front wheels. More details on [[SteeringSensor]].<br /> <br /> === Linear servos ===<br /> <br /> The linear steering servo on the Catrikes https://www.servocity.com/hdls-6-2-12v has 25 lb. thrust with 6&quot; throw. In the past we have used 4&quot; throw. A more suitable part may be https://www.servocity.com/motors-actuators/linear-actuators/heavy-duty-linear-actuators. The servo is powered by a pulse signal. The actuator would be powered by a relay to give it either +12V or -12V and use angle feedback to stop motion. Using the actuator requires hardware and software changes.<br /> <br /> The steering servo or actuator is powered by 12V DC. It produces 5V DC which can be used by other equipment. Steering is controlled by sending a pulse to the actuator. A pulse width of approximately 1 ms will cause the actuator to fully extend (right turn on Catrike). A pulse of about 2 ms will fully retract the actuator. A pulse of 1.5 ms will keep the vehicle pointed straight ahead. There is some variation in these voltages; thus the Catrikes have a mechanical adjustment for fine-tuning the position for going straight. Typically there are about 30 pulses per second; the exact rate does not matter. At 12V, servo operating speed is 56mm/s with no load or 35 mm/s at maximum load. <br /> <br /> The actuator interfaces to the Arduino over a three wire servo connector that is standard for RC planes and cars. The three wires are Signal Out, Ground, and Power. The power wire is not used since both the actuator and Arduino have their own sources of power. The actuator is fused for 5 Amps and has blown fuses. Be careful not to drive it beyond physical limits.<br /> <br /> === Servo Problems ===<br /> <br /> It is important to note that under certain circumstances the servo can critically damage itself. It is a $300 part and we have had ten of them fail. Most of the failed servos were used for braking; this poor performance was the motivation for changing to the solenoid braking system. It appears that the servo needs its power turned on only AFTER providing it a PWM signal. Further, providing it a signal corresponding to its current position will prevent it from trying to move during startup. The low-level firmware (early 2019) has been adapted to perform this, with an optional external relay board.<br /> <br /> Ben Rockhold (December 2018) wrote: <br /> <br /> So, worth noting that the linear actuators claim a duty cycle of 25%. I’ve just identified the driver chip, which has a duty cycle of 20% at 2A — with no thermal shutdown or safety. If you use the actuator continuously, it will just die. The driver is the Toshiba TB6612FNG, available from digikey.com TB6612FNG,C,8,EL Toshiba Semiconductor and Storage | Integrated Circuits (ICs) | DigiKeyMotor Driver Power MOSFET Parallel 24-SSOP<br /> <br /> Thinking about this some more; once we’re using a PID we can use the deltas — cap them to prevent long distance moves, and add them to an accumulator to keep track of total distance commanded. If the accumulator fills, we enter an error state and can’t steer. Then reduce the accumulator at a fixed rate, so that steering availability returns over time … or, probably easier… we could just use a different motor driver. Wire the driver to the DC motor in the servo that failed, and use the external feedback instead of the potentiometer inside the actuator. <br /> <br /> === Rotary servos ===<br /> <br /> The ELF uses a rotary actuator.<br /> <br /> <br /> == Braking System ==<br /> Two solenoids (Johnson Electric 150 174432-024; available from Newark/Element14) connected directly to the brake cables control braking. This system has some advantages and disadvantages over connecting the brake cables to a servo. Advantages are that a solenoid provides full braking force in milliseconds. Disadvantages include a lack of control over braking force and brake failure on loss of power: a solenoid alone will not hold position without adequate current from the batteries. Using a solenoid instead of a servo also requires additional hardware and software to control the solenoid.<br /> <br /> === Building a solenoid mount for braking ===<br /> ==== Creating and assembling a solenoid mount ====<br /> <br /> # Select a solenoid according to required braking force and throw. Information like force as a function of throw is provided in product data sheets<br /> ## measure how much force is required to initially pull the brake cable from rest (against spring tension and friction) and to completely close the brake, stopping the loaded vehicle<br /> ## measure the distance the brake cable travels from rest to closed position; this is the required throw<br /> ## select a solenoid that provides adequate force over the entire throw <br /> ## be aware that a solenoid provides less force when heated by environment and electrical load<br /> # Because solenoids generate heat, select metal stock with enough area to radiate heat from the solenoid; this information may be contained in the solenoid's data sheet <br /> # If needed: use measurements from the solenoid or solenoid data sheet to modify the drilling template provided below to fit the mounting plate on the selected solenoid. Make sure holes are not too close to the edge of the material so there is enough room to drill<br /> # Adhere the printed drilling template to the metal stock using rubber cement. Work quickly (&lt; 30 seconds after application of rubber cement) to apply the paper template smoothly on the surface before the adhesive dries<br /> # Drill holes where shown on the template. Drill pilot holes using a small bit before using large drill bits <br /> # Check that all parts (including the solenoid) fit the drilled screw holes and use screws and nuts to attach the two angle bracket stops and the solenoid base plate to the solenoid mount<br /> # install the brake shield ends (threaded metal parts) to the brake shield end mount and thread the brake cable through<br /> # Screw the three bridle pieces together around the barrel end of the brake cable and attach to the solenoid arm with a screw and nut (or other hardware, depending on the solenoid arm end) <br /> # Check that the solenoid arm moves freely along its entire throw with the bridle and brake cable attached<br /> # Attach electrical connectors to the solenoid and attach the solenoid to the solenoid controller to test that brakes open and close when the solenoid is switched off and on<br /> <br /> ==== Supplies ====<br /> # existing bicycle braking system using barrel-ended brake cable (to use our brake cable bridle)<br /> # one solenoid for each brake (it may be possible to alter the design included on this page to use one solenoid for two brakes, but make sure it has enough force for two brakes)<br /> # metal stock large enough to create an entire mount for each solenoid; this mount doubles as a heat sink and should have enough total area to radiate heat<br /> # metal stock to create a bridle attaching the solenoid arm to the brake cable<br /> # metal stock to create a stop for the bridle on the solenoid arm and a mount for the brake cable end<br /> (have extra metal stock to recreate each drilled piece in case of mistakes)<br /> # material such as screws, plates, or u-bolts to attach the solenoid mount to the vehicle<br /> # screws and nuts to hold all solenoid mount parts together<br /> # a printed drilling template, modified to fit your hardware if needed, one for each solenoid mount (neatly cut out individual pieces)<br /> # rubber cement or other adhesive for adhering the drilling template<br /> # hand drill or drill press<br /> # clamps and disposable wood block(s) for drilling<br /> # files or other abrasive for removing metal burs and sharp edges<br /> # personal safety equipment such as gloves and eye protection for when cutting, drilling, and filing<br /> <br /> === Wiring the solenoid ===<br /> The solenoids are connected in parallel to the [[LowLevel]] board's relay outputs. This is a height current connection, and is mean to switch between 24v (for striking) and 12v (for maintaining). The solenoids only have a 25% duty cycle at 24v, so be careful not to leave them connected to power for too long. It is also critically important to include a snubbing diode in parallel with any inductive load. <br /> As of version 3.0 the [[LowLevel]] board includes one on its brake output. We are using a pair of 1N400x series diodes rated for &gt;50v and 1A (specifically 1N4001). This prevents extreme high voltage transients generated by switching the inductor from finding an inconvenient path to ground via our sensitive electronics. Quite a few relay shields have lost their driving transistors prior to the addition of these diodes.<br /> <br /> <br /> == Links and Resources ==<br /> See the attached solenoid data sheet for its specific characteristics.<br /> Other linear servos: https://www.servocity.com/servos/heavy-duty-linear-servos<br /> <br /> NEXT &gt; [[Board Diagrams]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=ActuatorPage&diff=203 2019-07-10T15:35:31Z

<p>Tfolsom: Added Ben's information on steering servos.</p> <hr /> <div><br /> <br /> = Actuators and Motor =<br /> <br /> ==Description and Function ==<br /> Elcano uses a linear servo (actuator) to control steering hardware. Brake control had used a linear servo, but in Spring 2018, brake control was replaced by a Solenoid system. An electric bicycle controller drives the rear wheel.The recumbent Catrikes use a hub motor. The ELF uses an electric motor that drives a chain on the left side of the vehicle. The ELF uses a rotary servo for steering.<br /> <br /> == Parts and Materials ==<br /> <br /> # Two solenoids and assembly for braking. See '''&quot;Creating and assembling a solenoid mount&quot;''')<br /> # 4 inch or 6&quot; linear steering servo (Catrikes) or rotary servo (ELF)<br /> # servo mounts<br /> # linkage hardware to connect servos to brakes and steering<br /> # electric bike conversion kit<br /> # power subsystems (batteries, connectors, wiring) for servos and motor<br /> <br /> Detailed bill of materials: https://github.com/elcano/elcano/blob/master/Documentation/Elcano_BOM.xls<br /> <br /> == Drive System ==<br /> <br /> The Catrikes have no pedaling or chain. The vehicle is powered by a hub motor.<br /> <br /> The ELF has two chains. One is driven by pedaling and the other by an electric motor. Both chains have freewheels, so they do not interfere with each other.<br /> <br /> The electric motor is powered by an e-bike controller.<br /> <br /> == Steering System ==<br /> There are two main steering signals: <br /> <br /> 1. Signal Out is a 1 to 2 ms pulse sent from the Arduino to control the steering actuator.<br /> <br /> 2. Signal In is a 5 V analog feedback signal that gives the pointing angle of the wheel. There is one such signal for each of the two front wheels. More details on [[SteeringSensor]].<br /> <br /> === Linear servos ===<br /> <br /> The linear steering servo on the Catrikes https://www.servocity.com/hdls-6-2-12v has 25 lb. thrust with 6&quot; throw. In the past we have used 4&quot; throw. A more suitable part may be https://www.servocity.com/motors-actuators/linear-actuators/heavy-duty-linear-actuators. The servo is powered by a pulse signal. The actuator would be powered by a relay to give it either +12V or -12V and use angle feedback to stop motion. Using the actuator requires hardware and software changes.<br /> <br /> The steering servo or actuator is powered by 12V DC. It produces 5V DC which can be used by other equipment. Steering is controlled by sending a pulse to the actuator. A pulse width of approximately 1 ms will cause the actuator to fully extend (right turn on Catrike). A pulse of about 2 ms will fully retract the actuator. A pulse of 1.5 ms will keep the vehicle pointed straight ahead. There is some variation in these voltages; thus the Catrikes have a mechanical adjustment for fine-tuning the position for going straight. Typically there are about 30 pulses per second; the exact rate does not matter. At 12V, servo operating speed is 56mm/s with no load or 35 mm/s at maximum load. <br /> <br /> The actuator interfaces to the Arduino over a three wire servo connector that is standard for RC planes and cars. The three wires are Signal Out, Ground, and Power. The power wire is not used since both the actuator and Arduino have their own sources of power. The actuator is fused for 5 Amps and has blown fuses. Be careful not to drive it beyond physical limits.<br /> <br /> === Servo Problems ===<br /> <br /> It is important to note that under certain circumstances the servo can critically damage itself. It is a $300 part and we have had ten of them fail. Most of the failed servos were used for braking; this poor performance was the motivation for changing to the solenoid braking system. It appears that the servo needs its power turned on only AFTER providing it a PWM signal. Further, providing it a signal corresponding to its current position will prevent it from trying to move during startup. The low-level firmware (early 2019) has been adapted to perform this, with an optional external relay board.<br /> <br /> Ben Rockhold (December 2018) wrote: <br /> <br /> So, worth noting that the linear actuators claim a duty cycle of 25%. I’ve just identified the driver chip, which has a duty cycle of 20% at 2A — with no thermal shutdown or safety. If you use the actuator continuously, it will just die. The driver is the Toshiba TB6612FNG, available from digikey.com TB6612FNG,C,8,EL Toshiba Semiconductor and Storage | Integrated Circuits (ICs) | DigiKeyMotor Driver Power MOSFET Parallel 24-SSOP<br /> <br /> Thinking about this some more; once we’re using a PID we can use the deltas — cap them to prevent long distance moves, and add them to an accumulator to keep track of total distance commanded. If the accumulator fills, we enter an error state and can’t steer. Then reduce the accumulator at a fixed rate, so that steering availability returns over time … or, probably easier… we could just use a different motor driver. Wire the driver to the DC motor in the servo that failed, and use the external feedback instead of the potentiometer inside the actuator. <br /> <br /> === Rotary servos ===<br /> <br /> The ELF uses a rotary actuator.<br /> <br /> <br /> == Braking System ==<br /> Two solenoids (Johnson Electric 150 174432-024; available from Newark/Element14) connected directly to the brake cables control braking. This system has some advantages and disadvantages over connecting the brake cables to a servo. Advantages are that a solenoid provides full braking force in milliseconds. Disadvantages include a lack of control over braking force and brake failure on loss of power: a solenoid alone will not hold position without adequate current from the batteries. Using a solenoid instead of a servo also requires additional hardware and software to control the solenoid.<br /> <br /> === Building a solenoid mount for braking ===<br /> ==== Creating and assembling a solenoid mount ====<br /> <br /> # Select a solenoid according to required braking force and throw. Information like force as a function of throw is provided in product data sheets<br /> ## measure how much force is required to initially pull the brake cable from rest (against spring tension and friction) and to completely close the brake, stopping the loaded vehicle<br /> ## measure the distance the brake cable travels from rest to closed position; this is the required throw<br /> ## select a solenoid that provides adequate force over the entire throw <br /> ## be aware that a solenoid provides less force when heated by environment and electrical load<br /> # Because solenoids generate heat, select metal stock with enough area to radiate heat from the solenoid; this information may be contained in the solenoid's data sheet <br /> # If needed: use measurements from the solenoid or solenoid data sheet to modify the drilling template provided below to fit the mounting plate on the selected solenoid. Make sure holes are not too close to the edge of the material so there is enough room to drill<br /> # Adhere the printed drilling template to the metal stock using rubber cement. Work quickly (&lt; 30 seconds after application of rubber cement) to apply the paper template smoothly on the surface before the adhesive dries<br /> # Drill holes where shown on the template. Drill pilot holes using a small bit before using large drill bits <br /> # Check that all parts (including the solenoid) fit the drilled screw holes and use screws and nuts to attach the two angle bracket stops and the solenoid base plate to the solenoid mount<br /> # install the brake shield ends (threaded metal parts) to the brake shield end mount and thread the brake cable through<br /> # Screw the three bridle pieces together around the barrel end of the brake cable and attach to the solenoid arm with a screw and nut (or other hardware, depending on the solenoid arm end) <br /> # Check that the solenoid arm moves freely along its entire throw with the bridle and brake cable attached<br /> # Attach electrical connectors to the solenoid and attach the solenoid to the solenoid controller to test that brakes open and close when the solenoid is switched off and on<br /> <br /> ==== Supplies ====<br /> # existing bicycle braking system using barrel-ended brake cable (to use our brake cable bridle)<br /> # one solenoid for each brake (it may be possible to alter the design included on this page to use one solenoid for two brakes, but make sure it has enough force for two brakes)<br /> # metal stock large enough to create an entire mount for each solenoid; this mount doubles as a heat sink and should have enough total area to radiate heat<br /> # metal stock to create a bridle attaching the solenoid arm to the brake cable<br /> # metal stock to create a stop for the bridle on the solenoid arm and a mount for the brake cable end<br /> (have extra metal stock to recreate each drilled piece in case of mistakes)<br /> # material such as screws, plates, or u-bolts to attach the solenoid mount to the vehicle<br /> # screws and nuts to hold all solenoid mount parts together<br /> # a printed drilling template, modified to fit your hardware if needed, one for each solenoid mount (neatly cut out individual pieces)<br /> # rubber cement or other adhesive for adhering the drilling template<br /> # hand drill or drill press<br /> # clamps and disposable wood block(s) for drilling<br /> # files or other abrasive for removing metal burs and sharp edges<br /> # personal safety equipment such as gloves and eye protection for when cutting, drilling, and filing<br /> <br /> === Wiring the solenoid ===<br /> The solenoids are connected in parallel to the [[LowLevel]] board's relay outputs. This is a height current connection, and is mean to switch between 24v (for striking) and 12v (for maintaining). The solenoids only have a 25% duty cycle at 24v, so be careful not to leave them connected to power for too long. It is also critically important to include a snubbing diode in parallel with any inductive load. <br /> As of version 3.0 the [[LowLevel]] board includes one on its brake output. We are using a pair of 1N400x series diodes rated for &gt;50v and 1A (specifically 1N4001). This prevents extreme high voltage transients generated by switching the inductor from finding an inconvenient path to ground via our sensitive electronics. Quite a few relay shields have lost their driving transistors prior to the addition of these diodes.<br /> <br /> <br /> == Links and Resources ==<br /> See the attached solenoid data sheet for its specific characteristics.<br /> Other linear servos: https://www.servocity.com/servos/heavy-duty-linear-servos<br /> <br /> NEXT &gt; [[Board Diagrams]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Main_Page&diff=202 2019-07-10T14:52:05Z

<p>Tfolsom: /* Steering */</p> <hr /> <div><br /> <br /> = Welcome to the Elcano Project Wiki =<br /> As the title says, WELCOME TO THE ELCANO PROJECT! Over the past few years many different teams have been working hard to create Cheap and Modular autonomy at the University of Washington Bothell. We are currently working on our first two prototypes which are now in the form of tricycles. With the use of affordable microcontrollers, such as the Arduino Mega 2560 and Raspberry PI, we are working towards creating Autonomy for anyone to rebuild anywhere, and that under $2000 and fully open-source. But we don't plan to stop there, no. That is just the first step in reaching our ultimate goal, which is making our systems applicable to any desired ground vehicles, such as cars and other vehicles. Autonomy is nothing new, in fact it has been around for over 40 years, the difference is that now we have the ability to make it available for anyone who desires furthering their knowledge or simply finding a safer way to work.<br /> <br /> To '''edit articles''' or '''upload files''', please create an account and request editing rights from a [//www.elcanoproject.org/wiki/index.php?title=Special:ListUsers&amp;group=bureaucrat member of the &quot;bureaucrat&quot; group].<br /> <br /> For editing help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.<br /> --------<br /> [[File:Catrikes.JPG|1000px]]<br /> == [[ElcanoIntro | Overview]] ==<br /> Basic concept of how the Elcano Project vehicle works.<br /> <br /> == [[System Architecture]] ==<br /> How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.<br /> <br /> == [[Power System]] ==<br /> How different modules connect to the batteries or power subsystem hardware.<br /> <br /> == [[Low Level]] ==<br /> How the Low Level system uses inputs to control actuators to steer, move, and stop the vehicle.<br /> <br /> == [[High Level]] ==<br /> How the High Level system uses stored maps and inputs from navigational sensors to formulate movement instructions sent to Low Level.<br /> <br /> == [[RemoteControl]] ==<br /> Human control of trike movements through Low Level using hardware connected to Low Level by a radio communication link (drive by radio). Includes on-board controls (drive by wire).<br /> <br /> == [[SensorsPage]] ==<br /> <br /> === [[SteeringSensor]] ===<br /> The front wheel angle detector.<br /> <br /> === [[Sonar]] === <br /> How the sonar subsystem connected to High Level works.<br /> <br /> === [[Lidar]] ===<br /> How the lidar subsystem connected to High Level works.<br /> <br /> === [[ Camera]] ===<br /> How the camera and vision subsystem connected to High Level works.<br /> <br /> == [[ActuatorPage]] ==<br /> <br /> == [[ Board Diagrams]] ==<br /> Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].<br /> <br /> == [[GitUsage | Using Git and GitHub]] ==<br /> Practices for maintaining code and source files on Elcano Project's Github.<br /> <br /> <br /> ==[[FilesPage | Files]] ==<br /> These are media files (pictures, videos, etc.) that are part of the project, but are not maintained under version control.<br /> <br /> == Elcano Project Main Website ==<br /> * [//www.elcanoproject.org]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Main_Page&diff=201 2019-07-10T14:51:04Z

<p>Tfolsom: /* SensorsPage */</p> <hr /> <div><br /> <br /> = Welcome to the Elcano Project Wiki =<br /> As the title says, WELCOME TO THE ELCANO PROJECT! Over the past few years many different teams have been working hard to create Cheap and Modular autonomy at the University of Washington Bothell. We are currently working on our first two prototypes which are now in the form of tricycles. With the use of affordable microcontrollers, such as the Arduino Mega 2560 and Raspberry PI, we are working towards creating Autonomy for anyone to rebuild anywhere, and that under $2000 and fully open-source. But we don't plan to stop there, no. That is just the first step in reaching our ultimate goal, which is making our systems applicable to any desired ground vehicles, such as cars and other vehicles. Autonomy is nothing new, in fact it has been around for over 40 years, the difference is that now we have the ability to make it available for anyone who desires furthering their knowledge or simply finding a safer way to work.<br /> <br /> To '''edit articles''' or '''upload files''', please create an account and request editing rights from a [//www.elcanoproject.org/wiki/index.php?title=Special:ListUsers&amp;group=bureaucrat member of the &quot;bureaucrat&quot; group].<br /> <br /> For editing help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.<br /> --------<br /> [[File:Catrikes.JPG|1000px]]<br /> == [[ElcanoIntro | Overview]] ==<br /> Basic concept of how the Elcano Project vehicle works.<br /> <br /> == [[System Architecture]] ==<br /> How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.<br /> <br /> == [[Power System]] ==<br /> How different modules connect to the batteries or power subsystem hardware.<br /> <br /> == [[Low Level]] ==<br /> How the Low Level system uses inputs to control actuators to steer, move, and stop the vehicle.<br /> <br /> == [[High Level]] ==<br /> How the High Level system uses stored maps and inputs from navigational sensors to formulate movement instructions sent to Low Level.<br /> <br /> == [[RemoteControl]] ==<br /> Human control of trike movements through Low Level using hardware connected to Low Level by a radio communication link (drive by radio). Includes on-board controls (drive by wire).<br /> <br /> == [[SensorsPage]] ==<br /> <br /> === [[Steering]] ===<br /> The front wheel angle detector.<br /> <br /> === [[Sonar]] === <br /> How the sonar subsystem connected to High Level works.<br /> <br /> === [[Lidar]] ===<br /> How the lidar subsystem connected to High Level works.<br /> <br /> === [[ Camera]] ===<br /> How the camera and vision subsystem connected to High Level works.<br /> <br /> == [[ActuatorPage]] ==<br /> <br /> == [[ Board Diagrams]] ==<br /> Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].<br /> <br /> == [[GitUsage | Using Git and GitHub]] ==<br /> Practices for maintaining code and source files on Elcano Project's Github.<br /> <br /> <br /> ==[[FilesPage | Files]] ==<br /> These are media files (pictures, videos, etc.) that are part of the project, but are not maintained under version control.<br /> <br /> == Elcano Project Main Website ==<br /> * [//www.elcanoproject.org]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Board_Diagrams&diff=190 2019-07-02T00:22:25Z

<p>Tfolsom: Added links to CAD files on GitHub.</p> <hr /> <div>= Board Schematics =<br /> <br /> == Low Level Board ==<br /> <br /> * Documentation &gt; [[LowLevelBoard]]<br /> <br /> * Photo &gt; [[Low Level]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics/Low%20Level%20v3 <br /> <br /> * Should be migrated to: https://github.com/elcano/LowLevel/Electronics<br /> <br /> <br /> [[File:LowLevelV3.1_A.png]]<br /> [[File:LowLevelV3.1_B.png]]<br /> [[File:LowLevelV3.1_C.png]]<br /> [[File:LowLevelV3.1_brd.png]]<br /> <br /> == High Level Board ==<br /> <br /> * Documentation &gt; [[HighLevelHWv3]]<br /> <br /> * Photo &gt; [[High Level]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics/High%20Level <br /> <br /> * Should be migrated to: https://github.com/elcano/HighLevel/Electronics<br /> <br /> <br /> [[File:High-Level PCB v3.0.png]]<br /> [[File:High-Level PCB v3.0_brd.png]]<br /> <br /> == Sonar Array Board ==<br /> <br /> * Documentation and photo &gt; [[Sonar]]<br /> <br /> * Eagle CAD files on https://github.com/elcano/Sonar/tree/master/Electronics <br /> <br /> [[File:SonarBoardV2.png]]<br /> <br /> [[File:SonarBoardV2_brd.png]]<br /> <br /> <br /> == Transceiver Board ==<br /> <br /> * Documentation &gt; [[RemoteControl]]<br /> <br /> * Eagle CAD files coming soon to: https://github.com/elcano/Transceiver <br /> <br /> == PowerOn Board ==<br /> <br /> <br /> * Documentation and photo &gt; [[Power System]]<br /> <br /> * Eagle CAD files: https://github.com/elcano/elcano/tree/master/Electronics <br /> <br /> <br /> <br /> [[File:PowerOn.png]]<br /> <br /> Cuts and jumpers to just use Kelly power-on circuit and DC-DC converters<br /> <br /> [[File:PowerOnOnly.png]]<br /> <br /> [[File:PowerOn_brd.png]]</div>

Tfolsom https://www.elcanoproject.org/wiki/index.php?title=Board_Diagrams&diff=189 2019-07-01T23:57:38Z

<p>Tfolsom: </p> <hr /> <div>= Board Schematics =<br /> <br /> == Low Level Board ==<br /> <br /> * Documentation &gt; [[LowLevelBoard]]<br /> <br /> * Photo &gt; [[Low Level]]<br /> <br /> [[File:LowLevelV3.1_A.png]]<br /> [[File:LowLevelV3.1_B.png]]<br /> [[File:LowLevelV3.1_C.png]]<br /> [[File:LowLevelV3.1_brd.png]]<br /> <br /> == High Level Board ==<br /> <br /> * Documentation &gt; [[HighLevelHWv3]]<br /> <br /> * Photo &gt; [[High Level]]<br /> <br /> [[File:High-Level PCB v3.0.png]]<br /> [[File:High-Level PCB v3.0_brd.png]]<br /> <br /> == Sonar Array Board ==<br /> <br /> * Documentation &gt; [[Sonar]]<br /> <br /> CAD files on https://github.com/elcano/Sonar/tree/master/Electronics <br /> <br /> [[File:SonarBoardV2.png]]<br /> <br /> [[File:SonarBoardV2_brd.png]]<br /> <br /> <br /> == Transceiver Board ==<br /> <br /> * Documentation &gt; [[RemoteControl]]<br /> <br /> == PowerOn Board ==<br /> <br /> <br /> * Documentation &gt; [[Power System]]<br /> <br /> [[File:PowerOn.png]]<br /> <br /> Cuts and jumpers to just use Kelly power-on circuit and DC-DC converters<br /> <br /> [[File:PowerOnOnly.png]]<br /> <br /> [[File:PowerOn_brd.png]]</div>

Tfolsom