Course:VANT151/2026/Capstone/APSC/Team1

Home

Welcome

Welcome to the Team 1 VANT 151 Capstone Project Wiki. This page shows the work of our team for the design project. It includes our project goals, team requirements, task planning, design phase and final outcomes.

Team 1 was operating as multiple sub-teams. The individual sub-teams were each assigned to work on a different part of the vehicle system. This included coding, electrical, mechanical, structural and documentation work. Everyone focused on their part and then all the parts were put together to one final project.

This wiki also demonstrates how our team planned the project, divided the tasks, followed the schedule, and documented our progress. This assists the reader in understanding the work of each sub-team and the evolution of the whole project.

Introduction

The VANT 151 project was a multi-discipline engineering design project. Team 1 was tasked with designing and presenting a vehicle system that includes a range of engineering elements. The project was split in many areas, so the work was distributed in different sub-teams like Coding, Electrical, Mechanical, Structural and Documentation.

The control systems sub-team worked on the code for the transmitter and receiver, the joystick and the buttons, switches and their connections . The Electrical sub-team was in charge of the vehicle’s electronic system including the vehicle board, wiring, fan control, Peltier module circuit and other electrical parts. The Mechanical sub-team worked on the drive train, steering system, suspension and power transmission. The frame, enclosure, panels, transparent parts and doors were the responsibility of the Structural sub-team. The Documentation sub-team assisted Team 1 in producing the final wiki and presentation. We have set up the basic wiki framework, created the Gantt chart, tracked the project schedule and gathered information from each sub-team.

Communication was important in the project because many parts were connected. For instance, the mechanical design impacted the structure, the electrical system had to be housed inside the vehicle, and the coding system was needed to control the functions of the vehicle. So each sub team had to keep each other informed and change things if necessary. This wiki describes the main requirements of Team 1, design work, team progress, drawings and final results.

Team Requirements

Functions

The vehicle’s main functions are to:

1 Move backwards and forwards, under user control.

2 Turn left and right with the steering system.

3 Wireless control signals from the transmitter are received.

4 Carry a dummy or rider in the vehicle.

5 Build a robust structure to accommodate the vehicle body, rider area, and internal components.

Objectives

The goals of this project are to enhance the final vehicle design by:

1 Program and build a working vehicle system with electrical, mechanical and structural parts.

2 Ensuring the control system, drive system, electrical system and structure cooperate.

3 Keeping the vehicle simple, compact, safe and appropriate for the prototype.

4 Ensuring that the vehicle is stable and easy to steer while in motion.

Constrains

The constraints of the project are

1 The vehicle design must be built using the parts and materials supplied in the course.

2 The electrical system must be within the allowed power range, the nominal value is 9.6 V DC and 2.8 A.

3 The body of the vehicle has to be large enough to hold the rider or mannequin within.

4 The vehicle size and structure must be such that the main components can be assembled together in the final assembly.

5 Design shall be made according to the safety requirements and rules given in the course.

Gantt chart

Coding

Overview of the Arduino Code

The Coding sub-team was responsible for the remote-control software and the software interface between the transmitter, vehicle receiver, and dashboard. The system uses three Arduino Nano boards. The first Nano is inside the handheld transmitter. The second Nano is mounted on the vehicle as the receiver. The third Nano is connected to a laptop by USB and works as a radio bridge for the dashboard.

The transmitter reads the joystick and button inputs, then sends a command packet through an nRF24L01 radio module. The receiver reads this command packet and controls the steering servo, drive motor PWM, Peltier module, fan, lights, and buzzer. The receiver also reads the cabin temperature and humidity sensor. The third Nano listens for dashboard telemetry from the receiver and sends the data to a browser dashboard on the laptop.

Table 1. Coding files used in the final design

File	Board	Purpose
TXCODE.ino	Transmitter Arduino Nano	Reads the joystick, Peltier button, buzzer button, and light button, then transmits the RC command packet.
RXCODE.ino	Vehicle receiver Arduino Nano	Receives RC commands, applies vehicle outputs, reads temperature and humidity, sends dashboard telemetry, and enters failsafe when signal is lost.
DASHBOARD_BRIDGE.ino	Third Arduino Nano connected to laptop	Receives telemetry packets and prints them as JSON through USB Serial. It also forwards safe buzzer-tone settings from the dashboard to the receiver.
dashboard.html	Laptop browser	Displays the live dashboard with cabin temperature, humidity, Peltier mode, fan state, lights, motor PWM, steering, failsafe, packet count, and buzzer tone.

Requirements

Functions

The Coding sub-team design must:

1. Read user inputs from the RC transmitter, including joystick movement, Peltier mode selection, buzzer input, and the extra light button.
2. Send wireless command packets from the transmitter to the vehicle receiver using nRF24L01 radio modules.
3. Convert valid receiver packets into vehicle outputs, including steering servo position, drive motor PWM, Peltier mode, fan state, lights, buzzer sound, dashboard telemetry, and failsafe shutdown.

Objectives

The main design objectives are:

1. Make the RC control responsive and predictable so the vehicle can be tested and driven reliably.
2. Make the code easy to debug and demonstrate by including Serial output, live dashboard telemetry, temperature and humidity readings, adjustable buzzer tone, and signal-loss failsafe behavior.

Constraints

The Coding design must work within these constraints:

1. The transmitter and receiver must use the available Arduino Nano pins, nRF24L01 modules, joystick, buttons, switches, sensor, and output hardware.
2. The software must match the Electrical, Mechanical, Structural, and Thermal sub-team designs because the code depends on the actual motor driver, steering actuator, Peltier circuit, fan wiring, light wiring, and dashboard sensor placement.
3. The receiver must return to a safe state if radio communication is lost, so the motor does not continue running without a valid command signal.

The Design

System Architecture

The final coding system has three wireless roles. The transmitter sends driver commands to the receiver. The receiver controls the vehicle and sends telemetry data to the third Nano. The third Nano connects to the laptop by USB and allows the dashboard to show live data.

Figure 1. Final TX layout with joystick, three buttons, power switch, and power LED.

Figure 2. Receiver circuit with extra features: LEDs, buzzer, peltier module and fans.

-

Table 2. Wireless communication roles

Device	Radio role	Main data sent or received
Transmitter Nano	Command sender	Sends joystick X/Y, Peltier mode, buzzer command, fan command, and light command.
Vehicle receiver Nano	Command receiver and telemetry sender	Receives RC commands, controls outputs, reads sensors, and sends telemetry to the dashboard bridge.
Dashboard bridge Nano	Telemetry receiver and safe config sender	Receives vehicle telemetry and sends buzzer-tone settings from the laptop dashboard.

Transmitter Hardware

The transmitter is a rectangular controller box with one joystick, three buttons, one power switch, and one LED to show whether the controller is on. The physical box and mounting layout are part of the controller hardware design, while the Coding sub-team is responsible for reading the inputs and sending the correct command packet.

Transmitter Layout Alternatives and Selection

The transmitter layout was selected by comparing three physical layout alternatives. The goal was to make the controller comfortable to hold, easy to understand, and safe to operate while still leaving enough space for extra features.

Figure 3. Three alternative layouts of the transmitter

Table 3. Transmitter layout alternatives and selection

Alternative	A. Compact layout	B. Mixed layout	C. Separated layout
Description	The joystick, switch, LED, and buttons are all placed on the top surface in a compact arrangement.	The joystick and switch are placed on the top surface, while the feature buttons are placed on the right side of the transmitter.	The joystick is placed in the main driving area, while the switch and feature buttons are placed in a separate control area on the top surface.
Advantages	Small overall layout; simple to understand; all controls are visible from the top.	The top surface is less crowded, and the feature buttons are separated from the joystick area.	Clear separation between driving control and extra features; more space around the joystick; more comfortable two-thumb operation; easier to label and understand.
Disadvantages	The buttons are close to the joystick, which gives less thumb clearance and increases the chance of accidental button presses during driving. It also leaves less space for future features.	Side buttons are less visible during operation and may be harder to press consistently while holding the transmitter. They may also be pressed accidentally by the user's grip.	Requires slightly more planning for the transmitter box layout.
Decision	Not selected.	Not selected.	Selected.

The separated layout was chosen because it provides the best balance of comfort, clarity, and expandability. The joystick is used for the main driving control, while the extra feature buttons are placed in a separate area. This allows the user to keep one thumb on the joystick and use the other thumb for the feature buttons. As a result, the transmitter is more comfortable to hold, easier to understand, and less likely to cause accidental button presses during driving.

This layout also makes testing and demonstration easier because each control area has a clear purpose. The joystick area is used for vehicle movement, while the feature button area is used for extra functions such as the Peltier system, buzzer, and lights.

Final Transmitter Part Drawing

After comparing the layout alternatives, the separated transmitter layout was selected as the final design. The final transmitter uses a joystick for the main driving control and separates the extra feature buttons into a different control area. The part drawings below show the final physical layout of the transmitter.

Figure 4. Top view of the transmitter

Figure 5. Front view of the transmitter

Figure 6. Right view of the transmitter

Figure 7. Isometric view of the transmitter

Table 4 shows a summary of the transmitter inputs.

Table 4. Transmitter inputs

Input	Arduino pin	Coding function
Joystick X-axis	A0	Controls steering. The receiver maps this value to the steering servo pulse.
Joystick Y-axis	A1	Controls drive motor speed. The receiver calibrates the center value, applies a deadzone, and maps joystick travel to PWM.
Button 1	D2	Cycles the Peltier module through OFF, COLD, HEAT, then back to OFF.
Button 2	D3	Activates the buzzer while the button is held.
Button 3	D4	Toggles the vehicle lights on and off. This was chosen as the extra button feature because it is simple, visible, and useful during the conference demonstration.
Power switch	Hardware power path	Turns the transmitter on and off.
Power LED	Power indicator circuit	Shows when the controller is powered.

Vehicle Receiver Hardware

The receiver Arduino Nano is mounted on the vehicle and converts wireless commands into physical outputs. It controls the steering servo, motor driver, Peltier module, fan driver, lights, and buzzer. It also reads the temperature and humidity sensor inside the vehicle cabin.

Figure 8. Temperature and humidity sensor placement inside the vehicle cabin.

Table 5. Receiver outputs and sensor inputs

Part	Arduino pin	Purpose
Steering servo signal	D3	Controls steering position using joystick X.
Motor PWM	D5	Controls drive motor speed using joystick Y.
Peltier enable	D4	Turns the Peltier circuit on or off.
Peltier mode control	D2	Selects cold or heat mode through the Peltier relay/control circuit.
Fan driver	D6	Turns the fan on when the Peltier mode is active.
Lights	D7	Turns the vehicle lights on or off using transmitter Button 3.
Buzzer	D8	Plays a tone while the buzzer button is held. The tone frequency can be adjusted from the dashboard.
DHT temperature/humidity sensor	A0	Measures cabin temperature and humidity for the dashboard.

-

-

Dashboard Bridge and Landing Page

The dashboard feature uses a third Arduino Nano connected to the laptop by USB. This avoids needing an ESP32 or Bluetooth module. The third Nano has its own nRF24L01 radio and receives telemetry packets from the vehicle receiver. It then prints the data to the laptop as JSON through USB Serial. A browser dashboard reads this serial data and displays it as a live landing page.

The dashboard is not a public internet website. It is a local landing page opened on the laptop during testing or the conference. It can show live data in a browser while still keeping the RC transmitter responsible for vehicle movement.

Figure 9. Third Arduino Nano used as a USB radio bridge for the dashboard.

Figure 10. Laptop dashboard showing live RC and cabin telemetry.

Table 6. Dashboard values

Dashboard value	Source	Reason for including it
Cabin temperature	DHT sensor on receiver	Shows whether the Peltier/fan system changes the rider area temperature.
Cabin humidity	DHT sensor on receiver	Adds more environmental data for the cabin.
Peltier mode	Receiver telemetry	Shows if the system is OFF, COLD, or HEAT.
Fan state	Receiver telemetry	Shows if fan output is active with the Peltier system.
Lights state	Transmitter Button 3 and receiver telemetry	Shows the extra button feature.
Motor PWM	Receiver telemetry	Shows the current motor command.
Steering pulse	Receiver telemetry	Shows the current steering servo command.
Failsafe status	Receiver timeout logic	Shows whether the vehicle has entered safe-stop mode.
Signal age and packet count	Receiver telemetry	Helps debug radio communication.
Buzzer tone	Dashboard setting and receiver telemetry	Allows the buzzer sound to be adjusted safely without affecting steering or motor control.

Command and Telemetry Packets

The transmitter and receiver use the same command packet structure so both Arduinos interpret the radio message correctly.

Table 7. Command packet fields

Field	Meaning
x	Joystick X value for steering.
y	Joystick Y value for motor speed.
peltierMode	0 = OFF, 1 = COLD, 2 = HEAT.
buzzerActive	1 when the buzzer button is held, otherwise 0.
fanActive	1 when the Peltier mode is active, otherwise 0.
lightsActive	1 when the lights are on, otherwise 0.

The receiver sends a second packet type to the dashboard bridge. This packet includes the sensor values and the current output state of the vehicle.

Table 8. Telemetry packet fields

Field	Meaning
temperatureC	Cabin temperature in degrees Celsius.
humidity	Cabin relative humidity.
peltierMode	Current Peltier mode applied by the receiver.
fanActive	Current fan command.
lightsActive	Current light command.
motorPWM	Motor PWM value from 0 to 255.
servoPulse	Steering servo pulse in microseconds.
failsafe	Shows whether signal-loss failsafe is active.
signalAgeMs	Time since the receiver last received a valid command packet.
packetCount	Number of command packets received by the receiver.
buzzerToneHz	Current buzzer tone frequency.

Operating Sequence

1. The user turns on the transmitter using the power switch. The power LED turns on.
2. The transmitter initializes the joystick, buttons, Serial output, and nRF24L01 radio module.
3. The transmitter repeatedly reads the joystick and buttons.
4. If Button 1 is pressed, the transmitter cycles the Peltier mode through OFF, COLD, HEAT, and OFF again.
5. If Button 2 is held, the transmitter sends the buzzer-active command.
6. If Button 3 is pressed, the transmitter toggles the light command.
7. The transmitter sends a command packet to the receiver about every 50 ms.
8. The receiver reads valid command packets and updates the last-received time.
9. The receiver maps joystick X to the steering servo and joystick Y to motor PWM after joystick center calibration.
10. The receiver applies Peltier, fan, light, and buzzer outputs.
11. The receiver reads the DHT temperature/humidity sensor approximately every 2 seconds.
12. The receiver sends a telemetry packet to the third Nano about every 250 ms.
13. The third Nano sends the telemetry data to the laptop dashboard as JSON over USB.
14. The dashboard displays live values and can send a safe buzzer-tone setting back to the receiver.
15. If the receiver does not receive a command packet for more than 1000 ms, it enters failsafe by centering steering, stopping the motor, turning off the Peltier, turning off the fan, turning off the buzzer, and turning off the lights.

Program Flowchart

The program flowchart should be uploaded as an image in this section. Mermaid is useful for generating the diagram, but UBC Wiki may not render Mermaid directly. The recommended method is to render the Mermaid flowchart as a PNG or SVG, upload it to UBC Wiki, and place it below as Figure 7.

Figure 11. Final Coding program flowchart for transmitter, vehicle receiver, third Nano bridge, and dashboard.

Extra Features

The extra feature selected for the third transmitter button is vehicle lights. This was chosen because lights are easy to test, easy to show visually, and listed as a common extra feature for the project. The light output is controlled from transmitter Button 3 and displayed on the dashboard.

The second extra feature is the laptop dashboard. Instead of adding an ESP32 or Bluetooth module, the design uses a third Arduino Nano as a USB radio bridge. This allows the team to show live vehicle data on a browser page while using the same nRF24L01 radio system already used for RC communication.

Table 9. Extra features

Extra feature	Description	Status
Vehicle lights	Button 3 on the transmitter toggles a light output on the vehicle receiver.	Implemented in code; needs final light wiring.
Live dashboard	A browser dashboard displays temperature, humidity, Peltier mode, fan, lights, motor PWM, steering, failsafe, packet count, and buzzer tone.	Implemented as local laptop dashboard using a third Arduino Nano bridge.
Adjustable buzzer tone	The dashboard can send a safe buzzer-tone frequency to the receiver.	Implemented in code; works best with a passive buzzer.
Temperature and humidity sensing	A DHT sensor measures cabin environment data near the rider/mannequin.	Implemented in code; sensor must be mounted and wired.

Other possible uses for the extra transmitter button were considered, such as a horn toggle, dashboard marker, manual fan override, or joystick recalibration button. Lights were selected because they have the best balance of simplicity, safety, and demonstration value.

Current Testing Status

At the current stage, the code supports radio command packets, joystick control, Peltier mode cycling, fan command, light toggle, buzzer command, DHT temperature and humidity readings, dashboard telemetry, adjustable buzzer tone, and signal-loss failsafe. Final testing should confirm that the radio modules remain stable when all three Nanos are powered, that the receiver enters failsafe correctly, and that the dashboard updates reliably while the vehicle is running.

Table 10. Testing checklist

Test	Expected result
Transmitter joystick test	Dashboard and receiver Serial output show changing X/Y values.
Peltier button test	Mode cycles through OFF, COLD, HEAT, and OFF.
Buzzer button test	Buzzer plays only while the button is held.
Light button test	Vehicle lights toggle on and off.
DHT sensor test	Dashboard displays cabin temperature and humidity.
Dashboard bridge test	Browser dashboard receives live telemetry from the third Nano.
Failsafe test	Turning off the transmitter causes the receiver to stop the motor and turn off unsafe outputs.

Recommendations

1. Use a 10 uF to 47 uF capacitor across the VCC and GND pins of each nRF24L01 module to reduce radio power problems.
2. Keep the nRF24L01 wires short and power the module from 3.3 V only.
3. Test the DHT sensor before final mounting because incorrect sensor type selection can cause blank temperature and humidity readings.
4. Use a passive buzzer if adjustable tones are needed, because active buzzers may ignore frequency changes.
5. Keep the dashboard control limited to safe accessory settings, such as buzzer tone. Driving and steering should remain controlled by the transmitter.

Mechanical Design

The mechanical sub-system includes the front suspension, drive train, and steering system . These components work together to improve vehicle movement, stability, turning control, and structural support. The main goal is to keep the design simple, compact, easy to assemble, and reliable for the prototype.

Requirements

Functions

1. Front suspension: Absorb shocks and vibrations from the ground, keep the front wheels in contact with the ground and improve stability, and control during movement.
2. Drive train: Transfer power from the motor to the wheels, control the vehicle’s speed and movement, and provide enough torque for the vehicle to move smoothly.
3. Steering: Allow the vehicle to change direction, connect the steering input to the front wheels, and improve turning accuracy and control.

Objectives

1. Front suspension: Allow the front suspension to lean up to 30° during cornering, while keeping the front wheels more balanced and stable during turns.
2. Steering: Target a turning radius of around 600 mm, so the prototype can make tight turns while still keeping the steering system simple and easy to control.
3. Drive train: Increase the tested vehicle speed through the gear system, while keeping the chain movement smooth and reducing chain noise during operation.

Constraints

1. Front suspension: The lean angle is limited by front fork alignment, joint clearance, and wheel contact with the ground.
2. Steering: The steering angle is limited by the available frame space and the movement range of the steering linkage.
3. Drive train: The gear and chain layout is limited by frame space, chain alignment, and proper chain tension.

The Design

Front Suspension

We generated two front suspension designs as shown below:

Table 1. Front suspension design

Design 1	Design 2	Design 3

We used a weighted decision matrix to compare the three designs.

Table 2. Weighted decision matrix for selection of front suspension

	Weight	Design 1	Design 2	Design 3
Simplicity	30%	2	5	4
Durability	30%	3	5	4
Flexibility	40%	5	0	5
Total		3.5	3.0	4.4

Decision: Design 3 was selected because it provides the best overall balance of simplicity, durability, and flexibility. Although Design 2 is the simplest and most durable, it has no flexibility, which significantly lowers its overall score. Design 1 offers high flexibility, but its more complex linkage system makes it less simple and potentially less durable than Design 3. Therefore, Design 3 is the strongest option for the final prototype.

3D Assembly of the Steering Components

Steering

Table 3. 2D drawings of the main components of the steering system

Handlebar	Head	Steering column
The handlebar acts as the main control component of the steering system. Similar to a steering wheel, it allows the user to change the direction of the prototype by controlling the steering mechanism.	The head fixes the handlebar in place and connects it to the steering column. It helps transfer the steering force from the handlebar down to the front suspension system.	The steering column connects the handlebar to the front suspension. It transfers the steering motion from the handlebar down to the front suspension system.

3D picture of drive chain

Drive Chain

The drive train system uses a large gear to transfer power from the motor to two smaller gears connected to the wheel shafts. When the large gear rotates, it drives the smaller gears, causing them to spin at a higher rotational speed. This happens because the smaller gears have fewer teeth, so they complete more rotations for each rotation of the larger gear.

This gear arrangement was chosen to increase the output speed of the wheels while keeping the system compact and simple. The larger gear helps distribute motion to both smaller gears, allowing the vehicle to move forward efficiently. Although this design increases speed, it also reduces torque, so the gear ratio must be balanced to provide enough wheel power for movement.

Recommendations

1. Design simpler structures with fewer small and complex parts to improve 3D-printing reliability. Front Suspension Design 1 repeatedly failed during printing and had to be postponed.
2. Use metal connectors, such as steel pins, bolts, and screws, for moving joints instead of small 3D-printed connectors.
3. Organize the project schedule more effectively and allow extra time for printing, assembly, and redesign because of the large workload.

Appendices

Front suspension and steering sketches

Structural Design

The structural sub-team is responsible for designing and constructing the enclosure structure of the bicycle-based vehicle. The structural sub-team also designs the cabin frame, opaque panels, glazing panels, doors, and rear frame components to protect the rider and internal components while maintaining access, visibility, and ventilation.

Requirement

Functions

The functions of the structural components are to:

1. Environmental Protection: The enclosure must shield the rider from adverse weather conditions (such as wind, rain, and extreme ambient temperatures) and airborne debris.
2. Occupant and internal component safety: The structural shell must act as a protective barrier, reducing the risk of injury to the rider from external impacts or accidental collisions.
3. Structural support: The enclosure frame must support the opaque panels, transparent glazing panels, doors, and other structural components.
4. Access and visibility: The door design must allow the rider to enter and exit the vehicle safely, while the transparent glazing panels must provide enough visibility during operation.

Objectives

1. The vehicle must have an enclosure frame and opaque panels.
2. The vehicle must have natural ventilation.
3. The vehicle must have transparent glazing panels, with at least one vacuum-formed component.
4. The vehicle must have doors for rider entry and exit.

Constraints

1. 3D Printing Tolerances: Low precision caused minor dimensional errors, complicating assembly and weakening the final structure.
2. Understaffed Team: Smaller group size forced members to balance time across multiple sub-teams.
3. Time Limitations: Compounded by labor constraints and assembly delays, severely restricting the project schedule.

The Design

Designed with a minimalist and futuristic aesthetic, the enclosure features a slim structure that protects the rider from weather conditions and external hazards.

Enclosure

The enclosure is the main protective structure of the vehicle. It consists of a frame, opaque panels, glazing panels, and doors. The enclosure protects the rider and internal components from weather, debris, and external hazards while still allowing rider access, visibility, and ventilation.

Figure 1: Isometric View of the Enclosure Chassis with Panels and Doors omitted for clarity.

Figure 2: Isolated View of the Final Door Design

Figure 3: Isometric View of the Door in an Open State

Door

The door is designed as a pantograph door to provide sufficient clearance for the rider to enter and exit the vehicle regardless of how or where it is parked. Figure 3 illustrates the enclosure door mechanism in its open position on the vehicle chassis.

Natural Ventilation

Natural ventilation is achieved by opening or entirely removing the lateral and rear door. This open configuration serves a dual purpose, facilitating passive airflow to cool internal electronics while simultaneously granting unhindered access to the breadboard for inspection and circuit modification.

Figure 4: HVAC Support (Part 1)

Figure 5: HVAC Support (Part 2)

HVAC Supports

As illustrated in figures 4 and 5 both components are rigidly connected to the enclosure chassis, providing structural support to stabilize the HVAC system's position. Additionally, they serve as structural reinforcement to maintain the alignment and stability of the surrounding components.

Extra Features

Figure 6: Rear Door

Rear Door

The rear door seals the back of the enclosure and assists with the vehicle's passive cooling. It can be opened or completely removed to allow airflow, which prevents the internal electronics from overheating. Removing the door also provides quick, direct access to the breadboard for inspections and wiring adjustments. Depending on user preference, the door can be installed as a permanent fixture or kept easily removable.

Design Alternatives

Figure 7: Design Alternative 1

Figure 8: Design Alternative 2

Design Alternative 1:

The initial design focused on a lightweight bicycle chassis that omitted both doors and a full enclosure, allowing easier access to the bike interior and maximizing natural ventilation. However, this lack of doors and an enclosure presents a major issue with respect to protection; the internal components are exposed, resulting in a high risk of component damage as well as environmental hazards for the rider.

Design Alternative 2 (Final):

The second design alternative (the final design) features a full enclosure that ensures the protection of both the rider and the internal components. This configuration incorporates pantograph doors and a rear doors, both of which can be made removable or permanent depending on user preference.

Weighted Decision Matrix

	Weight	Decision 1	Weight 1	Decision 2	Weight 2
Weight	20%	9.0	1.8	5.0	1.0
Sturdiness	25%	4.0	1.0	8.0	2.0
Security	35%	2.0	0.7	9.0	3.15
Natural Ventilation	20%	9.0	1.8	4.0	0.8
Total	100%		5.3		6.95

The final design alternative was selected based on the weighted decision matrix (WDM), which compared weight, sturdiness, security, and natural ventilation. The results indicate that Design Alternative 2 offers a significant advantage in terms of protection, scoring higher in both security and sturdiness. Conversely, Design Alternative 1 provides greater advantages in rider comfort, achieving higher scores in weight and natural ventilation. Because the matrix assigned greater weight to the protective aspects of the vehicle, Design Alternative 2, which was developed specifically to address the lack of protection in Design Alternative 1, emerged as the superior option and was selected as the final design.

While team members made every effort to remain objective during group discussions, the resulting scoring matrix inevitably retains a degree of subjectivity due to the qualitative nature of the evaluation:

• Weight: Due to the lack of a weighing scale, as well as the decision not to physically construct the first design alternative, owing to time constraints and a desire to avoid material waste, the actual weights of the two designs could not be directly compared. Consequently, in the absence of physical prototypes and quantitative data, scores were assigned based on a group discussion where each member justified their decision through qualitative reasoning.
• Sturdiness: Because the first alternative was never physically constructed (due to time limitations and the need to minimize material waste) structural stress testing could not be performed to compare the durability of the two designs. In the absence of physical models and quantitative structural data, the team relied on a group discussion where each member evaluated the sturdiness of the concepts based on mechanical principles and qualitative reasoning.
• Security: Although the first design alternative was not physically constructed, the complete absence of doors and an enclosure made the security advantage of the second design immediately apparent. Nevertheless, to ensure an objective evaluation and avoid any biased interpretations, the final scores were still determined through a formal group discussion where team members cross-verified the safety and protective features of both concepts.
• Natural Ventilation: Because the scoring was based on the physical configuration of the vehicle, the complete absence of doors and an enclosure made it clear that the first alternative would achieve a higher score. Group discussion for this criterion focused primarily on determining the relative degree of performance loss in the second alternative compared to the first. Each member assigned an initial score and presented their underlying rationale. These individual scores were then adjusted through team deliberation only after the respective member consented to the change, and the final metric was established by calculating the average of these agreed-upon scores.

Recomendations

1. Test fit all enclosure parts before final assembly to reduce problems caused by 3D printing tolerances.

2.Use stronger connection points for the doors, panels, and rear door to improve durability.

3.Keep enough clearance for wiring, breadboard access, HVAC supports, and other sub-team components.

Appendices

Enclosure parts sketches

Electrical/Electronic Design

The electrical sub-team is responsible for connecting circuits and powering all electrical components of the Electrical tricycle. The electrical sub-team also does programming and operations of these components.

Requirements

Functions

The functions of the electrical components are to:

1. receive the signal from the trasmitter to control the vehicle

2. provide enough power for motor to move

3. able to rotate the servo to control the direction of the handle bar

4. able to receive the code from coding subteam

5. Pre-programmed automation of the vehicle

6. Complete a figure-8 path without toppling over

Objectives

1. Able to control the speed over 1km/h and maximize it

2. keep the wiring clear and well organized

3. allow the circuit fit in the prototype vehicle

4. Able to monitor the temperature and humidity inside the vehicle

5. able to be stable when no signal is received

Constraints

1. Maximum allowable electrical power consumption: nominal 9.6 V DC, 2.8 A.

2. need to prevent shortcircuit and electrostatics damage.

3. prevent wire loosing during the driving time

4. only can recieve the signal from the transmitter in a small room.

5. suitable location of the receiver in sepcific size

6. do not break the frame of the prototype during testing

The Design

Rejected Design

Our previous rejected design was to solder all the wires together instead of using a breadboard for the connections. In this design, some elecrical conponent are connected together, only a few wire were connected with the breadboard. This made the circuit very messy and difficult to check.

Because of this, even if the circuit could be more organized with extra circuit, we rejected this design to make sure all components are connected with breadboard, so it is more easy to check the circuit issue when troubleshooting.

Drive and Steering Circuit

The receiver gets the signal from the remote control and the Arduino then controls the motor and the servo to make the vehicle move forward and turn.

Receiver connection for VANT151 VD1 Team 1

Fan Circuit

The fan circuit is used to help control the temperature inside the vehicle. When the system is turned on, the fan can move air through the vehicle and help cool the rider area.

VANT151 team1 fan with peltier	sketch of HVAC system

Peltier Circuit

The Peltier circuit is used for cooling. The Arduino controls the Peltier module through the MOSFET so that it can help reduce the temperature inside the vehicle.

VANT151 VD1 team1 electrical fan circuit	VANT151 Team 1 Peltier and the circuit

Boards Mounting

The boards mounting helped keep the wires more organized and made testing easier. This also help us easy to connect and check when the boards were mounted inside the vehicle.

2026 VANT151 Team 1 transmitter & receiver	2026 VANT151 Team 1 electrical circuit with extra features

Autonomous Program

The Autonomous Program can control the motor and steering so the vehicle can move in a straight line and complete the required path. File:RX automation code.docx

2026 VANT151 team1 electrical flowchart

Extra Features (if any)

The receiver was placed in a position where it could receive the remote-control signal more easily. This helped improve the connection between the remote control and the vehicle.

This picture shows the position of the receiver for the remote control
2026 VANT151 electrical sketch

Appendices

Arduino Code

File:TRANSMITTERCODETEAM1 1.docx File:RECEIVERCODETEAM1 1.docx File:DASHBOARDCODESTEAM1.docx

File:RX automation code.docx

DEMO VIDEO

About Us

Sub-teams:

Documentation
Chengxiang Hu Documentation Sub-team Member I helped with the Wiki, project documentation, Gantt Chart and project planning. I collected data from different sub-teams and helped to produce the final Wiki and presentation. Through this project I learned how to manage project information, track project progress and work with different team members. I’ve also developed my communication and teamwork skills.	Amartuvshin Tavinbekh Documentation sub-team member. I was responsible for task planning, project organization, and keeping our documents updated. Through this role, I learned to communicate better with my team members and found more efficient ways to collect and organize data's from different teams.
Electrical/Electronic
Tim Cai Electrical Sub-team Design and Assembly I helped with the receiver circuit, wiring, Arduino code, and testing the remote-control and autonomous functions. Through this project, I learned how to connect electronic components, troubleshoot wiring problems, and improve the reliability of the control system.	Jianyu Zhang My role in the team: to work on the electrical and electronic design of the tricycle. I helped with the receiver circuit, wiring, Arduino code, and testing the remote-control and autonomous functions. Through this project, I learned how to connect electronic components, troubleshoot wiring problems, and improve the reliability of the control system.
Mechanical
Thang Le Mechanical Sub-team Design and Main mechanical design in Solidworks. I led the overall mechanical design process by developing the front suspension, drive train, and steering system. I also used SolidWorks to model the individual components and integrate these mechanical mechanisms into the complete prototype assembly. Through this experience, I learned how important it is to consider manufacturability, assembly, and compatibility between different sub-systems during the design process.	Jiarui Zhang Mechanical Sub-team Design and Basic SolidWorks Assembly. I led the basic SolidWorks design and main assembly process for the mechanical system, including the front suspension, drive train, and steering system. I was part of the mechanical sub-team. I contributed to the basic SolidWorks design and main assembly, including the front suspension, drive train, and steering system. From this project, I learned how to balance simplicity, durability, and buildability when designing mechanical parts.
Structural
Jimmy Chong Wang Structural Sub-team Design and Assembly Leader I led the overall design process, developing two alternative enclosure concepts and utilizing SolidWorks to sketch and model both the individual components and the complete assembly. I also worked with another subteam to design the gear system and integrate it within the enclosure. Additionally, I was in charge of the assembly of the bike structure and was responsible for troubleshooting any issues that arose.	Jinyuan Jin Structural Design Support and Documentation Contributor I assisted in completing the assigned structural tasks and actively discussed the design direction and division of work with my teammate. I created sketches based on the agreed enclosure design, contributed ideas and suggestions during the design process, helped make revisions, and took a major role in the project document.
Coding
Christopher Rodas Castillo Chief Developer and Team Leader My main contributions were organizing the team’s coding work, planning the project structure, developing and testing key features, debugging errors, and improving the overall functionality of the final product. I also helped connect different parts of the project together, reviewed the code to make sure it worked properly, and supported teammates when they ran into technical problems. Through this experience, I learned how important communication, planning, and teamwork are in software development, especially when turning ideas into a working project. https://www.linkedin.com/in/rodaschristopher/	Bowen Zheng coding sub-team member My main contribution to the team was designing and fabricating the transmitter housing, as well as assisting in building the transmitter circuitry, including soldering and component assembly. Through this experience, I learned the importance of collaboration and gained a deeper understanding of how transmitters work, including their internal components and code development.