P18392: Remote Control Bicycle Braking System
/public/

Preliminary Detailed Design

Table of Contents

Team Vision for Preliminary Detailed Design Phase

Steven

Eli

Nick

Gabriel

Justin

Feasibility: Prototyping, Analysis

Force Testing (Steven)

Focusing on a high risk mechanical requirement of applying sufficient braking force to stop the rider (satisfying Customer Requirement #6) the team conducted a force test on the tricycle. To measure this force, there were a few options.

Although very accurate, the in-line load cell was out of the budget and time constraints of the project. On the other hand, the required pressure sensor was not able to be packaged between the brake pads of our caliper. Therefore, a displacement measurement was determined to be the most efficient way to obtain a braking force measurement.

In order to measure the maximum braking force that the caliper would be subjected to during standard operation, the displacement of the brake was measured up until the lever contacted the handlebar. Any further force applied at the handlebar would be inputted into the hand grip rather than the braking system.

Initially, a dial indicator borrowed from the Engineering Application Lab was used to measure the caliper displacement. However, it proved too difficult to secure the indicator to a datum suitable to obtain an accurate measurement.

Dial calipers were then used to measure the displacement. This allowed the team to allow the tricycle move under load and maintain the measurements datum.

With the maximum displacement recorded, a borrowed spring scale was attached to the brake cable to record the actual force to achieve the displacement. To calibrate the spring scale, a known mass was attached and the adjustment dial was turned until the scale read the known weight.

Force was applied to the brake cable until the caliper displacement matched that of the maximum handlebar force.

The average recorded force from the spring scale was 70-80 lbf.

After the design braking force was determined, an actuator could be selected. Using our benchmarking chart, the team first considered the Progressive Automations PA-14. This actuator met our force requirement and would provide a reasonable factor of safety.

However, after contacting Progressive Automations, it was determined that the team would not be able to purchase the actuator through RIT. Therefore, we selected another options from our bench marking chart, the Servo City Heavy Duty LA. This actuator still meets our requirements and is available from an approved RIT vendor.

A crucial attribute of our selected actuator is the "Static Load". This is the maximum force the actuator can hold when power is cut from the system. Therefore, we will be able to apply and hold braking force on the bike without burning out the actorator or electronics.

Motor Controller Benchmarking (Eli)

Actuator Power Management (Nick)

The drop from 12V to 3.3V (battery to Teensy) is much larger than the 3.7 to 3.3V drop making this environment immensely unfavorable for a linear regulator.

LTM4633

A LTM4633 10A switching regulator is being considered, with a boasted efficacy of ~92%.

V78-500

A v78-500 non-isolated switching regulator was also considered. This regulator is significantly cheaper, but supplies only up to 500mA. It boasts ~95% efficiency.

The datasheet provides values for the two capacitors: C1 = 10 uF/50V C2 = 22 uF/6.3V

Battery

A 12V, 2900mAH Lead Acid battery will be used for prototyping and initial benchmarking for actuator power draw and circuit testing.

Range and Wireless Communications Testing (Gabe & Eli)

Range testing was done using XCTU, software provided by Digi for the setup and debugging of XBees. Each XBee was powered from a laptop. One XBee was kept stationary while the second XBee was moved away from it while keeping line of sight. The XBees were moved further apart until a packet was dropped. The distance was measured using a GPS tape-measure app on a phone. A distance of 140 meters was achieved before any packets were dropped, though it should be noted that the XBees quickly regained connection while continuing to be moved further apart.

Alert Testing (Eli)

Buzzer testing

Buzzer testing

Initial tests were performed with a small buzzer. The test shows that the small buzzer will be too quiet to alert rider but the ease of use warrants ordering a larger buzzer.

LED Bike Light

LED Bike Light

A bike light was ordered to act as the LED in the alert cluster, the light already comes with a handlebar mount and a weatherproof enclosure. The internal circuitry will be replaced with an LED driver controlled by the Teensy LC and will be powered from the main battery on the bike.

LED oscilloscope measuring

LED oscilloscope measuring

High mode PWM measurement

High mode PWM measurement

Low mode PWM measurement

Low mode PWM measurement

The brightness of the current set up has two levels, they were measured to determine the PWM signal. The tests provided information that will aid in future programing of the LED.

Models and Schematics

Mounting (Steven)

CAD

Overall Isometric View

Overall Isometric View

Overall Isometric View

Overall Isometric View

In complying with the customer requirements, the system must be easily disconnected and any stored mechanical tension released. In addition, this system must be mechanical and function without the main controller being turned on. To accomplish this, the linear actuator was mounted on a carriage/rail system. A push/pull lever will then attach to the actuator mount. Then, the lever can be used to easily move the entire actuator body 1" forward (to release the tension) or backward (engaging cable tension).

Tensioned Cable Position

Tensioned Cable Position

Untensioned Cable Position

Untensioned Cable Position

Remote (Justin)

CAD

Isometric View of Internal Components of Oval Remote

Isometric View of Internal Components of Oval Remote

Top View of Internal Components of Oval Remote

Top View of Internal Components of Oval Remote

Side View of Internal Components of Oval Remote

Side View of Internal Components of Oval Remote

Isometric View of Internal Components of Square Remote

Isometric View of Internal Components of Square Remote

Top View of Internal Components of Square Remote

Top View of Internal Components of Square Remote

Side View of Internal Components of Square Remote

Side View of Internal Components of Square Remote

Isometric View of Revision 2 Remote Faces

Isometric View of Revision 2 Remote Faces

Top View of Revision 2 Remote Faces

Top View of Revision 2 Remote Faces

Met with Dr. Marshall, human factors and ergonomics, for consultation of remote designs. In general Dr. Marshall approved of the design concepts and provided us with direction moving forward.

Remote System Wiring (Justin)

Preliminary Remote Circuit Schematic

Preliminary Remote Circuit Schematic

Above is a preliminary wiring diagram for the remote circuit. The diagram shows each component of the remote with expected power, ground and signal wires. As depicted the battery will power the microcontroller and all necessary components.

Braking System Wiring (Eli)

Above is a preliminary wiring diagram of the actuator driver circuit. The diagram displays the battery, Teensy LC, motor controller, and the linear actuator. The motor controller is powered from the battery with the red and black wires, in turn the actuator is powered by the motor controller. The light blue wire connects the Teensy LC to the motor controller to send commands to drive the actuator. The light green wire connecting the Teensy LC and the actuator sends the potentiometer reading from the actuator to achieve position control.

Alert Cluster Wiring (Eli)

Above is a preliminary wiring diagram of the alert cluster. The diagram displays the battery, Teensy LC, LED, buzzer and a transistor. The LED will take power from the battery and be controlled by the Teensy LC, the light blue wire shows the connection. The buzzer will also be powered by the battery but inline there is a transistor to control the tone and when it is on.

Charging Circuitry (Remote) (Nick)

BQ25600 Circuit

The general system is shown in this charging circuit. A microcontroller has the ability to interface with the chip via I2C via the SDA, SCL, INT and CE pins. This circuit provides a solid idea of what the circuit topology will look like, including capacitor, resistor and inductor sizes. The power comes in through the rail that is fed in parallel to VBUS, VAC and SYSTEM. REGN represents the thermal regulation the chip utilizes to better charge the battery. The BATSNS rail monitors battery voltage to determine charging status. The STAT pin spits out the charging status of the battery, which can be read in to the microcontroller through I2C.

One 18650 battery will be used for the remote.

One issue that remains is the ability to report battery life. One possible method to do so is to tap into the analog BATSNS rail shown in the diagram and correlate battery voltage with the voltage curve of the given battery. Another option would be to add a gas gauge IC which are specifically built to monitor battery life. The tradeoff would be a slight increase in design complexity for more a more robust measurement.

Power Circuitry (Remote) (Nick)

LD1117 Pinout

LD1117 basic circuit

The simple pinout and circuit is shown. The efficiency of a linear regulator is simply

eta = Vo/Vin = 3.3V/3.7V ~= 90%. This should be sufficient efficency. Some alternatives were considered, including switching regulators in an attempt to achieve an efficiency >95%. The Polulu D24V5F3, 500mA regulator was considered, however it boasts an efficacy between 80 and 90%. The size was also large, ~0.4" x 0.5" x 0.1", versus the LD1117 which boasts dimensions in the range magnitude of ~15mm x 4.4mm x 10mm.

The LD1117 is advertised as a low-drop regulator and is ideal for supply voltages close to the desired output.

Software Framework (Gabe)

Blue: Code to be produced by team. Green: Code libraries already available. Orange: Hardware.

At the lowest level cortex-m and cotex-m-rt provide the inital framework for running Rust code on ARM Cortex-M series devices, like what is found on the Teensy LC. Building on top of that, mkl26 adds support for the specific peripherals found on the NXP MKL26 family chip used in the Teensy LC. embedded_hal adds a interface for generic libraries to use the specific hardware broken out by mkl26. xbee_s2c uses this generic interface to provide support for communicating with the XBee S2C radio over both UART and SPI. On top of all this the Safe Stop software for both the Remote and Brake subsystems is written.

Code Flow Diagrams (Gabe)

public/Detailed Design Documents/Software/comms_loop.png

public/Detailed Design Documents/Software/comms_loop.png

public/Detailed Design Documents/Software/parse_loop.png

public/Detailed Design Documents/Software/parse_loop.png

public/Detailed Design Documents/Software/actuator_loop.png

public/Detailed Design Documents/Software/actuator_loop.png

Bill of Material (BOM) (Justin)

Purchased (Justin)

Comprehensive

Test Plans (Steven)

Risk Assessment (Steven)

Risk Management

Risk Management

Plans for next phase (Steven)

Final Phase Schedule

Final Phase Schedule


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation