Elcano Project Wiki - User contributions [en]

ElcanoIntro

2026-06-25T22:34:05Z

Elcanoadmin: /* Vehicles */

= Elcano Project Introduction =

== Vehicles ==

A self-driving vehicle does not have to be a car. It can be a bicycle or motorcycle. We work with tricycles so that we do not need to worry about balance. Other vehicles could be karts or toy cars. At University of Washington Bothell we have two Catrike recumbents and an Organic Transit ELF. In 2026, version 5 of the Rive by Wire System was built. It has the capability of outputting in [[ Communication |CAN Bus format]], which is the standard for automotive control. With a CAN Bus interface on Low Level a trike can present the same automation interface as a car.

[[File:ELF.JPG|1000px]]

Automation of the ELF vehicle has started with the steering system, which is described in the attached document.

== Theory ==

Self-driving vehicles like Elcano can increase passenger safety, reduce the energy used for urban transportation, and reduce vehicle congestion. Over 90% of traffic accidents are caused by driver error, so the safety potential of self-drive is well-understood. When self-drive almost eliminates traffic accidents, a motorcycle is almost as safe as a full-frame automobile. Vehicle weights could fall to the point that pod-cars weighing less than the riders are the preferred choice in urban environments. Since 65% of U.S. vehicle miles traveled (VMT) are urban, the ramifications are enormous. Self-driving vehicles can drive a pre-determined speed on a pre-determined route, eliminating unpredictable driver behavior that causes sudden traffic stoppage and congestion. An aerodynamic ultra-light vehicle that avoids stop-and-go traffic needs less than one-tenth the energy of an automobile; a 25 pound rechargeable battery and a small electric motor on a light vehicle achieves the speed and range required for urban transportation. Light batteries can be easily swapped when exhausted, eliminating range anxiety. A bank of batteries can be recharged when the wind blows and the sun shines. Fossil fuel demand, pollution and green house gas production could fall dramatically.

For most people, transportation automation is rocket science. The Elcano Project aims to make self-drive real for students and hobbyists, and build a popular demand to adopt traffic automation. The technology is here; laws and policies to take advantage of it are not.

An isolated autonomous car can improve safety, but the other benefits require choreographing road users; when done right, highway capacity goes up three times and congestion mostly disappears. If manual and automated traffic were allowed to mix, the manually driven cars would snarl up the automated lane; thus there needs to be separated lanes. A lane set apart for automated vehicles looks a lot like Personal Rapid Transit (PRT), a technology that has been around for more than 40 years. Today PRT systems are in operation; other automated road systems are only at the testing phase.

When an automated vehicle is in a reserved lane, the sensors get simpler and less expensive; there is no need for lidar, radar or extensive machine vision because lane traffic is synchronized and predictable. The Elcano Project provides a blueprint for building your own inexpensive experimental automated vehicle using electronics and sensors. A tricycle with an electric motor under 750 Watt and top speed under 20 mph is legally a bicycle, and thus street-legal without license, registration or insurance.

== Use of Arduino microcontrollers for Elcano ==
As you might be just taking your first dive into this project, it is important to know that most of our microcontrollers are manufactured by Arduino. Arduino is one of the largest producers of such development tools and have found great success in creating cheap ways to make them available to the public. Although generally affordable, these boards are mainly intended for prototyping and have rates of failure that may be too high for a production system. It still provides a great base for developers to create new systems.
For more information refer to https://www.arduino.cc/
--> the website also has a lot of information about their products from programming to forums so don't be afraid to look things up! Note that Arduino hardware is an open source design originally based on Atmel AVR. We have migrated the drive-by-wire board to the ARM-based Arduino Due. The High-level functions have migrated from Arduino to Jetson Nano with Pixhawk. Since our boards are also open source, you have the possibility of designing a single board that merges the Arduino and Elcano functionality.

== System Architecture Overview ==
Elcano converts an ordinary vehicle to self-drive by adding several classes of hardware, including:
* [[ProcessorGeneral | Processors]] that use data from the sensors and data from on-board storage to control where the vehicle goes.
* '''Actuators''' to control steering, braking, and vehicle speed. Actuators are often servomotors but can be other devices.
* '''Sensors''' to measure vehicle speed, vehicle location, vehicle direction, obstacle distance, and other information about the vehicle and its surroundings.
* '''Electrical Power''' comes from a bank of batteries, with power converters changing the voltage.
The processors, actuators, sensors, and power subsystem are all located on the vehicle.
Physical Architecture describes where each part is on the vehicle and the location of wires connecting each subsystem.

NEXT > [[System Architecture]]

ActuatorPage

2026-06-21T19:08:12Z

Elcanoadmin: /* Linear actuator with Motor Control Shield */

= Actuators and Motor =

==Description and Function ==
Elcano uses a linear 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 used an electric motor that drives a chain on the left side of the vehicle. The ELF used a rotary servo for steering.

== Drive System ==

The Catrikes have no pedaling or chain. The vehicle is powered by a hub motor.

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.

The electric motor is powered by an e-bike controller. The trikes use a Kelly controller. https://www.kellycontroller.com/shop/kbs-e/

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 drive-by-wire board that gives the throttle.

The Kelly e-bike controller has some additional functionality that has not yet been used:

-- 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.

-- It is possible to do regenerative braking.

-- The controller supports driving the wheel in reverse.

=== Connections ===

The main drive connector on DBW v5 is an RJ45 connector. On the Power box, the signals are attached to wires to the Kelly controller, which have unique colors and numbers. The only signal currently used is Throttle. The pins are

* 1: Forward / Reverse: White (12)
* 2: Current meter: Dark blue (8)
* 3: Amount of regenerative braking: White (2)
* 4: Regenerative brake switch: Brown (13)
* 5: Reserved
* 6: Throttle: Dark green (3)
* 7: Speedometer: Green from Hall B (17)
* 8: E-Bike alive: Purple (4) or Dark Grey (11)
* Kelly Pink wire (7) must be attached to 36V or system is off

== Steering System ==

Three methods have been used for steering: Linear servo, linear actuator with H-bridge, and linear actuator with motor control shield.

=== Linear servos ===

There are two main steering signals:

1. Signal Out is a 1 to 2 ms pulse sent from the Arduino to control the steering actuator.

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]].

The linear steering servo on the Catrikes https://www.servocity.com/hdls-6-2-12v has 25 lb. thrust with 6" throw. The servo is powered by a pulse signal (D48). A more suitable part may be https://www.servocity.com/motors-actuators/linear-actuators/heavy-duty-linear-actuators, which is described below.

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.

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 but has blown fuses. Be careful not to drive it beyond physical limits.

=== Linear actuator with H-bridge ===

The pulsed linear servo fails too often. When it fails it can still be used as a linear actuator, and it costs less to buy it as an actuator in the first place. The actuator is powered by a relay to give it either +12V or -12V and uses angle feedback to stop motion.

Students built an H-bridge circuit board to swap positive and negative voltages, but it never quite worked. We then discovered that the Arduino Motor Control shield can control the actuator when powered from its own 12V supply. This is the preferred design as of 2026.

The actuator depends on Signal In feedback. The H-bridge circuit used two digital signals to turn either left or right (D41, D48).

=== Linear actuator with Motor Control Shield ===

The Motor Shield has signals for motor on/off (D9), direction (D12) and speed (D3). It can also read the current that the motor is drawing (A0) and software can adjust speed to keep it within limits. CAUTION: the analog signal is 0-5V but the Arduino Due must not have any input > 3.3V. It is probably necessary to cut A0 and A1 and route them to a voltage converter. Interface to the shield is on https://docs.arduino.cc/tutorials/motor-shield-rev3/msr3-controlling-dc-motor/#hardware--software-needed Steering is Motor A. The motor to lift the gate to decouple would be Motor B.

The Vin line on Arduino cannot supply enough current for the steering motor. An external 12V supply needs to be connected to the motor shield through the screw terminal. The other screw terminals drive the motors: (+,-) for motor A and (+,-) for motor B. The motor is controlled by swapping 12V and Ground between the (+,-) terminals to make it go one direction or the other.

== Braking System ==
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.

=== Building a solenoid mount for braking ===
==== Creating and assembling a solenoid mount ====

# Select a solenoid according to required braking force and throw. Information like force as a function of throw is provided in product data sheets
## 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
## measure the distance the brake cable travels from rest to closed position; this is the required throw
## select a solenoid that provides adequate force over the entire throw
## be aware that a solenoid provides less force when heated by environment and electrical load
# 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
# 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
# Adhere the printed drilling template to the metal stock using rubber cement. Work quickly (< 30 seconds after application of rubber cement) to apply the paper template smoothly on the surface before the adhesive dries
# Drill holes where shown on the template. Drill pilot holes using a small bit before using large drill bits
# 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
# install the brake shield ends (threaded metal parts) to the brake shield end mount and thread the brake cable through
# 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)
# Check that the solenoid arm moves freely along its entire throw with the bridle and brake cable attached
# 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

==== Supplies ====
# existing bicycle braking system using barrel-ended brake cable (to use our brake cable bridle)
# 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)
# 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
# metal stock to create a bridle attaching the solenoid arm to the brake cable
# metal stock to create a stop for the bridle on the solenoid arm and a mount for the brake cable end
(have extra metal stock to recreate each drilled piece in case of mistakes)
# material such as screws, plates, or u-bolts to attach the solenoid mount to the vehicle
# screws and nuts to hold all solenoid mount parts together
# a printed drilling template, modified to fit your hardware if needed, one for each solenoid mount (neatly cut out individual pieces)
# rubber cement or other adhesive for adhering the drilling template
# hand drill or drill press
# clamps and disposable wood block(s) for drilling
# files or other abrasive for removing metal burs and sharp edges
# personal safety equipment such as gloves and eye protection for when cutting, drilling, and filing

=== Wiring the solenoid ===
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.
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 >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.

== Parts and Materials ==

# Two solenoids and assembly for braking. See '''"Creating and assembling a solenoid mount"''')
# 6" linear steering servo (Catrikes) or rotary servo (ELF)
# servo mounts
# linkage hardware to connect servos to brakes and steering
# electric bike conversion kit
# power subsystems (batteries, connectors, wiring) for servos and motor

Detailed bill of materials: https://github.com/elcano/elcano/blob/master/Documentation/Elcano_BOM.xls

== Links and Resources ==
See the attached solenoid data sheet for its specific characteristics.
Other linear servos: https://www.servocity.com/servos/heavy-duty-linear-servos

NEXT > [[Board Diagrams]]

ElcanoIntro

2026-06-20T00:11:46Z

Elcanoadmin: /* System Architecture Overview */

= Elcano Project Introduction =

== Vehicles ==

A self-driving vehicle does not have to be a car. It can be a bicycle or motorcycle. We work with tricycles so that we do not need to worry about balance. Other vehicles could be karts or toy cars. At University of Washington Bothell we have two Catrike recumbents and an Organic Transit ELF. In 2018, version 3 of the High Level System was built. It has the capability of outputting in [[ Communication |CAN Bus format]], which is the standard for automotive control. With a CAN Bus interface on Low Level a trike can present the same automation interface as a car.

[[File:ELF.JPG|1000px]]

Automation of the ELF vehicle has started with the steering system, which is described in the attached document.

== Theory ==

Self-driving vehicles like Elcano can increase passenger safety, reduce the energy used for urban transportation, and reduce vehicle congestion. Over 90% of traffic accidents are caused by driver error, so the safety potential of self-drive is well-understood. When self-drive almost eliminates traffic accidents, a motorcycle is almost as safe as a full-frame automobile. Vehicle weights could fall to the point that pod-cars weighing less than the riders are the preferred choice in urban environments. Since 65% of U.S. vehicle miles traveled (VMT) are urban, the ramifications are enormous. Self-driving vehicles can drive a pre-determined speed on a pre-determined route, eliminating unpredictable driver behavior that causes sudden traffic stoppage and congestion. An aerodynamic ultra-light vehicle that avoids stop-and-go traffic needs less than one-tenth the energy of an automobile; a 25 pound rechargeable battery and a small electric motor on a light vehicle achieves the speed and range required for urban transportation. Light batteries can be easily swapped when exhausted, eliminating range anxiety. A bank of batteries can be recharged when the wind blows and the sun shines. Fossil fuel demand, pollution and green house gas production could fall dramatically.

For most people, transportation automation is rocket science. The Elcano Project aims to make self-drive real for students and hobbyists, and build a popular demand to adopt traffic automation. The technology is here; laws and policies to take advantage of it are not.

An isolated autonomous car can improve safety, but the other benefits require choreographing road users; when done right, highway capacity goes up three times and congestion mostly disappears. If manual and automated traffic were allowed to mix, the manually driven cars would snarl up the automated lane; thus there needs to be separated lanes. A lane set apart for automated vehicles looks a lot like Personal Rapid Transit (PRT), a technology that has been around for more than 40 years. Today PRT systems are in operation; other automated road systems are only at the testing phase.

When an automated vehicle is in a reserved lane, the sensors get simpler and less expensive; there is no need for lidar, radar or extensive machine vision because lane traffic is synchronized and predictable. The Elcano Project provides a blueprint for building your own inexpensive experimental automated vehicle using electronics and sensors. A tricycle with an electric motor under 750 Watt and top speed under 20 mph is legally a bicycle, and thus street-legal without license, registration or insurance.

== Use of Arduino microcontrollers for Elcano ==
As you might be just taking your first dive into this project, it is important to know that most of our microcontrollers are manufactured by Arduino. Arduino is one of the largest producers of such development tools and have found great success in creating cheap ways to make them available to the public. Although generally affordable, these boards are mainly intended for prototyping and have rates of failure that may be too high for a production system. It still provides a great base for developers to create new systems.
For more information refer to https://www.arduino.cc/
--> the website also has a lot of information about their products from programming to forums so don't be afraid to look things up! Note that Arduino hardware is an open source design originally based on Atmel AVR. We have migrated the drive-by-wire board to the ARM-based Arduino Due. The High-level functions have migrated from Arduino to Jetson Nano with Pixhawk. Since our boards are also open source, you have the possibility of designing a single board that merges the Arduino and Elcano functionality.

== System Architecture Overview ==
Elcano converts an ordinary vehicle to self-drive by adding several classes of hardware, including:
* [[ProcessorGeneral | Processors]] that use data from the sensors and data from on-board storage to control where the vehicle goes.
* '''Actuators''' to control steering, braking, and vehicle speed. Actuators are often servomotors but can be other devices.
* '''Sensors''' to measure vehicle speed, vehicle location, vehicle direction, obstacle distance, and other information about the vehicle and its surroundings.
* '''Electrical Power''' comes from a bank of batteries, with power converters changing the voltage.
The processors, actuators, sensors, and power subsystem are all located on the vehicle.
Physical Architecture describes where each part is on the vehicle and the location of wires connecting each subsystem.

NEXT > [[System Architecture]]

Main Page

2026-06-20T00:08:59Z

Elcanoadmin: /* Elcano Project Main Website */

= Welcome to the Elcano Project Wiki =
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 two prototype recumbent tricycles and also worked on an ELF tricycle. With the use of affordable microcontrollers, such as the Arduino Due, Jetson Nano and Pixhawk, we are working towards creating Autonomy for anyone to build anywhere, with electronics and software 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 to further their knowledge or simply finding a safer way to work.

Elcano Project Main Website: [//www.elcanoproject.org]

Visit our github repositories: [https://github.com/elcano].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles GPS. It includes inertial sensors and a Kalman filter and thus improves on raw GPS. Various sensors can be purchased. Some use Global Network Satellite Systems (GNSS) from other countries to improve on the US Global Positioning System.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

Main Page

2026-06-20T00:01:37Z

Elcanoadmin: /* Welcome to the Elcano Project Wiki */

= Welcome to the Elcano Project Wiki =
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 two prototype recumbent tricycles and also worked on an ELF tricycle. With the use of affordable microcontrollers, such as the Arduino Due, Jetson Nano and Pixhawk, we are working towards creating Autonomy for anyone to build anywhere, with electronics and software 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 to further their knowledge or simply finding a safer way to work.

Elcano Project Main Website: [//www.elcanoproject.org]

Visit our github repositories: [https://github.com/elcano].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles GPS. It includes inertial sensors and a Kalman filter and thus improves on raw GPS. Various sensors can be purchased. Some use Global Network Satellite Systems (GNSS) from other countries to improve on the US Global Positioning System.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

Main Page

2026-06-19T23:57:56Z

Elcanoadmin: /* Welcome to the Elcano Project Wiki */

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Elcano Project Main Website: [//www.elcanoproject.org]

Visit our github repositories: [https://github.com/elcano].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles GPS. It includes inertial sensors and a Kalman filter and thus improves on raw GPS. Various sensors can be purchased. Some use Global Network Satellite Systems (GNSS) from other countries to improve on the US Global Positioning System.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

Main Page

2026-06-19T23:56:55Z

Elcanoadmin: /* Welcome to the Elcano Project Wiki */

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Elcano Project Main Website: [//www.elcanoproject.org]

Visit our github repositories [//https://github.com/elcano].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles GPS. It includes inertial sensors and a Kalman filter and thus improves on raw GPS. Various sensors can be purchased. Some use Global Network Satellite Systems (GNSS) from other countries to improve on the US Global Positioning System.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

Main Page

2026-06-19T23:54:52Z

Elcanoadmin: /* Welcome to the Elcano Project Wiki */

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Elcano Project Main Website: [//www.elcanoproject.org]

Visit our github repositories [//https://github.com/elcano here].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles GPS. It includes inertial sensors and a Kalman filter and thus improves on raw GPS. Various sensors can be purchased. Some use Global Network Satellite Systems (GNSS) from other countries to improve on the US Global Positioning System.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

Main Page

2026-06-19T23:53:13Z

Elcanoadmin:

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Visit our github repositories [//https://github.com/elcano here].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles GPS. It includes inertial sensors and a Kalman filter and thus improves on raw GPS. Various sensors can be purchased. Some use Global Network Satellite Systems (GNSS) from other countries to improve on the US Global Positioning System.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

Main Page

2026-06-19T23:52:08Z

Elcanoadmin:

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Visit our github repositories [//https://github.com/elcano here].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles GPS. It includes inertial sensors and a Kalman filter and thus improves on raw GPS. Various sensors can be purchased. Some use Global Network Satellite Systems (GNSS) from other countries to improve on the US Global Positioning System.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

Current Board Diagrams

2026-06-19T23:49:14Z

Elcanoadmin: /* Drive by Wire Board */

== Drive by Wire Board ==

[[FIle: DBWv5_Schematic1.png]]

[[FIle: DBWv5_Schematic2.png]]

[[FIle: DBWv5_Schematic3.png]]

== Simulator Board ==

* Documentation > [[Simulator]]

* Photo > [[Simulator]]

* Eagle CAD files: https://github.com/elcano/Simulator

[[File:CARLA_sch.jpg]]
[[File:CARLAbrd_1_1.jpg]]

Current Board Diagrams

2026-06-19T23:48:12Z

Elcanoadmin: /* Drive by Wire Board */

== Drive by Wire Board ==

[[FIle: DBWv5_Schematic1.png]]

== Simulator Board ==

* Documentation > [[Simulator]]

* Photo > [[Simulator]]

* Eagle CAD files: https://github.com/elcano/Simulator

[[File:CARLA_sch.jpg]]
[[File:CARLAbrd_1_1.jpg]]

File:DBWv5 Schematic3.png

2026-06-19T23:46:00Z

Elcanoadmin: DBW version 5 Schematic Sheet 3

== Summary ==
DBW version 5 Schematic Sheet 3

File:DBWv5 Schematic2.png

2026-06-19T23:45:10Z

Elcanoadmin: DBW version 5 Schematic Sheet 2

== Summary ==
DBW version 5 Schematic Sheet 2

File:DBWv5 Schematic1.png

2026-06-19T23:44:39Z

Elcanoadmin: DBW version 5 Schematic Sheet 1

== Summary ==
DBW version 5 Schematic Sheet 1

Current Board Diagrams

2026-06-19T23:27:19Z

Elcanoadmin: /* Simulator Board */

== Drive by Wire Board ==

== Simulator Board ==

* Documentation > [[Simulator]]

* Photo > [[Simulator]]

* Eagle CAD files: https://github.com/elcano/Simulator

[[File:CARLA_sch.jpg]]
[[File:CARLAbrd_1_1.jpg]]

Main Page

2026-06-19T19:59:18Z

Elcanoadmin: /* GPS */

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Visit our github repositories [//https://github.com/elcano here].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles GPS. It includes inertial sensors and a Kalman filter and thus improves on raw GPS. Various sensors can be purchased. Some use Global Network Satellite Systems (GNSS) from other countries to improve on the US Global Positioning System.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

Main Page

2026-06-19T19:56:06Z

Elcanoadmin: /* SensorsPage */

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Visit our github repositories [//https://github.com/elcano here].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles PPS.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

SteeringSensor

2026-06-19T19:52:56Z

Elcanoadmin: /* Sensor Connections */

= Steering Angle Sensor =

To change or maintain travel direction, the system must know which way the front wheels are pointing. Elcano tricycles accomplish this task with a rotational position sensor placed on the front steer wheels. Each trike has two steering columns, and both are instrumented for redundancy. The sensor is mechanically mounted to the shaft. Since the system uses Ackerman steering, the turn angle of the two wheels will be slightly different. More information is below.
Rotational position sensors may be incremental or absolute. An incremental position sensor only reports discrete changes in rotational position and possibly direction of rotation. Absolute position sensors report the current angle of the sensor shaft. Absolute position sensors have advantages for sensing wheel angle, such as always knowing the current wheel angle at the power-on state. Elcano test vehicles use absolute rotation sensors.

== Absolute wheel position: Analog ==

Analog position sensors typically communicate angle using current or voltage levels. In these devices, current or voltage is a function of the angle. Example:

[[File:wheel-turn-angle_360-degree-sensor.png | border | 640px]]

== Absolute wheel position: Digital ==

Digital position sensors communicate angle digitally. Two ways a sensor can accomplish this task is by encoding the measured position into a binary stream (serial communication) or by encoding the position in binary by driving several output pins high or low (parallel communication).

== Reducing Sensor Noise ==

The problem with sending an analog signal over a long wire to the Arduino is that the wire acts as an antenna and picks up noise. Thus we connect a twisted wire pair from sensor to Arduino that has Signal In as well as the return. The return wire is connected to the ground wire at the sensor. The return wire may have picked up noise when it gets to the Arduino. The Arduino subtracts the analog value of return from the Signal In. Since both wires have picked up approximately the same noise, subtracting them gives a more robust reading. The Signal In return signal goes to an analog input on the Arduino, and is not connected to Arduino ground. The test vehicle analog sensor uses four wires: power, ground, signal, and signal return.

Another alternative is to use an analog-to-digital converter to digitize the voltage reading from the sensor before it reaches [[C2]]. All analog signals are sensitive to noise from the environment, especially nearby electronics. This noise appears as voltage changes on the power and signal wires of the turn sensors and is visible with an oscilloscope. Because noise creates changes in voltage on the signal and power wires, it creates erroneous angle readings.

--Main.JosephBreithaupt - 2017-02-11

== Sensors used ==

We have gotten the best results from RTY060LVNAX 60 degree analog rotary encoder with a 5V range.
Other possibilities:

- TT Electronics 6127 sensor giving 5V analog output over 360 degrees https://www.digikey.com/products/en?keywords=987-1393-ND . Has six times less resolution than a 60 degree sensor, and the minimum resolution can get lost in the noise.

- EMS22A50-M25-LD6 Digital rotary encoder. This produces 1024 steps over 360 degrees, in SPI. It will give a resolution of 0.35 degrees. Requires a change to Arduino.

- TLC1549CP 10-bit analog-to-digital converter with serial control. This could be used to digitize the voltage from the RTY060LVNAX, reducing noise from analog transmission. DBW v5 can handle this with jumpers set for it.

- A CAN encoder such as https://www.amazon.com/Absolute-Encoder-Rotating-Magnetic-Diameter/dp/B0CN6GL4DD/ref=sr_1_3?sr=8-3

- AMS5043 Magnetic Angle Encoder. This requires that a cylindrical magnet be mounted precisely on the shaft. The sensor has an indent for the magnet, but the indent in not in the right place. Difficult to get robust readings from the part.

== Sensor Connections ==

The RJ45 Steering connection on DBW v5 carries both sensor input and actuator output. Depending on the jumpers, it can be configured as

Jumper A
* 1: Angle sensor on left steering column
* 2: Return on left column
* 3: Angle sensor on right steering column
* 4: Return on right column
Both signal and return are expected to pick up similar noise. Their difference is used to reduce noise.

Jumper B
* 1: MISO
* 2: CS
* 3: SCK
* 4: MOSI

There are three methods for steering: Pulse (linear servo), H-bridge, or Motor Shield. Other RJ45 pins are

* 5: Ground
* 6: Pulse for servo; R_turn for H-bridge
* 7: No connect or L_turn for H-bridge
* 8: 5V

The Motor Shield does not use this connector. A CAN sensor would not use the connector either, so the RJ45 cable could be eliminated.

== Mounting the Steering Angle Sensor ==

The steering sensor is mounted directly the top of the steering knuckle. In the top if the steering knuckle is threaded rod that is kept in place using a jam nut. On the end of that threaded rod is a coupling nut that has been locked in place using a jam nut. From the coupling nut an adapter has been 3d printed that connects the coupling nut to the Steering angle sensor. The steering angle sensor is help in place using a piece of flat metal bar with a 90 degree bend.

Mounting in this position is beneficial by reducing the amount of mechanical play that the system is exposed to and therefore reducing false readings.

== Ackermann Steering Geometry: wheel angle and turning radius ==

Many road vehicles use a variation of Ackermann Steering to allow a vehicle with more than two wheels to turn smoothly. The challenge of steering a multi-wheel vehicle in a circle is that all wheels are at different distances to the center of that circle, so they must turn to different angles and spin at different speeds. The trike used in the current Elcano system solves the speed differential problem by having only one drive wheel and un-driven steering wheels. The steering differential problem is solved using Ackermann steering geometry. With a basic understanding of Ackermann steering and right triangle geometry, we can predict variables like the turning radius of each wheel and the steering angle of the two front wheels. The inner turning wheel and outer turning wheel turn at different angles and have different turning radii. These calculations find both dimensions when given the inner turning radius (R1 in the image), wheelbase, and front wheel distance.

Ackermann steering geometry is based on two right triangles. Every calculation comes from right triangle trigonometry and the Pythagorean Theorem.

[[File:wheel-angles-small.png|center]]

'''Variables:'''

Bicycle Image:

R = bicycle turning radius

A = bicycle front wheel angle

A' = A

L = wheelbase

[[File:bicycle-form.png|center]]

Ackermann Image:

R1 = inner turning radius

R2 = outer turning radius

A1 = inner front wheel angle

A2 - outer front wheel angle

W = distance between front wheels

L = wheelbase

[[File:ackermann-form.png|center]]

TODO: determine if these equations accurately predict the inputs from the turn angle sensors while the trike is stationary or moving.

== Steering state Summer 2024 ==

Both prototype trikes are using the 60-degree angle sensors on the left wheel hub with the 360-degree angle sensor on the right wheel hub acting as a backup sensor. The current noise experienced from the left angle sensor is 10-15 analog read values or 48-73 mV recorded on the DBW v3 board and the resolution currently provided meets the current needs when steering with the RC controller. The steering angles are currently being returned through the steering board via an RJ-45 cable to the DBW board with each sensor having its own return line and power being provided locally from the steering board.

[[File:SteeringPerformance.png|600px|Solenoid Brakes]]

SteeringSensor

2026-06-19T19:51:42Z

Elcanoadmin: /* Sensor Connections */

= Steering Angle Sensor =

To change or maintain travel direction, the system must know which way the front wheels are pointing. Elcano tricycles accomplish this task with a rotational position sensor placed on the front steer wheels. Each trike has two steering columns, and both are instrumented for redundancy. The sensor is mechanically mounted to the shaft. Since the system uses Ackerman steering, the turn angle of the two wheels will be slightly different. More information is below.
Rotational position sensors may be incremental or absolute. An incremental position sensor only reports discrete changes in rotational position and possibly direction of rotation. Absolute position sensors report the current angle of the sensor shaft. Absolute position sensors have advantages for sensing wheel angle, such as always knowing the current wheel angle at the power-on state. Elcano test vehicles use absolute rotation sensors.

== Absolute wheel position: Analog ==

Analog position sensors typically communicate angle using current or voltage levels. In these devices, current or voltage is a function of the angle. Example:

[[File:wheel-turn-angle_360-degree-sensor.png | border | 640px]]

== Absolute wheel position: Digital ==

Digital position sensors communicate angle digitally. Two ways a sensor can accomplish this task is by encoding the measured position into a binary stream (serial communication) or by encoding the position in binary by driving several output pins high or low (parallel communication).

== Reducing Sensor Noise ==

The problem with sending an analog signal over a long wire to the Arduino is that the wire acts as an antenna and picks up noise. Thus we connect a twisted wire pair from sensor to Arduino that has Signal In as well as the return. The return wire is connected to the ground wire at the sensor. The return wire may have picked up noise when it gets to the Arduino. The Arduino subtracts the analog value of return from the Signal In. Since both wires have picked up approximately the same noise, subtracting them gives a more robust reading. The Signal In return signal goes to an analog input on the Arduino, and is not connected to Arduino ground. The test vehicle analog sensor uses four wires: power, ground, signal, and signal return.

Another alternative is to use an analog-to-digital converter to digitize the voltage reading from the sensor before it reaches [[C2]]. All analog signals are sensitive to noise from the environment, especially nearby electronics. This noise appears as voltage changes on the power and signal wires of the turn sensors and is visible with an oscilloscope. Because noise creates changes in voltage on the signal and power wires, it creates erroneous angle readings.

--Main.JosephBreithaupt - 2017-02-11

== Sensors used ==

We have gotten the best results from RTY060LVNAX 60 degree analog rotary encoder with a 5V range.
Other possibilities:

- TT Electronics 6127 sensor giving 5V analog output over 360 degrees https://www.digikey.com/products/en?keywords=987-1393-ND . Has six times less resolution than a 60 degree sensor, and the minimum resolution can get lost in the noise.

- EMS22A50-M25-LD6 Digital rotary encoder. This produces 1024 steps over 360 degrees, in SPI. It will give a resolution of 0.35 degrees. Requires a change to Arduino.

- TLC1549CP 10-bit analog-to-digital converter with serial control. This could be used to digitize the voltage from the RTY060LVNAX, reducing noise from analog transmission. DBW v5 can handle this with jumpers set for it.

- A CAN encoder such as https://www.amazon.com/Absolute-Encoder-Rotating-Magnetic-Diameter/dp/B0CN6GL4DD/ref=sr_1_3?sr=8-3

- AMS5043 Magnetic Angle Encoder. This requires that a cylindrical magnet be mounted precisely on the shaft. The sensor has an indent for the magnet, but the indent in not in the right place. Difficult to get robust readings from the part.

== Sensor Connections ==

The RJ45 Steering connection on DBW v5 carries both sensor input and actuator output. Depending on the jumpers, it can be configured as

Jumper A
* 1: Angle sensor on left steering column
* 2: Return on left column
* 3: Angle sensor on right steering column
* 4: Return on right column
Both signal and return are expected to pick up similar noise. Their difference is used to reduce noise

Jumper B
* 1: MISO
* 2: CS
* 3: SCK
* 4: MOSI

There are three methods for steering: Pulse for linear servo, H-bridge, or Motor Shield. Other RJ45 pins are

* 5: Ground
* 6: Pulse for servo; R_turn for H-bridge
* 7: No connect or L_turn for H-bridge
* 8: 5V

The Motor Shield does not use this connector. A CAN sensor would not use the connector either, so the RJ45 cable could be eliminated.

== Mounting the Steering Angle Sensor ==

The steering sensor is mounted directly the top of the steering knuckle. In the top if the steering knuckle is threaded rod that is kept in place using a jam nut. On the end of that threaded rod is a coupling nut that has been locked in place using a jam nut. From the coupling nut an adapter has been 3d printed that connects the coupling nut to the Steering angle sensor. The steering angle sensor is help in place using a piece of flat metal bar with a 90 degree bend.

Mounting in this position is beneficial by reducing the amount of mechanical play that the system is exposed to and therefore reducing false readings.

== Ackermann Steering Geometry: wheel angle and turning radius ==

Many road vehicles use a variation of Ackermann Steering to allow a vehicle with more than two wheels to turn smoothly. The challenge of steering a multi-wheel vehicle in a circle is that all wheels are at different distances to the center of that circle, so they must turn to different angles and spin at different speeds. The trike used in the current Elcano system solves the speed differential problem by having only one drive wheel and un-driven steering wheels. The steering differential problem is solved using Ackermann steering geometry. With a basic understanding of Ackermann steering and right triangle geometry, we can predict variables like the turning radius of each wheel and the steering angle of the two front wheels. The inner turning wheel and outer turning wheel turn at different angles and have different turning radii. These calculations find both dimensions when given the inner turning radius (R1 in the image), wheelbase, and front wheel distance.

Ackermann steering geometry is based on two right triangles. Every calculation comes from right triangle trigonometry and the Pythagorean Theorem.

[[File:wheel-angles-small.png|center]]

'''Variables:'''

Bicycle Image:

R = bicycle turning radius

A = bicycle front wheel angle

A' = A

L = wheelbase

[[File:bicycle-form.png|center]]

Ackermann Image:

R1 = inner turning radius

R2 = outer turning radius

A1 = inner front wheel angle

A2 - outer front wheel angle

W = distance between front wheels

L = wheelbase

[[File:ackermann-form.png|center]]

TODO: determine if these equations accurately predict the inputs from the turn angle sensors while the trike is stationary or moving.

== Steering state Summer 2024 ==

Both prototype trikes are using the 60-degree angle sensors on the left wheel hub with the 360-degree angle sensor on the right wheel hub acting as a backup sensor. The current noise experienced from the left angle sensor is 10-15 analog read values or 48-73 mV recorded on the DBW v3 board and the resolution currently provided meets the current needs when steering with the RC controller. The steering angles are currently being returned through the steering board via an RJ-45 cable to the DBW board with each sensor having its own return line and power being provided locally from the steering board.

[[File:SteeringPerformance.png|600px|Solenoid Brakes]]

SteeringSensor

2026-06-19T19:45:20Z

Elcanoadmin: /* Sensor Connections */

= Steering Angle Sensor =

To change or maintain travel direction, the system must know which way the front wheels are pointing. Elcano tricycles accomplish this task with a rotational position sensor placed on the front steer wheels. Each trike has two steering columns, and both are instrumented for redundancy. The sensor is mechanically mounted to the shaft. Since the system uses Ackerman steering, the turn angle of the two wheels will be slightly different. More information is below.
Rotational position sensors may be incremental or absolute. An incremental position sensor only reports discrete changes in rotational position and possibly direction of rotation. Absolute position sensors report the current angle of the sensor shaft. Absolute position sensors have advantages for sensing wheel angle, such as always knowing the current wheel angle at the power-on state. Elcano test vehicles use absolute rotation sensors.

== Absolute wheel position: Analog ==

Analog position sensors typically communicate angle using current or voltage levels. In these devices, current or voltage is a function of the angle. Example:

[[File:wheel-turn-angle_360-degree-sensor.png | border | 640px]]

== Absolute wheel position: Digital ==

Digital position sensors communicate angle digitally. Two ways a sensor can accomplish this task is by encoding the measured position into a binary stream (serial communication) or by encoding the position in binary by driving several output pins high or low (parallel communication).

== Reducing Sensor Noise ==

The problem with sending an analog signal over a long wire to the Arduino is that the wire acts as an antenna and picks up noise. Thus we connect a twisted wire pair from sensor to Arduino that has Signal In as well as the return. The return wire is connected to the ground wire at the sensor. The return wire may have picked up noise when it gets to the Arduino. The Arduino subtracts the analog value of return from the Signal In. Since both wires have picked up approximately the same noise, subtracting them gives a more robust reading. The Signal In return signal goes to an analog input on the Arduino, and is not connected to Arduino ground. The test vehicle analog sensor uses four wires: power, ground, signal, and signal return.

Another alternative is to use an analog-to-digital converter to digitize the voltage reading from the sensor before it reaches [[C2]]. All analog signals are sensitive to noise from the environment, especially nearby electronics. This noise appears as voltage changes on the power and signal wires of the turn sensors and is visible with an oscilloscope. Because noise creates changes in voltage on the signal and power wires, it creates erroneous angle readings.

--Main.JosephBreithaupt - 2017-02-11

== Sensors used ==

We have gotten the best results from RTY060LVNAX 60 degree analog rotary encoder with a 5V range.
Other possibilities:

- TT Electronics 6127 sensor giving 5V analog output over 360 degrees https://www.digikey.com/products/en?keywords=987-1393-ND . Has six times less resolution than a 60 degree sensor, and the minimum resolution can get lost in the noise.

- EMS22A50-M25-LD6 Digital rotary encoder. This produces 1024 steps over 360 degrees, in SPI. It will give a resolution of 0.35 degrees. Requires a change to Arduino.

- TLC1549CP 10-bit analog-to-digital converter with serial control. This could be used to digitize the voltage from the RTY060LVNAX, reducing noise from analog transmission. DBW v5 can handle this with jumpers set for it.

- A CAN encoder such as https://www.amazon.com/Absolute-Encoder-Rotating-Magnetic-Diameter/dp/B0CN6GL4DD/ref=sr_1_3?sr=8-3

- AMS5043 Magnetic Angle Encoder. This requires that a cylindrical magnet be mounted precisely on the shaft. The sensor has an indent for the magnet, but the indent in not in the right place. Difficult to get robust readings from the part.

== Sensor Connections ==

The RJ45 Steering connection on DBW v5 carries both sensor input and actuator output. Depending on the jumpers, it can be configured as

Jumper A
* 1: Angle sensor on left steering column
* 2: Return on left column
* 3: Angle sensor on right steering column
* 4: Return on right column
Both signal and return are expected to pick up similar noise. Their difference is used to reduce noise

Jumper B
* 1: MISO
* 2: CS
* 3: SCK
* 4: MOSI

== Mounting the Steering Angle Sensor ==

The steering sensor is mounted directly the top of the steering knuckle. In the top if the steering knuckle is threaded rod that is kept in place using a jam nut. On the end of that threaded rod is a coupling nut that has been locked in place using a jam nut. From the coupling nut an adapter has been 3d printed that connects the coupling nut to the Steering angle sensor. The steering angle sensor is help in place using a piece of flat metal bar with a 90 degree bend.

Mounting in this position is beneficial by reducing the amount of mechanical play that the system is exposed to and therefore reducing false readings.

== Ackermann Steering Geometry: wheel angle and turning radius ==

Many road vehicles use a variation of Ackermann Steering to allow a vehicle with more than two wheels to turn smoothly. The challenge of steering a multi-wheel vehicle in a circle is that all wheels are at different distances to the center of that circle, so they must turn to different angles and spin at different speeds. The trike used in the current Elcano system solves the speed differential problem by having only one drive wheel and un-driven steering wheels. The steering differential problem is solved using Ackermann steering geometry. With a basic understanding of Ackermann steering and right triangle geometry, we can predict variables like the turning radius of each wheel and the steering angle of the two front wheels. The inner turning wheel and outer turning wheel turn at different angles and have different turning radii. These calculations find both dimensions when given the inner turning radius (R1 in the image), wheelbase, and front wheel distance.

Ackermann steering geometry is based on two right triangles. Every calculation comes from right triangle trigonometry and the Pythagorean Theorem.

[[File:wheel-angles-small.png|center]]

'''Variables:'''

Bicycle Image:

R = bicycle turning radius

A = bicycle front wheel angle

A' = A

L = wheelbase

[[File:bicycle-form.png|center]]

Ackermann Image:

R1 = inner turning radius

R2 = outer turning radius

A1 = inner front wheel angle

A2 - outer front wheel angle

W = distance between front wheels

L = wheelbase

[[File:ackermann-form.png|center]]

TODO: determine if these equations accurately predict the inputs from the turn angle sensors while the trike is stationary or moving.

== Steering state Summer 2024 ==

Both prototype trikes are using the 60-degree angle sensors on the left wheel hub with the 360-degree angle sensor on the right wheel hub acting as a backup sensor. The current noise experienced from the left angle sensor is 10-15 analog read values or 48-73 mV recorded on the DBW v3 board and the resolution currently provided meets the current needs when steering with the RC controller. The steering angles are currently being returned through the steering board via an RJ-45 cable to the DBW board with each sensor having its own return line and power being provided locally from the steering board.

[[File:SteeringPerformance.png|600px|Solenoid Brakes]]

SteeringSensor

2026-06-19T19:37:36Z

Elcanoadmin:

= Steering Angle Sensor =

To change or maintain travel direction, the system must know which way the front wheels are pointing. Elcano tricycles accomplish this task with a rotational position sensor placed on the front steer wheels. Each trike has two steering columns, and both are instrumented for redundancy. The sensor is mechanically mounted to the shaft. Since the system uses Ackerman steering, the turn angle of the two wheels will be slightly different. More information is below.
Rotational position sensors may be incremental or absolute. An incremental position sensor only reports discrete changes in rotational position and possibly direction of rotation. Absolute position sensors report the current angle of the sensor shaft. Absolute position sensors have advantages for sensing wheel angle, such as always knowing the current wheel angle at the power-on state. Elcano test vehicles use absolute rotation sensors.

== Absolute wheel position: Analog ==

Analog position sensors typically communicate angle using current or voltage levels. In these devices, current or voltage is a function of the angle. Example:

[[File:wheel-turn-angle_360-degree-sensor.png | border | 640px]]

== Absolute wheel position: Digital ==

Digital position sensors communicate angle digitally. Two ways a sensor can accomplish this task is by encoding the measured position into a binary stream (serial communication) or by encoding the position in binary by driving several output pins high or low (parallel communication).

== Reducing Sensor Noise ==

The problem with sending an analog signal over a long wire to the Arduino is that the wire acts as an antenna and picks up noise. Thus we connect a twisted wire pair from sensor to Arduino that has Signal In as well as the return. The return wire is connected to the ground wire at the sensor. The return wire may have picked up noise when it gets to the Arduino. The Arduino subtracts the analog value of return from the Signal In. Since both wires have picked up approximately the same noise, subtracting them gives a more robust reading. The Signal In return signal goes to an analog input on the Arduino, and is not connected to Arduino ground. The test vehicle analog sensor uses four wires: power, ground, signal, and signal return.

Another alternative is to use an analog-to-digital converter to digitize the voltage reading from the sensor before it reaches [[C2]]. All analog signals are sensitive to noise from the environment, especially nearby electronics. This noise appears as voltage changes on the power and signal wires of the turn sensors and is visible with an oscilloscope. Because noise creates changes in voltage on the signal and power wires, it creates erroneous angle readings.

--Main.JosephBreithaupt - 2017-02-11

== Sensors used ==

We have gotten the best results from RTY060LVNAX 60 degree analog rotary encoder with a 5V range.
Other possibilities:

- TT Electronics 6127 sensor giving 5V analog output over 360 degrees https://www.digikey.com/products/en?keywords=987-1393-ND . Has six times less resolution than a 60 degree sensor, and the minimum resolution can get lost in the noise.

- EMS22A50-M25-LD6 Digital rotary encoder. This produces 1024 steps over 360 degrees, in SPI. It will give a resolution of 0.35 degrees. Requires a change to Arduino.

- TLC1549CP 10-bit analog-to-digital converter with serial control. This could be used to digitize the voltage from the RTY060LVNAX, reducing noise from analog transmission. DBW v5 can handle this with jumpers set for it.

- A CAN encoder such as https://www.amazon.com/Absolute-Encoder-Rotating-Magnetic-Diameter/dp/B0CN6GL4DD/ref=sr_1_3?sr=8-3

- AMS5043 Magnetic Angle Encoder. This requires that a cylindrical magnet be mounted precisely on the shaft. The sensor has an indent for the magnet, but the indent in not in the right place. Difficult to get robust readings from the part.

== Sensor Connections ==

The RJ45 Steering connection on DBW v5 carries both sensor input and actuator output.

== Mounting the Steering Angle Sensor ==

The steering sensor is mounted directly the top of the steering knuckle. In the top if the steering knuckle is threaded rod that is kept in place using a jam nut. On the end of that threaded rod is a coupling nut that has been locked in place using a jam nut. From the coupling nut an adapter has been 3d printed that connects the coupling nut to the Steering angle sensor. The steering angle sensor is help in place using a piece of flat metal bar with a 90 degree bend.

Mounting in this position is beneficial by reducing the amount of mechanical play that the system is exposed to and therefore reducing false readings.

== Ackermann Steering Geometry: wheel angle and turning radius ==

Many road vehicles use a variation of Ackermann Steering to allow a vehicle with more than two wheels to turn smoothly. The challenge of steering a multi-wheel vehicle in a circle is that all wheels are at different distances to the center of that circle, so they must turn to different angles and spin at different speeds. The trike used in the current Elcano system solves the speed differential problem by having only one drive wheel and un-driven steering wheels. The steering differential problem is solved using Ackermann steering geometry. With a basic understanding of Ackermann steering and right triangle geometry, we can predict variables like the turning radius of each wheel and the steering angle of the two front wheels. The inner turning wheel and outer turning wheel turn at different angles and have different turning radii. These calculations find both dimensions when given the inner turning radius (R1 in the image), wheelbase, and front wheel distance.

Ackermann steering geometry is based on two right triangles. Every calculation comes from right triangle trigonometry and the Pythagorean Theorem.

[[File:wheel-angles-small.png|center]]

'''Variables:'''

Bicycle Image:

R = bicycle turning radius

A = bicycle front wheel angle

A' = A

L = wheelbase

[[File:bicycle-form.png|center]]

Ackermann Image:

R1 = inner turning radius

R2 = outer turning radius

A1 = inner front wheel angle

A2 - outer front wheel angle

W = distance between front wheels

L = wheelbase

[[File:ackermann-form.png|center]]

TODO: determine if these equations accurately predict the inputs from the turn angle sensors while the trike is stationary or moving.

== Steering state Summer 2024 ==

Both prototype trikes are using the 60-degree angle sensors on the left wheel hub with the 360-degree angle sensor on the right wheel hub acting as a backup sensor. The current noise experienced from the left angle sensor is 10-15 analog read values or 48-73 mV recorded on the DBW v3 board and the resolution currently provided meets the current needs when steering with the RC controller. The steering angles are currently being returned through the steering board via an RJ-45 cable to the DBW board with each sensor having its own return line and power being provided locally from the steering board.

[[File:SteeringPerformance.png|600px|Solenoid Brakes]]

SteeringSensor

2026-06-19T19:34:40Z

Elcanoadmin: /* Sensors used */

= Steering Angle Sensor =

To change or maintain travel direction, the system must know which way the front wheels are pointing. Elcano tricycles accomplish this task with a rotational position sensor placed on the front steer wheels. Each trike has two steering columns, and both are instrumented for redundancy. The sensor is mechanically mounted to the shaft. Since the system uses Ackerman steering, the turn angle of the two wheels will be slightly different. More information is below.
Rotational position sensors may be incremental or absolute. An incremental position sensor only reports discrete changes in rotational position and possibly direction of rotation. Absolute position sensors report the current angle of the sensor shaft. Absolute position sensors have advantages for sensing wheel angle, such as always knowing the current wheel angle at the power-on state. Elcano test vehicles use absolute rotation sensors.

== Absolute wheel position: Analog ==

Analog position sensors typically communicate angle using current or voltage levels. In these devices, current or voltage is a function of the angle. Example:

[[File:wheel-turn-angle_360-degree-sensor.png | border | 640px]]

== Absolute wheel position: Digital ==

Digital position sensors communicate angle digitally. Two ways a sensor can accomplish this task is by encoding the measured position into a binary stream (serial communication) or by encoding the position in binary by driving several output pins high or low (parallel communication).

== Reducing Sensor Noise ==

The problem with sending an analog signal over a long wire to the Arduino is that the wire acts as an antenna and picks up noise. Thus we connect a twisted wire pair from sensor to Arduino that has Signal In as well as the return. The return wire is connected to the ground wire at the sensor. The return wire may have picked up noise when it gets to the Arduino. The Arduino subtracts the analog value of return from the Signal In. Since both wires have picked up approximately the same noise, subtracting them gives a more robust reading. The Signal In return signal goes to an analog input on the Arduino, and is not connected to Arduino ground. The test vehicle analog sensor uses four wires: power, ground, signal, and signal return.

Another alternative is to use an analog-to-digital converter to digitize the voltage reading from the sensor before it reaches [[C2]]. All analog signals are sensitive to noise from the environment, especially nearby electronics. This noise appears as voltage changes on the power and signal wires of the turn sensors and is visible with an oscilloscope. Because noise creates changes in voltage on the signal and power wires, it creates erroneous angle readings.

--Main.JosephBreithaupt - 2017-02-11

== Sensors used ==

We have gotten the best results from RTY060LVNAX 60 degree analog rotary encoder with a 5V range.
Other possibilities:

- TT Electronics 6127 sensor giving 5V analog output over 360 degrees https://www.digikey.com/products/en?keywords=987-1393-ND . Has six times less resolution than a 60 degree sensor, and the minimum resolution can get lost in the noise.

- EMS22A50-M25-LD6 Digital rotary encoder. This produces 1024 steps over 360 degrees, in SPI. It will give a resolution of 0.35 degrees. Requires a change to Arduino.

- TLC1549CP 10-bit analog-to-digital converter with serial control. This could be used to digitize the voltage from the RTY060LVNAX, reducing noise from analog transmission. DBW v5 can handle this with jumpers set for it.

- A CAN encoder such as https://www.amazon.com/Absolute-Encoder-Rotating-Magnetic-Diameter/dp/B0CN6GL4DD/ref=sr_1_3?sr=8-3

- AMS5043 Magnetic Angle Encoder. This requires that a cylindrical magnet be mounted precisely on the shaft. The sensor has an indent for the magnet, but the indent in not in the right place. Difficult to get robust readings from the part.

== Mounting the Steering Angle Sensor ==

The steering sensor is mounted directly the top of the steering knuckle. In the top if the steering knuckle is threaded rod that is kept in place using a jam nut. On the end of that threaded rod is a coupling nut that has been locked in place using a jam nut. From the coupling nut an adapter has been 3d printed that connects the coupling nut to the Steering angle sensor. The steering angle sensor is help in place using a piece of flat metal bar with a 90 degree bend.

Mounting in this position is beneficial by reducing the amount of mechanical play that the system is exposed to and therefore reducing false readings.

== Ackermann Steering Geometry: wheel angle and turning radius ==

Many road vehicles use a variation of Ackermann Steering to allow a vehicle with more than two wheels to turn smoothly. The challenge of steering a multi-wheel vehicle in a circle is that all wheels are at different distances to the center of that circle, so they must turn to different angles and spin at different speeds. The trike used in the current Elcano system solves the speed differential problem by having only one drive wheel and un-driven steering wheels. The steering differential problem is solved using Ackermann steering geometry. With a basic understanding of Ackermann steering and right triangle geometry, we can predict variables like the turning radius of each wheel and the steering angle of the two front wheels. The inner turning wheel and outer turning wheel turn at different angles and have different turning radii. These calculations find both dimensions when given the inner turning radius (R1 in the image), wheelbase, and front wheel distance.

Ackermann steering geometry is based on two right triangles. Every calculation comes from right triangle trigonometry and the Pythagorean Theorem.

[[File:wheel-angles-small.png|center]]

'''Variables:'''

Bicycle Image:

R = bicycle turning radius

A = bicycle front wheel angle

A' = A

L = wheelbase

[[File:bicycle-form.png|center]]

Ackermann Image:

R1 = inner turning radius

R2 = outer turning radius

A1 = inner front wheel angle

A2 - outer front wheel angle

W = distance between front wheels

L = wheelbase

[[File:ackermann-form.png|center]]

TODO: determine if these equations accurately predict the inputs from the turn angle sensors while the trike is stationary or moving.

== Steering state Summer 2024 ==

Both prototype trikes are using the 60-degree angle sensors on the left wheel hub with the 360-degree angle sensor on the right wheel hub acting as a backup sensor. The current noise experienced from the left angle sensor is 10-15 analog read values or 48-73 mV recorded on the DBW v3 board and the resolution currently provided meets the current needs when steering with the RC controller. The steering angles are currently being returned through the steering board via an RJ-45 cable to the DBW board with each sensor having its own return line and power being provided locally from the steering board.

[[File:SteeringPerformance.png|600px|Solenoid Brakes]]

Main Page

2026-06-19T19:25:12Z

Elcanoadmin: /* SensorsPage */

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Visit our github repositories [//https://github.com/elcano here].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

Main Page

2026-06-19T19:22:46Z

Elcanoadmin: /* SensorsPage */

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Visit our github repositories [//https://github.com/elcano here].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== [[Speedometer]] ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

Main Page

2026-06-19T19:18:23Z

Elcanoadmin: /* Camera */

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Visit our github repositories [//https://github.com/elcano here].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

Old Sensors

2026-06-19T19:17:22Z

Elcanoadmin:

= [[Sonar]] =
How the sonar subsystem connected to High-Level works.

[[File:SonarArray.JPG|1000px]]

This documentation is taken from Sonar2half.doc, in the Documentation folder in the GitHub repository.

== Sonar Board ==

The board contains up to 8 sonars, numbered as in the diagram. The board acts as a slave to the host over an SPI line. The board has two RJ45 connectors, one to the High-Level board and the other to a second sonar unit. The line to High-Level carries the MOSI/MISO/CLK/SS lines for SPI. The connector to a second sonar unit has a UART serial connection to coordinate timing, but this has never been implemented. If there is a single unit, sonar 6 is rear-facing.
If there is a second rear-facing unit, the second unit acts as a slave to the forward-facing unit. In the two-unit configuration, sonar position 6 is unpopulated. Position 12R is never used. The two boards have identical hardware, but will use different software. A better configuration would be to connect both the forward and rear facing units to the High-Level board.

Sonars are operated in three rounds, arranged so that there is no acoustic interference between them.

# Sonars at 12, 3, 4R, 7R, 9
# Sonars at 1, 3R, 6, 6R, 9R, 10
# Sonars at 2, 5R, 8R, 11

Board nomenclature is based on the forward position. When operated in the rear sonar positions are transformed as

12 → 6R

1 → 7R

2 → 8R

3 → 9R

6 → 12R

9 → 3R

10 → 4R

11 → 5R

Two or three pulse width signals on the board are wired together (by OR gates or diodes) and used to generate an interrupt when the pulse changes. The interrupt groups are:

IRQ1: 1, 2, 3 / 7R, 8R, 9R

IRQ2: 10, 11, 12 / 4R, 5R, 6R, 

IRQ3: 6, 9 / 12R, 3R

During each sonar round, only one sonar will produce an interrupt.

== Notes on 12/12/14: ==

The lines ADR_OK, ADR_0, ADR_1 and ADR_2 are not needed. They had been intended to select one of eight sonars. Instead, use lines RND_0 and RND_1, both attached to interrupts. These lines are sequenced according to a gray code (only one bit changes at a time):

(RND_0, RND_1) =

(0,1): Start a pulse on sonars at 12, 3 and 9 o'clock.

(1,1): Start a pulse on sonars at 1, 6 and 10 o'clock.

(1,0): Start a pulse on sonars at 2 and 11 o'clock.

(0,0): No action.

The resulting pulse is read on lines IRQ1, IRQ2 and IRQ3. On the forward pointing master, RND_0 and RND_1 are outputs. They are tied to the rear-facing slave, where they are inputs. On the slave, a change on any of lines RND_0 or RND_1 triggers an interrupt, which start the pulse on the appropriate sonars.

The hardware can read both pulse width range (IRQ_1 … 3) and analog range (SNR_1 … 12). It may be wise to use both, to make sure that they agree. No jumpers are needed. The analog values will change slowly, so interference with digital signals may not be significant.

On sonar:

Pin 1- Open or high

Pin 2 – To IRQ1, IRQ2 or IRQ3.

Pin 3 – To SNR_1, SNR_2, SNR_3, SNR_6, SNR_9, SNR_10, SNR_11 or SNR_12.

Pin 4 – Selected by RND_0 and RND_1.

Pin_5 – Serial data could go to D9, D10, D11 or D12, except that Arduino can only receive one software serial at a time. Probably not worth pursuing.

Pin 6 – Vcc

Pin 7 – Ground.

Timing

The default frequency for the SPI CLK is 4 MHz. The clock can be set to numbers between 8 MHz and 125 Khz.

-- Main.JohnsonB - 2017-06-27
* SonarBoard.png: 
<img src="%PUBURLPATH%/%WEB%/%TOPIC%/SonarBoard.png" alt="SonarBoard.png" width="969" height="1254" />

= Camera Sensor =

== Hardware ==

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.

== Functions ==

=== Visual Traffic Cone Ranging ===

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.

{|
|-
|*Camera Model*||*Focal length (mm)*||*Pixel dimensions (um)*
|-
|Pi Cam v1.x||3.5||1.4 x 1.4
|-
|Pi Cam v2.x||3.0||1.12 x 1.12
|}

''These are values provided in Pi Cam documentation. These are designed dimensions and may not be accurate from camera to camera.''

The vision processor is a Raspberry PI, and the camera is the Pi camera.
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,
3.6 mm / (N * 0.0014 mm) = range / 0.46 m.

range = 3.6 * 0.46 m / (N * 0.0014)

=== Visual Traffic Cone Angle ===

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.

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:

Degrees / pixel = (horizontal field of view) / (horizontal pixel count)

Example: 62.2 degrees / 3280 pixels = 0.0190 degrees per pixel, equivalent to 52.7 pixels per degree.

Now calculate the degrees per pixel using the focal length, pixel size, and data from the range calculations described in "Visual Traffic Cone Ranging":

Tan(degrees) = (Object height in meters) / (Object range in meters)

Degrees = Tanh( height / range)

Pixels = (focal length * height) / (pixel size * range)

Degrees / pixel = Degrees / pixel

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.

To find the horizontal degree offset of an object using its center point, first find the object's offset from center:

Horizontal offset in pixels= (object horizontal center in image) - (image width / 2)

Horizontal offset in degrees = (Horizontal Offset) * (degrees / pixel)

The horizontal offset in degrees will be positive when the object is right of center and negative when the object is left of center.

==== Experimentally finding focal length and pixel size ====

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.

The ratio of a Camera's focal length to its pixel size is part of the similar triangles formula:

focal_length / (N * pixel_size) = range / 0.46 m

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:

focal_length / pixel_size = N * range / 0.46 m

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.

=== Expected world coordinates ===

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

G {n Num} {p EPosMeters,NPosMeters} {b Deg}

and the current position of the trike as

S {p EPosMeters,NPosMeters} {b Deg}

The Pi returns the position of the cone as

G {n Num} {p EPosMeters,NPosMeters} {b Deg} {r Probability}

These formats are documented in GitHub under Documentation / SerialCmd.html.

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.)

-- Main.TylerCFolsom - 2017-06-16

ALSO > [[VisionPage]]

NEXT > [[ActuatorPage]]

= [[Lidar]] =

How the lidar subsystem connected to High-Level works.

The LiDAR sensor is able to detect the distance and angle of any object in its view. This data can be used by the high-level software to determine where an obstacle is located for the vehicle to avoid.

== Hardware ==

Scanse Sweep is a portable, rotating, horizontal-plane lidar unit. It has a maximum specified range of 40 meters and works best at ranges greater than 0.5 meter. '''Range data''' precision is 1 centimeter and range values are in centimeters. Angular resolution is user-configurable by adjusting sample rate and motor rotation frequency. Surface variables like reflectivity and environmental variables like strong illumination by sunlight limit measurement signal quality. '''Signal quality''' is a number between 0-255, with smaller numbers indicating poorer signal quality. '''Angle data''' precision is 0.0625 degrees and angle values are in degrees, expressed as a 16-bit fixed-point number with twelve integer bits and four fractional bits.

{| class="wikitable"
|-
! Angle bits
! Angle decimal (degrees)
|-
| ...0000'''0001'''
| 0.0625
|-
| ...0001'''0000'''
| 1.0
|-
| ...0001'''0001'''
| 1.0625
|}

The Scanse Sweep lidar unit is connected to an Arduino Micro to capture and process range, angle, and signal quality data during a scan.

== Software ==
Software on the Arduino Micro controls the Scanse Sweep. On startup, the '''setup()''' procedure resets the lidar, configures scan frequency and motor rotation frequency, waits for the motor to come up to speed, and configures the lidar to begin scanning. The '''loop()''' procedure requests the most recent complete scan reading, filters out invalid readings, and processes the signal for transmission to high level.

=== Filtering ===
Readings should be rejected if:
* '''Range''' is greater than 4000cm or equal to 1cm
* '''Angle''' is not within desired scan angles
* '''Signal quality''' is above an arbitrary value

Warning: the lidar is always scanning during operation unless the software signals it to stop (not implemented). The Scanse Sweep is a class 1 laser device and designed to be eye-safe, but placing the eye directly in the path of the beam or the scan plane should be avoided or prevented.

=== Signal processing ===

Signal processing is required to limit bytes sent to [[HighLevel]] but still allow HighLevel to reconstruct obstacle data from the scan. At maximum sampling frequency, the lidar unit collects 1000 range readings per second. Some of these reading are filtered out. This results in tens or hundreds of readings during each pass. To reduce data bandwidth, the software uses a "max delta" value to break the scan into segments beginning and ending at points with a change in range greater than the max delta. This discards small changes in range, but detects larger changes in range that indicate obstacles. This balances the need to detect both obstacles and continuous surfaces like walls. A single straight surface is broken into several segments centered on the closest point. If obstacles are placed on front of the surface, the change in range for each obstacle produces one or more segments for each obstacle and one or more segments for each section of straight surface. How accurately this process reconstructs the field of obstacles depends on how many points are filtered out before signal processing: if obstacle data is missing, it will not begin or end a segment.

== YDLIDAR ==

The YDLIDAR was worked on for the autonomous ATV capstone project summer of 2025 by Henry Haight. The lidar separates the data it detects and creates objects that can be used by the software. More information can be found on the GitHub page: https://github.com/elcano/Obstacles

==Scanse Sweep ==

The Scanse Sweep is a lidar sensor. Its head spins around multiple times per second, and collects information about its lateral surroundings. The spin speed and sampling rate can be changed.

It sends readings over a serial connection, each of which includes the angle, distance, signal strength, and other information.

Blasé Johnson worked on the sweep in the summer of 2017. The following is from his 6/22/17 report.

== Basic Sweep Obstacle Detection Algorithm ==
Goal

To use the readings from the sweep to determine if there is an obstacle present within a given distance in front of the trike, and to stop the trike if this is so.
Sweep Operation
Rotation and Speed
The Sweep rotates counterclockwise. Its rotational speed can be set to any integral value between 0 Hz and 10 Hz (number of full rotations per second).

=== Sampling Rate ===

The sweep obtains readings according to a given sample rate. Three distinct sample rates can be used for the Sweep:
500 – 600 Hz
750 – 800 Hz
1000 – 1075 Hz\

=== Sample Data ===

Each reading from the Sweep contains these data:

* A byte with sync/error bits, where the sync bit indicates whether the current reading is the first reading since the sensor last made a full rotation, one of the error bits indicates a communication error with the Lidar module, and the rest of the bits are reserved for future uses.

* The azimuth (degree of angle with starting position), transmitted as a 16-bit fixed point number, where the 12 MSBs are the integral part and the 4 LSBs are the fractional part.

* The distance from the nearest obstacle in centimeters, transmitted as a 16-bit integer.

* A value representing the signal strength, transmitted as an unsigned 8-bit integer, where 0 is the lowest strength, and 255 is the highest strength.

* A checksum, which is the remainder of the sum of the six previous bytes divided by 255.

=== Math ===

The trike will be expected to stop if an obstacle is detected within a certain distance from the front side of the vehicle, within the horizontal span of the trike. These distances are illustrated in Figure 1 as DISTANCE and WIDTH, respectively. 
The grey lines in Figure 1 show the distances that will be measured by the Sweep if it detects an obstacle at the line. The formula for this distance is DISTANCE/cos(AZIMUTH) .
The range of azimuths for the front side of the trike can be computed from the formula sarcsin(WIDTH/(2*DISTANCE))
and
360-arcsin(WIDTH/(2*DISTANCE))
for the right and left corners, respectively.

=== Process ===

Once the Sweep begins taking measurements, check the measurements whose azimuths lie within the boundaries of the front side of the trike. For each measurement within this range, determine if the distance from an obstacle in centimeters is equal to or less than DISTANCE/cos(AZIMUTH) . If so, stop the vehicle until a search of the measurements within the front boundary comes back negative, and a certain amount of time has passed since the last obstacle was detected.W

NEXT > [[Camera]]

=== External Links ===

[http://scanse.io/ Scanse]

-- Main.JohnsonB - 2017-11-07
* Figure 1: Distance from trike to detect obstacle & trike width: 
<img src="%PUBURLPATH%/%WEB%/%TOPIC%/ScanseTrike.png" alt="ScanseTrike.png" width="397" height="463" />

Main Page

2026-06-19T19:13:30Z

Elcanoadmin: /* Camera */

= Welcome to the Elcano Project Wiki =
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 Due Jetson Nano and Pixhawk, 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 to further their knowledge or simply finding a safer way to work.

Visit our github repositories [//https://github.com/elcano here].

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&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== [[ Camera]] ===
The camera and vision subsystem are controlled by Jetson Nano.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

ActuatorPage

2026-06-19T19:05:22Z

Elcanoadmin:

= Actuators and Motor =

==Description and Function ==
Elcano uses a linear 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 used an electric motor that drives a chain on the left side of the vehicle. The ELF used a rotary servo for steering.

== Drive System ==

The Catrikes have no pedaling or chain. The vehicle is powered by a hub motor.

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.

The electric motor is powered by an e-bike controller. The trikes use a Kelly controller. https://www.kellycontroller.com/shop/kbs-e/

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 drive-by-wire board that gives the throttle.

The Kelly e-bike controller has some additional functionality that has not yet been used:

-- 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.

-- It is possible to do regenerative braking.

-- The controller supports driving the wheel in reverse.

=== Connections ===

The main drive connector on DBW v5 is an RJ45 connector. On the Power box, the signals are attached to wires to the Kelly controller, which have unique colors and numbers. The only signal currently used is Throttle. The pins are

* 1: Forward / Reverse: White (12)
* 2: Current meter: Dark blue (8)
* 3: Amount of regenerative braking: White (2)
* 4: Regenerative brake switch: Brown (13)
* 5: Reserved
* 6: Throttle: Dark green (3)
* 7: Speedometer: Green from Hall B (17)
* 8: E-Bike alive: Purple (4) or Dark Grey (11)
* Kelly Pink wire (7) must be attached to 36V or system is off

== Steering System ==

Three methods have been used for steering: Linear servo, linear actuator with H-bridge, and linear actuator with motor control shield.

=== Linear servos ===

There are two main steering signals:

1. Signal Out is a 1 to 2 ms pulse sent from the Arduino to control the steering actuator.

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]].

The linear steering servo on the Catrikes https://www.servocity.com/hdls-6-2-12v has 25 lb. thrust with 6" throw. The servo is powered by a pulse signal (D48). A more suitable part may be https://www.servocity.com/motors-actuators/linear-actuators/heavy-duty-linear-actuators, which is described below.

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.

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 but has blown fuses. Be careful not to drive it beyond physical limits.

=== Linear actuator with H-bridge ===

The pulsed linear servo fails too often. When it fails it can still be used as a linear actuator, and it costs less to buy it as an actuator in the first place. The actuator is powered by a relay to give it either +12V or -12V and uses angle feedback to stop motion.

Students built an H-bridge circuit board to swap positive and negative voltages, but it never quite worked. We then discovered that the Arduino Motor Control shield can control the actuator when powered from its own 12V supply. This is the preferred design as of 2026.

The actuator depends on Signal In feedback. The H-bridge circuit used two digital signals to turn either left or right (D41, D48).

=== Linear actuator with Motor Control Shield ===

The Motor Shield has signals for motor on/off (D9), direction (D12) and speed (D3). It can also read the current that the motor is drawing (A0) and software can adjust speed to keep it within limits. CAUTION: the analog signal is 0-5V but the Arduino Due must not have any input > 3.3V. It is probably necessary to cut A0 and A1 and route them to a voltage converter. Interface to the shield is on https://docs.arduino.cc/tutorials/motor-shield-rev3/msr3-controlling-dc-motor/#hardware--software-needed Steering is Motor A. The motor to lift the gate to decouple would be Motor B.

The Vin line on Arduino cannot supply enough current for the steering motor. An external 12V supply needs to be connected to the motor shield.

== Braking System ==
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.

=== Building a solenoid mount for braking ===
==== Creating and assembling a solenoid mount ====

# Select a solenoid according to required braking force and throw. Information like force as a function of throw is provided in product data sheets
## 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
## measure the distance the brake cable travels from rest to closed position; this is the required throw
## select a solenoid that provides adequate force over the entire throw
## be aware that a solenoid provides less force when heated by environment and electrical load
# 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
# 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
# Adhere the printed drilling template to the metal stock using rubber cement. Work quickly (< 30 seconds after application of rubber cement) to apply the paper template smoothly on the surface before the adhesive dries
# Drill holes where shown on the template. Drill pilot holes using a small bit before using large drill bits
# 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
# install the brake shield ends (threaded metal parts) to the brake shield end mount and thread the brake cable through
# 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)
# Check that the solenoid arm moves freely along its entire throw with the bridle and brake cable attached
# 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

==== Supplies ====
# existing bicycle braking system using barrel-ended brake cable (to use our brake cable bridle)
# 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)
# 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
# metal stock to create a bridle attaching the solenoid arm to the brake cable
# metal stock to create a stop for the bridle on the solenoid arm and a mount for the brake cable end
(have extra metal stock to recreate each drilled piece in case of mistakes)
# material such as screws, plates, or u-bolts to attach the solenoid mount to the vehicle
# screws and nuts to hold all solenoid mount parts together
# a printed drilling template, modified to fit your hardware if needed, one for each solenoid mount (neatly cut out individual pieces)
# rubber cement or other adhesive for adhering the drilling template
# hand drill or drill press
# clamps and disposable wood block(s) for drilling
# files or other abrasive for removing metal burs and sharp edges
# personal safety equipment such as gloves and eye protection for when cutting, drilling, and filing

=== Wiring the solenoid ===
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.
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 >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.

== Parts and Materials ==

# Two solenoids and assembly for braking. See '''"Creating and assembling a solenoid mount"''')
# 6" linear steering servo (Catrikes) or rotary servo (ELF)
# servo mounts
# linkage hardware to connect servos to brakes and steering
# electric bike conversion kit
# power subsystems (batteries, connectors, wiring) for servos and motor

Detailed bill of materials: https://github.com/elcano/elcano/blob/master/Documentation/Elcano_BOM.xls

== Links and Resources ==
See the attached solenoid data sheet for its specific characteristics.
Other linear servos: https://www.servocity.com/servos/heavy-duty-linear-servos

NEXT > [[Board Diagrams]]

ActuatorPage

2026-06-19T19:04:34Z

Elcanoadmin:

= Actuators and Motor =

==Description and Function ==
Elcano uses a linear 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 used an electric motor that drives a chain on the left side of the vehicle. The ELF used a rotary servo for steering.

== Drive System ==

The Catrikes have no pedaling or chain. The vehicle is powered by a hub motor.

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.

The electric motor is powered by an e-bike controller. The trikes use a Kelly controller. https://www.kellycontroller.com/shop/kbs-e/

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 drive-by-wire board that gives the throttle.

The Kelly e-bike controller has some additional functionality that has not yet been used:

-- 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.

-- It is possible to do regenerative braking.

-- The controller supports driving the wheel in reverse.

== Connections ==

The main drive connector on DBW v5 is an RJ45 connector. On the Power box, the signals are attached to wires to the Kelly controller, which have unique colors and numbers. The only signal currently used is Throttle. The pins are

* 1: Forward / Reverse: White (12)
* 2: Current meter: Dark blue (8)
* 3: Amount of regenerative braking: White (2)
* 4: Regenerative brake switch: Brown (13)
* 5: Reserved
* 6: Throttle: Dark green (3)
* 7: Speedometer: Green from Hall B (17)
* 8: E-Bike alive: Purple (4) or Dark Grey (11)
* Kelly Pink wire (7) must be attached to 36V or system is off

== Steering System ==

Three methods have been used for steering: Linear servo, linear actuator with H-bridge, and linear actuator with motor control shield.

=== Linear servos ===

There are two main steering signals:

1. Signal Out is a 1 to 2 ms pulse sent from the Arduino to control the steering actuator.

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]].

The linear steering servo on the Catrikes https://www.servocity.com/hdls-6-2-12v has 25 lb. thrust with 6" throw. The servo is powered by a pulse signal (D48). A more suitable part may be https://www.servocity.com/motors-actuators/linear-actuators/heavy-duty-linear-actuators, which is described below.

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.

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 but has blown fuses. Be careful not to drive it beyond physical limits.

=== Linear actuator with H-bridge ===

The pulsed linear servo fails too often. When it fails it can still be used as a linear actuator, and it costs less to buy it as an actuator in the first place. The actuator is powered by a relay to give it either +12V or -12V and uses angle feedback to stop motion.

Students built an H-bridge circuit board to swap positive and negative voltages, but it never quite worked. We then discovered that the Arduino Motor Control shield can control the actuator when powered from its own 12V supply. This is the preferred design as of 2026.

The actuator depends on Signal In feedback. The H-bridge circuit used two digital signals to turn either left or right (D41, D48).

=== Linear actuator with Motor Control Shield ===

The Motor Shield has signals for motor on/off (D9), direction (D12) and speed (D3). It can also read the current that the motor is drawing (A0) and software can adjust speed to keep it within limits. CAUTION: the analog signal is 0-5V but the Arduino Due must not have any input > 3.3V. It is probably necessary to cut A0 and A1 and route them to a voltage converter. Interface to the shield is on https://docs.arduino.cc/tutorials/motor-shield-rev3/msr3-controlling-dc-motor/#hardware--software-needed Steering is Motor A. The motor to lift the gate to decouple would be Motor B.

The Vin line on Arduino cannot supply enough current for the steering motor. An external 12V supply needs to be connected to the motor shield.

== Braking System ==
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.

=== Building a solenoid mount for braking ===
==== Creating and assembling a solenoid mount ====

# Select a solenoid according to required braking force and throw. Information like force as a function of throw is provided in product data sheets
## 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
## measure the distance the brake cable travels from rest to closed position; this is the required throw
## select a solenoid that provides adequate force over the entire throw
## be aware that a solenoid provides less force when heated by environment and electrical load
# 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
# 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
# Adhere the printed drilling template to the metal stock using rubber cement. Work quickly (< 30 seconds after application of rubber cement) to apply the paper template smoothly on the surface before the adhesive dries
# Drill holes where shown on the template. Drill pilot holes using a small bit before using large drill bits
# 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
# install the brake shield ends (threaded metal parts) to the brake shield end mount and thread the brake cable through
# 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)
# Check that the solenoid arm moves freely along its entire throw with the bridle and brake cable attached
# 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

==== Supplies ====
# existing bicycle braking system using barrel-ended brake cable (to use our brake cable bridle)
# 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)
# 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
# metal stock to create a bridle attaching the solenoid arm to the brake cable
# metal stock to create a stop for the bridle on the solenoid arm and a mount for the brake cable end
(have extra metal stock to recreate each drilled piece in case of mistakes)
# material such as screws, plates, or u-bolts to attach the solenoid mount to the vehicle
# screws and nuts to hold all solenoid mount parts together
# a printed drilling template, modified to fit your hardware if needed, one for each solenoid mount (neatly cut out individual pieces)
# rubber cement or other adhesive for adhering the drilling template
# hand drill or drill press
# clamps and disposable wood block(s) for drilling
# files or other abrasive for removing metal burs and sharp edges
# personal safety equipment such as gloves and eye protection for when cutting, drilling, and filing

=== Wiring the solenoid ===
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.
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 >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.

== Parts and Materials ==

# Two solenoids and assembly for braking. See '''"Creating and assembling a solenoid mount"''')
# 6" linear steering servo (Catrikes) or rotary servo (ELF)
# servo mounts
# linkage hardware to connect servos to brakes and steering
# electric bike conversion kit
# power subsystems (batteries, connectors, wiring) for servos and motor

Detailed bill of materials: https://github.com/elcano/elcano/blob/master/Documentation/Elcano_BOM.xls

== Links and Resources ==
See the attached solenoid data sheet for its specific characteristics.
Other linear servos: https://www.servocity.com/servos/heavy-duty-linear-servos

NEXT > [[Board Diagrams]]

ActuatorPage

2026-06-19T19:02:49Z

Elcanoadmin: /* Connections */

= Actuators and Motor =

==Description and Function ==
Elcano uses a linear 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 used an electric motor that drives a chain on the left side of the vehicle. The ELF used a rotary servo for steering.

== Parts and Materials ==

# Two solenoids and assembly for braking. See '''"Creating and assembling a solenoid mount"''')
# 6" linear steering servo (Catrikes) or rotary servo (ELF)
# servo mounts
# linkage hardware to connect servos to brakes and steering
# electric bike conversion kit
# power subsystems (batteries, connectors, wiring) for servos and motor

Detailed bill of materials: https://github.com/elcano/elcano/blob/master/Documentation/Elcano_BOM.xls

== Drive System ==

The Catrikes have no pedaling or chain. The vehicle is powered by a hub motor.

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.

The electric motor is powered by an e-bike controller. The trikes use a Kelly controller. https://www.kellycontroller.com/shop/kbs-e/

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 drive-by-wire board that gives the throttle.

The Kelly e-bike controller has some additional functionality that has not yet been used:

-- 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.

-- It is possible to do regenerative braking.

-- The controller supports driving the wheel in reverse.

== Connections ==

The main drive connector on DBW v5 is an RJ45 connector. On the Power box, the signals are attached to wires to the Kelly controller, which have unique colors and numbers. The only signal currently used is Throttle. The pins are

* 1: Forward / Reverse: White (12)
* 2: Current meter: Dark blue (8)
* 3: Amount of regenerative braking: White (2)
* 4: Regenerative brake switch: Brown (13)
* 5: Reserved
* 6: Throttle: Dark green (3)
* 7: Speedometer: Green from Hall B (17)
* 8: E-Bike alive: Purple (4) or Dark Grey (11)
* Kelly Pink wire (7) must be attached to 36V or system is off

== Steering System ==

Three methods have been used for steering: Linear servo, linear actuator with H-bridge, and linear actuator with motor control shield.

=== Linear servos ===

There are two main steering signals:

1. Signal Out is a 1 to 2 ms pulse sent from the Arduino to control the steering actuator.

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]].

The linear steering servo on the Catrikes https://www.servocity.com/hdls-6-2-12v has 25 lb. thrust with 6" throw. The servo is powered by a pulse signal (D48). A more suitable part may be https://www.servocity.com/motors-actuators/linear-actuators/heavy-duty-linear-actuators, which is described below.

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.

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 but has blown fuses. Be careful not to drive it beyond physical limits.

=== Linear actuator with H-bridge ===

The pulsed linear servo fails too often. When it fails it can still be used as a linear actuator, and it costs less to buy it as an actuator in the first place. The actuator is powered by a relay to give it either +12V or -12V and uses angle feedback to stop motion.

Students built an H-bridge circuit board to swap positive and negative voltages, but it never quite worked. We then discovered that the Arduino Motor Control shield can control the actuator when powered from its own 12V supply. This is the preferred design as of 2026.

The actuator depends on Signal In feedback. The H-bridge circuit used two digital signals to turn either left or right (D41, D48).

=== Linear actuator with Motor Control Shield ===

The Motor Shield has signals for motor on/off (D9), direction (D12) and speed (D3). It can also read the current that the motor is drawing (A0) and software can adjust speed to keep it within limits. CAUTION: the analog signal is 0-5V but the Arduino Due must not have any input > 3.3V. It is probably necessary to cut A0 and A1 and route them to a voltage converter. Interface to the shield is on https://docs.arduino.cc/tutorials/motor-shield-rev3/msr3-controlling-dc-motor/#hardware--software-needed Steering is Motor A. The motor to lift the gate to decouple would be Motor B.

The Vin line on Arduino cannot supply enough current for the steering motor. An external 12V supply needs to be connected to the motor shield.

== Braking System ==
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.

=== Building a solenoid mount for braking ===
==== Creating and assembling a solenoid mount ====

# Select a solenoid according to required braking force and throw. Information like force as a function of throw is provided in product data sheets
## 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
## measure the distance the brake cable travels from rest to closed position; this is the required throw
## select a solenoid that provides adequate force over the entire throw
## be aware that a solenoid provides less force when heated by environment and electrical load
# 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
# 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
# Adhere the printed drilling template to the metal stock using rubber cement. Work quickly (< 30 seconds after application of rubber cement) to apply the paper template smoothly on the surface before the adhesive dries
# Drill holes where shown on the template. Drill pilot holes using a small bit before using large drill bits
# 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
# install the brake shield ends (threaded metal parts) to the brake shield end mount and thread the brake cable through
# 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)
# Check that the solenoid arm moves freely along its entire throw with the bridle and brake cable attached
# 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

==== Supplies ====
# existing bicycle braking system using barrel-ended brake cable (to use our brake cable bridle)
# 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)
# 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
# metal stock to create a bridle attaching the solenoid arm to the brake cable
# metal stock to create a stop for the bridle on the solenoid arm and a mount for the brake cable end
(have extra metal stock to recreate each drilled piece in case of mistakes)
# material such as screws, plates, or u-bolts to attach the solenoid mount to the vehicle
# screws and nuts to hold all solenoid mount parts together
# a printed drilling template, modified to fit your hardware if needed, one for each solenoid mount (neatly cut out individual pieces)
# rubber cement or other adhesive for adhering the drilling template
# hand drill or drill press
# clamps and disposable wood block(s) for drilling
# files or other abrasive for removing metal burs and sharp edges
# personal safety equipment such as gloves and eye protection for when cutting, drilling, and filing

=== Wiring the solenoid ===
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.
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 >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.

== Links and Resources ==
See the attached solenoid data sheet for its specific characteristics.
Other linear servos: https://www.servocity.com/servos/heavy-duty-linear-servos

NEXT > [[Board Diagrams]]

ActuatorPage

2026-06-19T19:01:56Z

Elcanoadmin: /* Drive System */

= Actuators and Motor =

==Description and Function ==
Elcano uses a linear 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 used an electric motor that drives a chain on the left side of the vehicle. The ELF used a rotary servo for steering.

== Parts and Materials ==

# Two solenoids and assembly for braking. See '''"Creating and assembling a solenoid mount"''')
# 6" linear steering servo (Catrikes) or rotary servo (ELF)
# servo mounts
# linkage hardware to connect servos to brakes and steering
# electric bike conversion kit
# power subsystems (batteries, connectors, wiring) for servos and motor

Detailed bill of materials: https://github.com/elcano/elcano/blob/master/Documentation/Elcano_BOM.xls

== Drive System ==

The Catrikes have no pedaling or chain. The vehicle is powered by a hub motor.

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.

The electric motor is powered by an e-bike controller. The trikes use a Kelly controller. https://www.kellycontroller.com/shop/kbs-e/

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 drive-by-wire board that gives the throttle.

The Kelly e-bike controller has some additional functionality that has not yet been used:

-- 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.

-- It is possible to do regenerative braking.

-- The controller supports driving the wheel in reverse.

== Connections ==

The main drive connector on DBW v5 is an RJ45 connector. On the Power box, the signals are attached to wires to the Kelly controller, which have unique colors and numbers. The only signal currently used is Throttle. The pins are

* 1: Forward / Reverse: White (12)
* 2: Current meter: Dark blue (8)
* 3: Amount of regenerative braking: White (2)
* 4: Regenerative brake switch: Brown (13)
* 5: Reserved
* 6: Throttle: Dark green (3)
* 7: Speedometer: Green from Hall B (17)
* 8: E-Bike alive: Purple (4) or Dark Grey (11)
* Kelly Pink wire (7) must be attached to 36V or system is off

== Steering System ==

Three methods have been used for steering: Linear servo, linear actuator with H-bridge, and linear actuator with motor control shield.

=== Linear servos ===

There are two main steering signals:

1. Signal Out is a 1 to 2 ms pulse sent from the Arduino to control the steering actuator.

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]].

The linear steering servo on the Catrikes https://www.servocity.com/hdls-6-2-12v has 25 lb. thrust with 6" throw. The servo is powered by a pulse signal (D48). A more suitable part may be https://www.servocity.com/motors-actuators/linear-actuators/heavy-duty-linear-actuators, which is described below.

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.

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 but has blown fuses. Be careful not to drive it beyond physical limits.

=== Linear actuator with H-bridge ===

The pulsed linear servo fails too often. When it fails it can still be used as a linear actuator, and it costs less to buy it as an actuator in the first place. The actuator is powered by a relay to give it either +12V or -12V and uses angle feedback to stop motion.

Students built an H-bridge circuit board to swap positive and negative voltages, but it never quite worked. We then discovered that the Arduino Motor Control shield can control the actuator when powered from its own 12V supply. This is the preferred design as of 2026.

The actuator depends on Signal In feedback. The H-bridge circuit used two digital signals to turn either left or right (D41, D48).

=== Linear actuator with Motor Control Shield ===

The Motor Shield has signals for motor on/off (D9), direction (D12) and speed (D3). It can also read the current that the motor is drawing (A0) and software can adjust speed to keep it within limits. CAUTION: the analog signal is 0-5V but the Arduino Due must not have any input > 3.3V. It is probably necessary to cut A0 and A1 and route them to a voltage converter. Interface to the shield is on https://docs.arduino.cc/tutorials/motor-shield-rev3/msr3-controlling-dc-motor/#hardware--software-needed Steering is Motor A. The motor to lift the gate to decouple would be Motor B.

The Vin line on Arduino cannot supply enough current for the steering motor. An external 12V supply needs to be connected to the motor shield.

== Braking System ==
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.

=== Building a solenoid mount for braking ===
==== Creating and assembling a solenoid mount ====

# Select a solenoid according to required braking force and throw. Information like force as a function of throw is provided in product data sheets
## 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
## measure the distance the brake cable travels from rest to closed position; this is the required throw
## select a solenoid that provides adequate force over the entire throw
## be aware that a solenoid provides less force when heated by environment and electrical load
# 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
# 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
# Adhere the printed drilling template to the metal stock using rubber cement. Work quickly (< 30 seconds after application of rubber cement) to apply the paper template smoothly on the surface before the adhesive dries
# Drill holes where shown on the template. Drill pilot holes using a small bit before using large drill bits
# 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
# install the brake shield ends (threaded metal parts) to the brake shield end mount and thread the brake cable through
# 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)
# Check that the solenoid arm moves freely along its entire throw with the bridle and brake cable attached
# 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

==== Supplies ====
# existing bicycle braking system using barrel-ended brake cable (to use our brake cable bridle)
# 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)
# 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
# metal stock to create a bridle attaching the solenoid arm to the brake cable
# metal stock to create a stop for the bridle on the solenoid arm and a mount for the brake cable end
(have extra metal stock to recreate each drilled piece in case of mistakes)
# material such as screws, plates, or u-bolts to attach the solenoid mount to the vehicle
# screws and nuts to hold all solenoid mount parts together
# a printed drilling template, modified to fit your hardware if needed, one for each solenoid mount (neatly cut out individual pieces)
# rubber cement or other adhesive for adhering the drilling template
# hand drill or drill press
# clamps and disposable wood block(s) for drilling
# files or other abrasive for removing metal burs and sharp edges
# personal safety equipment such as gloves and eye protection for when cutting, drilling, and filing

=== Wiring the solenoid ===
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.
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 >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.

== Links and Resources ==
See the attached solenoid data sheet for its specific characteristics.
Other linear servos: https://www.servocity.com/servos/heavy-duty-linear-servos

NEXT > [[Board Diagrams]]

RemoteControl

2026-06-19T18:41:20Z

Elcanoadmin: /* Events */

= RC controller =
DumboRC X6FG 6 channel Radio Control Unit 2.4 GHz 4.8-10V. Installed summer 2024

Pulse width 1000-2000 milliseconds

* CH1 Steering
* CH2 Throttle / Brake
* CH3 2 way switch: Forward or reverse
* CH4 3 way slider switch: Manual or Automatic or Operator mode
* CH5 Rotary switch: Request to raise gate to undock.
* CH6 Rotary switch: Reserved

The system comes up in Manual (Controlled from RC) mode. The RC can switch the mode to Automatic or Operator. If no data comes from the RC, mode will transition to Operator.

[https://www.amazon.com/dp/B09MS4HBC8/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B09MS4HBC8&pd_rd_w=LeIXy&content-id=amzn1.sym.36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_p=36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_r=SF0RW81Y2X0PB3BGXJZP&pd_rd_wg=fWdsi&pd_rd_r=6c04f252-61f9-40a5-ac07-847c559b0e41&s=toys-and-games&sp_csd=d2lkZ2V0TmFtZT1zcF9kZXRhaWxfdGhlbWF0aWM Amazon]

[[File:DUMBORC.jpg|300px|]]

= Operator Control =

If a person is riding the vehicle, they can use a joystick and switches for the same functionality as the RC controller

* Joystick Left-Right: Steering
* Joystick up/down: Throttle / Brake
* Switch: Forward or reverse
* Switch: Manual or Automatic mode
* Switch: Request to raise gate to undock.
^ There is an Emergency Stop button on the vehicle.

= Automatic Control =

In Automatic mode, the Nav computer sends driving commands over CAN. Automatic mode is selected by the RC or Operator switch. There are separate Auto modes, depending on whether Auto was selected from the RC or Operator, since the response to E-stop differs.

The system can go into Emergency Stop from various situations.
* If Auto Mode was initiated from RC, the RC switch will be in Auto mode. Estop is cleared by returning the RC switch to Manual Mode.
* If Auto Mode was initiated by the operator, the Operator switch will be in Auto mode. Estop is cleared by setting the Operator switch to Manual Mode.
* If the operator pushes the E-Stop button, E-stop is cleared by the button being reset.

= Modes =

Trike behavior depends on the mode. In RC control, pulling the trigger in puts on the brakes. In Operator or Automatic mode, the RC unit is disabled, except that pulling the trigger in is an E-Stop. State transitions are shown in the diagram. An LED on the vehicle is set to a color in the diagram to indicate the mode.

[[File:State transitions2A.png]]

== Events ==

* RC_DATA: Valid data from RC
* NO_RC: No data from RC
* RC_MAN: RC mode switch set to manual
* RC_OP: RC mode switch set to operator
* RC_AUTO: RC mode switch set to auto
* RC_BRAKE: RC applies brake
* NO_CAN: No recent data from CAN
* NO_OP: No operator action for too long
* OP_AUTO: Operator switch set for auto
* OP_MAN: Operator switch set for manual
* OP_BRAKE: Operator applies brake
* OP_ESTP: Operator pushes E-stop button
* OP_RTN: Operator resets E-stop button
* CAN_MAN: Auto mode requests manual takeover
* AUTO_ESTP: Auto mode requests E-stop

RemoteControl

2026-06-19T18:38:12Z

Elcanoadmin: /* Events */

= RC controller =
DumboRC X6FG 6 channel Radio Control Unit 2.4 GHz 4.8-10V. Installed summer 2024

Pulse width 1000-2000 milliseconds

* CH1 Steering
* CH2 Throttle / Brake
* CH3 2 way switch: Forward or reverse
* CH4 3 way slider switch: Manual or Automatic or Operator mode
* CH5 Rotary switch: Request to raise gate to undock.
* CH6 Rotary switch: Reserved

The system comes up in Manual (Controlled from RC) mode. The RC can switch the mode to Automatic or Operator. If no data comes from the RC, mode will transition to Operator.

[https://www.amazon.com/dp/B09MS4HBC8/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B09MS4HBC8&pd_rd_w=LeIXy&content-id=amzn1.sym.36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_p=36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_r=SF0RW81Y2X0PB3BGXJZP&pd_rd_wg=fWdsi&pd_rd_r=6c04f252-61f9-40a5-ac07-847c559b0e41&s=toys-and-games&sp_csd=d2lkZ2V0TmFtZT1zcF9kZXRhaWxfdGhlbWF0aWM Amazon]

[[File:DUMBORC.jpg|300px|]]

= Operator Control =

If a person is riding the vehicle, they can use a joystick and switches for the same functionality as the RC controller

* Joystick Left-Right: Steering
* Joystick up/down: Throttle / Brake
* Switch: Forward or reverse
* Switch: Manual or Automatic mode
* Switch: Request to raise gate to undock.
^ There is an Emergency Stop button on the vehicle.

= Automatic Control =

In Automatic mode, the Nav computer sends driving commands over CAN. Automatic mode is selected by the RC or Operator switch. There are separate Auto modes, depending on whether Auto was selected from the RC or Operator, since the response to E-stop differs.

The system can go into Emergency Stop from various situations.
* If Auto Mode was initiated from RC, the RC switch will be in Auto mode. Estop is cleared by returning the RC switch to Manual Mode.
* If Auto Mode was initiated by the operator, the Operator switch will be in Auto mode. Estop is cleared by setting the Operator switch to Manual Mode.
* If the operator pushes the E-Stop button, E-stop is cleared by the button being reset.

= Modes =

Trike behavior depends on the mode. In RC control, pulling the trigger in puts on the brakes. In Operator or Automatic mode, the RC unit is disabled, except that pulling the trigger in is an E-Stop. State transitions are shown in the diagram. An LED on the vehicle is set to a color in the diagram to indicate the mode.

[[File:State transitions2A.png]]

== Events ==

* RC_DATA: Valid data from RC
* NO_RC: No data from RC
* RC_MAN: RC mode switch set to manual
* RC_OP: RC mode switch set to operator
* RC_AUTO: RC mode switch set to auto
* RC_BRAKE: RC applies brake
* NO_CAN: No recent data from CAN
* NO_OP: No operator action for too long
* OP_DATA: Switch change on operator panel
* OP_AUTO: Operator switch set for auto
* OP_MAN: Operator switch set for manual
* OP_BRAKE: Operator applies brake
* OP_ESTP: Operator pushes E-stop button
* OP_RTN: Operator resets E-stop button
* CAN_MAN: Auto mode requests manual takeover
* AUTO_ESTP: Auto mode requests E-stop

RemoteControl

2026-06-19T18:32:52Z

Elcanoadmin: /* Automatic Control */

= RC controller =
DumboRC X6FG 6 channel Radio Control Unit 2.4 GHz 4.8-10V. Installed summer 2024

Pulse width 1000-2000 milliseconds

* CH1 Steering
* CH2 Throttle / Brake
* CH3 2 way switch: Forward or reverse
* CH4 3 way slider switch: Manual or Automatic or Operator mode
* CH5 Rotary switch: Request to raise gate to undock.
* CH6 Rotary switch: Reserved

The system comes up in Manual (Controlled from RC) mode. The RC can switch the mode to Automatic or Operator. If no data comes from the RC, mode will transition to Operator.

[https://www.amazon.com/dp/B09MS4HBC8/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B09MS4HBC8&pd_rd_w=LeIXy&content-id=amzn1.sym.36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_p=36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_r=SF0RW81Y2X0PB3BGXJZP&pd_rd_wg=fWdsi&pd_rd_r=6c04f252-61f9-40a5-ac07-847c559b0e41&s=toys-and-games&sp_csd=d2lkZ2V0TmFtZT1zcF9kZXRhaWxfdGhlbWF0aWM Amazon]

[[File:DUMBORC.jpg|300px|]]

= Operator Control =

If a person is riding the vehicle, they can use a joystick and switches for the same functionality as the RC controller

* Joystick Left-Right: Steering
* Joystick up/down: Throttle / Brake
* Switch: Forward or reverse
* Switch: Manual or Automatic mode
* Switch: Request to raise gate to undock.
^ There is an Emergency Stop button on the vehicle.

= Automatic Control =

In Automatic mode, the Nav computer sends driving commands over CAN. Automatic mode is selected by the RC or Operator switch. There are separate Auto modes, depending on whether Auto was selected from the RC or Operator, since the response to E-stop differs.

The system can go into Emergency Stop from various situations.
* If Auto Mode was initiated from RC, the RC switch will be in Auto mode. Estop is cleared by returning the RC switch to Manual Mode.
* If Auto Mode was initiated by the operator, the Operator switch will be in Auto mode. Estop is cleared by setting the Operator switch to Manual Mode.
* If the operator pushes the E-Stop button, E-stop is cleared by the button being reset.

= Modes =

Trike behavior depends on the mode. In RC control, pulling the trigger in puts on the brakes. In Operator or Automatic mode, the RC unit is disabled, except that pulling the trigger in is an E-Stop. State transitions are shown in the diagram. An LED on the vehicle is set to a color in the diagram to indicate the mode.

[[File:State transitions2A.png]]

== Events ==

* RC_DATA: Valid data from RC
* NO_RC: No data from RC
* RC_MAN: RC mode switch set to manual
* RC_OP: RC mode switch set to operator
* RC_AUTO: RC mode switch set to auto
* RC_BRAKE: RC applies brake
* CAN_MAN: Auto mode requests manual takeover
* NO_CAN: No recent data from CAN
* NO_OP: No operator action for too long
* OP_DATA: Switch change on operator panel
* OP_AUTO: Operator switch set for auto
* OP_MAN: Operator switch set for manual
* OP_BRAKE: Operator applies brake
* OP_RTN: Operator resets E-stop button
* AUTO_ESTP: Auto mode request E-stop
* OP_ESTP: Operator pushes E-stop button

RemoteControl

2026-06-19T18:32:21Z

Elcanoadmin: /* Automatic Control */

= RC controller =
DumboRC X6FG 6 channel Radio Control Unit 2.4 GHz 4.8-10V. Installed summer 2024

Pulse width 1000-2000 milliseconds

* CH1 Steering
* CH2 Throttle / Brake
* CH3 2 way switch: Forward or reverse
* CH4 3 way slider switch: Manual or Automatic or Operator mode
* CH5 Rotary switch: Request to raise gate to undock.
* CH6 Rotary switch: Reserved

The system comes up in Manual (Controlled from RC) mode. The RC can switch the mode to Automatic or Operator. If no data comes from the RC, mode will transition to Operator.

[https://www.amazon.com/dp/B09MS4HBC8/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B09MS4HBC8&pd_rd_w=LeIXy&content-id=amzn1.sym.36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_p=36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_r=SF0RW81Y2X0PB3BGXJZP&pd_rd_wg=fWdsi&pd_rd_r=6c04f252-61f9-40a5-ac07-847c559b0e41&s=toys-and-games&sp_csd=d2lkZ2V0TmFtZT1zcF9kZXRhaWxfdGhlbWF0aWM Amazon]

[[File:DUMBORC.jpg|300px|]]

= Operator Control =

If a person is riding the vehicle, they can use a joystick and switches for the same functionality as the RC controller

* Joystick Left-Right: Steering
* Joystick up/down: Throttle / Brake
* Switch: Forward or reverse
* Switch: Manual or Automatic mode
* Switch: Request to raise gate to undock.
^ There is an Emergency Stop button on the vehicle.

= Automatic Control =

In Automatic mode, the Nav computer sends driving commands over CAN. Automatic mode is selected by RC or Operator switch. There are separate Auto modes, depending on whether Auto was selected from the RC or Operator, since the response to E-stop differs.

The system can go into Emergency Stop from various situations.
* If Auto Mode was initiated from RC, the RC switch will be in Auto mode. Estop is cleared by returning the RC switch to Manual Mode.
* If Auto Mode was initiated by the operator, the Operator switch will be in Auto mode. Estop is cleared by setting the Operator switch to Manual Mode.
* If the operator pushes the E-Stop button, E-stop is cleared by the button being reset.

= Modes =

Trike behavior depends on the mode. In RC control, pulling the trigger in puts on the brakes. In Operator or Automatic mode, the RC unit is disabled, except that pulling the trigger in is an E-Stop. State transitions are shown in the diagram. An LED on the vehicle is set to a color in the diagram to indicate the mode.

[[File:State transitions2A.png]]

== Events ==

* RC_DATA: Valid data from RC
* NO_RC: No data from RC
* RC_MAN: RC mode switch set to manual
* RC_OP: RC mode switch set to operator
* RC_AUTO: RC mode switch set to auto
* RC_BRAKE: RC applies brake
* CAN_MAN: Auto mode requests manual takeover
* NO_CAN: No recent data from CAN
* NO_OP: No operator action for too long
* OP_DATA: Switch change on operator panel
* OP_AUTO: Operator switch set for auto
* OP_MAN: Operator switch set for manual
* OP_BRAKE: Operator applies brake
* OP_RTN: Operator resets E-stop button
* AUTO_ESTP: Auto mode request E-stop
* OP_ESTP: Operator pushes E-stop button

RemoteControl

2026-06-19T18:31:43Z

Elcanoadmin: /* Automatic Control */

= RC controller =
DumboRC X6FG 6 channel Radio Control Unit 2.4 GHz 4.8-10V. Installed summer 2024

Pulse width 1000-2000 milliseconds

* CH1 Steering
* CH2 Throttle / Brake
* CH3 2 way switch: Forward or reverse
* CH4 3 way slider switch: Manual or Automatic or Operator mode
* CH5 Rotary switch: Request to raise gate to undock.
* CH6 Rotary switch: Reserved

The system comes up in Manual (Controlled from RC) mode. The RC can switch the mode to Automatic or Operator. If no data comes from the RC, mode will transition to Operator.

[https://www.amazon.com/dp/B09MS4HBC8/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B09MS4HBC8&pd_rd_w=LeIXy&content-id=amzn1.sym.36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_p=36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_r=SF0RW81Y2X0PB3BGXJZP&pd_rd_wg=fWdsi&pd_rd_r=6c04f252-61f9-40a5-ac07-847c559b0e41&s=toys-and-games&sp_csd=d2lkZ2V0TmFtZT1zcF9kZXRhaWxfdGhlbWF0aWM Amazon]

[[File:DUMBORC.jpg|300px|]]

= Operator Control =

If a person is riding the vehicle, they can use a joystick and switches for the same functionality as the RC controller

* Joystick Left-Right: Steering
* Joystick up/down: Throttle / Brake
* Switch: Forward or reverse
* Switch: Manual or Automatic mode
* Switch: Request to raise gate to undock.
^ There is an Emergency Stop button on the vehicle.

= Automatic Control =

In Automatic mode, the Nav computer sends equivalent commands over CAN. Automatic mode is selected by RC or Operator switch. There are separate Auto modes, depending on whether Auto was selected from the RC or Operator, since the response to E-stop differs.

The system can go into Emergency Stop from various situations.
* If Auto Mode was initiated from RC, the RC switch will be in Auto mode. Estop is cleared by returning the RC switch to Manual Mode.
* If Auto Mode was initiated by the operator, the Operator switch will be in Auto mode. Estop is cleared by setting the Operator switch to Manual Mode.
* If the operator pushes the E-Stop button, E-stop is cleared by the button being reset.

= Modes =

Trike behavior depends on the mode. In RC control, pulling the trigger in puts on the brakes. In Operator or Automatic mode, the RC unit is disabled, except that pulling the trigger in is an E-Stop. State transitions are shown in the diagram. An LED on the vehicle is set to a color in the diagram to indicate the mode.

[[File:State transitions2A.png]]

== Events ==

* RC_DATA: Valid data from RC
* NO_RC: No data from RC
* RC_MAN: RC mode switch set to manual
* RC_OP: RC mode switch set to operator
* RC_AUTO: RC mode switch set to auto
* RC_BRAKE: RC applies brake
* CAN_MAN: Auto mode requests manual takeover
* NO_CAN: No recent data from CAN
* NO_OP: No operator action for too long
* OP_DATA: Switch change on operator panel
* OP_AUTO: Operator switch set for auto
* OP_MAN: Operator switch set for manual
* OP_BRAKE: Operator applies brake
* OP_RTN: Operator resets E-stop button
* AUTO_ESTP: Auto mode request E-stop
* OP_ESTP: Operator pushes E-stop button

RemoteControl

2026-06-19T18:23:06Z

Elcanoadmin: /* Events */

= RC controller =
DumboRC X6FG 6 channel Radio Control Unit 2.4 GHz 4.8-10V. Installed summer 2024

Pulse width 1000-2000 milliseconds

* CH1 Steering
* CH2 Throttle / Brake
* CH3 2 way switch: Forward or reverse
* CH4 3 way slider switch: Manual or Automatic or Operator mode
* CH5 Rotary switch: Request to raise gate to undock.
* CH6 Rotary switch: Reserved

The system comes up in Manual (Controlled from RC) mode. The RC can switch the mode to Automatic or Operator. If no data comes from the RC, mode will transition to Operator.

[https://www.amazon.com/dp/B09MS4HBC8/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B09MS4HBC8&pd_rd_w=LeIXy&content-id=amzn1.sym.36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_p=36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_r=SF0RW81Y2X0PB3BGXJZP&pd_rd_wg=fWdsi&pd_rd_r=6c04f252-61f9-40a5-ac07-847c559b0e41&s=toys-and-games&sp_csd=d2lkZ2V0TmFtZT1zcF9kZXRhaWxfdGhlbWF0aWM Amazon]

[[File:DUMBORC.jpg|300px|]]

= Operator Control =

If a person is riding the vehicle, they can use a joystick and switches for the same functionality as the RC controller

* Joystick Left-Right: Steering
* Joystick up/down: Throttle / Brake
* Switch: Forward or reverse
* Switch: Manual or Automatic mode
* Switch: Request to raise gate to undock.
^ There is an Emergency Stop button on the vehicle.

= Automatic Control =

In Automatic mode, the Nav computer sends equivalent commands over CAN. Automatic mode is selected by RC or Operator switch. There are separate Auto modes, depending on whether Auto was selected from the RC or Operator, since the response to E-stop differs.

= Modes =

Trike behavior depends on the mode. In RC control, pulling the trigger in puts on the brakes. In Operator or Automatic mode, the RC unit is disabled, except that pulling the trigger in is an E-Stop. State transitions are shown in the diagram. An LED on the vehicle is set to a color in the diagram to indicate the mode.

[[File:State transitions2A.png]]

== Events ==

* RC_DATA: Valid data from RC
* NO_RC: No data from RC
* RC_MAN: RC mode switch set to manual
* RC_OP: RC mode switch set to operator
* RC_AUTO: RC mode switch set to auto
* RC_BRAKE: RC applies brake
* CAN_MAN: Auto mode requests manual takeover
* NO_CAN: No recent data from CAN
* NO_OP: No operator action for too long
* OP_DATA: Switch change on operator panel
* OP_AUTO: Operator switch set for auto
* OP_MAN: Operator switch set for manual
* OP_BRAKE: Operator applies brake
* OP_RTN: Operator resets E-stop button
* AUTO_ESTP: Auto mode request E-stop
* OP_ESTP: Operator pushes E-stop button

RemoteControl

2026-06-19T18:18:28Z

Elcanoadmin: /* Events */

= RC controller =
DumboRC X6FG 6 channel Radio Control Unit 2.4 GHz 4.8-10V. Installed summer 2024

Pulse width 1000-2000 milliseconds

* CH1 Steering
* CH2 Throttle / Brake
* CH3 2 way switch: Forward or reverse
* CH4 3 way slider switch: Manual or Automatic or Operator mode
* CH5 Rotary switch: Request to raise gate to undock.
* CH6 Rotary switch: Reserved

The system comes up in Manual (Controlled from RC) mode. The RC can switch the mode to Automatic or Operator. If no data comes from the RC, mode will transition to Operator.

[https://www.amazon.com/dp/B09MS4HBC8/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B09MS4HBC8&pd_rd_w=LeIXy&content-id=amzn1.sym.36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_p=36d4fe03-2814-4a0b-86e2-d1e3d3071509&pf_rd_r=SF0RW81Y2X0PB3BGXJZP&pd_rd_wg=fWdsi&pd_rd_r=6c04f252-61f9-40a5-ac07-847c559b0e41&s=toys-and-games&sp_csd=d2lkZ2V0TmFtZT1zcF9kZXRhaWxfdGhlbWF0aWM Amazon]

[[File:DUMBORC.jpg|300px|]]

= Operator Control =

If a person is riding the vehicle, they can use a joystick and switches for the same functionality as the RC controller

* Joystick Left-Right: Steering
* Joystick up/down: Throttle / Brake
* Switch: Forward or reverse
* Switch: Manual or Automatic mode
* Switch: Request to raise gate to undock.
^ There is an Emergency Stop button on the vehicle.

= Automatic Control =

In Automatic mode, the Nav computer sends equivalent commands over CAN. Automatic mode is selected by RC or Operator switch. There are separate Auto modes, depending on whether Auto was selected from the RC or Operator, since the response to E-stop differs.

= Modes =

Trike behavior depends on the mode. In RC control, pulling the trigger in puts on the brakes. In Operator or Automatic mode, the RC unit is disabled, except that pulling the trigger in is an E-Stop. State transitions are shown in the diagram. An LED on the vehicle is set to a color in the diagram to indicate the mode.

[[File:State transitions2A.png]]

== Events ==

* RC_DATA: Valid data from RC
* NO_RC: No data from RC
* RC_OP: RC mode switch set to operator
* RC_BRAKE: RC applies brake
* NO_CAN: No recent data from CAN
* NO_OP: No operator action for too long
* OP_AUTO: Operator switch set for auto
* OP_BRAKE: Operator applies brake
* OP_RTN: Operator resets E-stop button
* RC_MAN: RC mode switch set to manual
* RC_AUTO: RC mode switch set to auto
* CAN_MAN: Auto mode requests manual takeover
* OP_DATA: Switch change on operator panel
* OP_MAN: Operator switch set for manual
* AUTO_ESTP: Auto mode request E-stop
* OP_ESTP: Operator pushes E-stop button

RemoteControl

2026-06-19T18:16:04Z

Elcanoadmin: /* Modes */

RemoteControl

2026-06-19T18:13:33Z

Elcanoadmin: /* Modes */

RemoteControl

2026-06-19T18:12:16Z

Elcanoadmin: /* Automatic Control */

RemoteControl

2026-06-19T18:09:42Z

Elcanoadmin: /* RC controller */

RemoteControl

2026-06-19T18:08:43Z

Elcanoadmin: /* RC controller */

RemoteControl

2026-06-19T17:58:51Z

Elcanoadmin:

RemoteControl

2026-06-19T17:55:37Z

Elcanoadmin:

RemoteControl

2026-06-19T17:54:54Z

Elcanoadmin:

File:State transitions2A.png

2026-06-19T17:54:06Z

Elcanoadmin: State Transitions

== Summary ==
State Transitions

RemoteControl

2026-06-19T17:52:54Z

Elcanoadmin:

RemoteControl

2026-06-19T17:44:08Z

Elcanoadmin: /* RC controller */