P18392: Remote Control Bicycle Braking System
/public/

Subsystem Build & Test

Table of Contents

Team Vision for Subsystem Level Build & Test Phase

This phase, the team focused on fabricating and testing our components at a sub system level. These foundational subsystems are crucial in that they will eventually create the final "Safe Stop" product. This fabrication included machining, soldering, and programming.

Plan

Accomplished

Test Results Summary

Here, we see that 6 tests have been completed in the last phase. These were conducted at the subsystem level and reflect the anticipated system level performance.
Updated Testing Matrix

Updated Testing Matrix

Below, each test procedure is outlined as followed with the accompanying results.

Test #7 (Water Ingress)

Test Description: Confirm no water ingress when electronics enclosure is subjected to IP65 conditions
Water Ingress Testing

Water Ingress Testing

A sample video of the water ingress test can be found at the link below https://drive.google.com/open?id=1DWjuA8Bj16OauNcARcgJtkMU_8EThoYW

At the conclusion of the test, no water was found inside the box. This confirms the manufacture's claim that the box is water tight. It may be advantageous to perform this test again once the connector bulkheads are installed.

Test #14 (Actuator Force)

Test Description: Characterize maximum required force provided by actuator

The set up for force testing was not entirely representative of the final system, but it did utilize all the same components. The component layout is seen here.

Force Testing Components

Force Testing Components

The total of ~113lb was applied to the actuator during application. This was done manually by pulling on the actuator with the spring scale.
113lb applied to the actuator

113lb applied to the actuator

113lb applied to the actuator

113lb applied to the actuator

Current was captured on the digital multi meter for future reference.

2.7A drawn during 113lb test

2.7A drawn during 113lb test

With the representative braking load applied, the actuator was commanded to move. This can be seen in the video below.

https://drive.google.com/open?id=1-apC93smq0y8H-nTZhtJrHjdBhclGD4S

Test #16 (Actuator Stroke Limits)

Test Description: Find stroke limits of actuator when installed

Actuator Fully Retracted (0.75

Actuator Fully Retracted (0.75")

Actuator Fully Extended (2.75

Actuator Fully Extended (2.75")

From the two recorded measurements, the actuator stoke is (2.75"-0.75")=2". This mirrors the manufacturers claim. https://www.servocity.com/hda2-50

Test #17 (Actuator Current)

2.7A drawn during ~100lb test

2.7A drawn during ~100lb test

Testing Link https://drive.google.com/open?id=1GDsHbZVXAoDMu8ij7DN47YY6KfcTEDwL

Test #21 (Alert Cluster LED)

Test Description: Alert cluster is visible & audible in all outdoor conditions

Preliminary Testing of LED Inside

Preliminary Testing of LED Inside

Final Testing of LED Outside

Final Testing of LED Outside

Full Brightness LED on Cloudy Day (Too Bright)

Full Brightness LED on Cloudy Day (Too Bright)

Here, the alert cluster is activated outdoors and is clearly visible to the user

https://drive.google.com/open?id=13ClBi7a_H-nrQxgGMyA7QHlm0CxF9DNC

Test #23 (Passive Actuator Performance)

Test Description: Determine movement of passive actuator (no power applied)

The actuator set up was similar to test #14 as they were completed together.

113lb applied to the actuator

113lb applied to the actuator

The internal potentiometer was used to measure actuator position. The voltage reading across this potentiometer directly correlates to position. Therefore, no change in voltage should be seen when applying force.

Initial actuator position

Initial actuator position

Actuator position after applying ~113lb

Actuator position after applying ~113lb

Individual Contributions

In addition to the tests run during this phase, each team member contributed to the sub-system build. Outlined below are individual accomplishments. However, collaboration between team members was crucial to meeting milestones during the phase.

Steven Reuter

During this phase, mechanical work primarily focused on fabricating the initial actuator mounts. These parts were the most crucial to begin testing of our components. Below are photos of the machining processes used to create the front/rear actuator mounts, clamp spacer, bushings, and clevis
Machining Actuator Front Mounting Profile

Machining Actuator Front Mounting Profile

Test Machining Actuator Front Mounting Profile

Test Machining Actuator Front Mounting Profile

Drilling Cable Hole in Clevis

Drilling Cable Hole in Clevis

Turning Bushings for Actuator Mounting

Turning Bushings for Actuator Mounting

Due to water jet maintenance, the main mounting plate could not be manufactured during this phase. Instead, a plywood base was used as a representative base to maintain the test schedule.

Test Actuator Mounting

Test Actuator Mounting

Front Actuator Mount

Front Actuator Mount

Rear Actuator Mount

Rear Actuator Mount

Gabriel Smith

The Timer module was a fairly simple module, but it held some stumbling points. The module has many options, not all of which are well documented, which can easily lead to a misconfigured module. In addition, if certain settings are not set correctly, the module may act like everything is fine, but no external effect will be seen. Some of this was sidestepped by basing the initialization code on a C sample found online.

Much of the debugging was taken care of by using "LED debugging", e.g. Light up an LED when a certain point in code is reached. This form of debugging was used as it is quick and no real debugger interface is available on the Teensy LC.

The library for communicating with the XBee in API mode has been completed. Some testing and debugging has occurred with more to follow. The library has been tested on a Teensy LC communicating over an XBee to a host PC. Some slight inconsistencies between the behavior of the XBee connected to the Teensy LC and the XBee connected to the host PC have been seen, but the cause of the inconsistencies has not been tracked down. Even with these inconsistencies communication is possible and the project can move forward.

The screen had been previously prototyped on a breadboard, but not with the pins and exact interfaces that were used for the PCB design. When first moving to the correct interface the screen would not respond. After probing the SPI bus signals, an error was found in the SPI module driver, selecting the wrong signal phase. When this bug was fixed, then the screen worked with the correct pins and interfaces on a breadboard, but not the PCB. We are still exploring why this is.

Justin Kon

Assembled PCB (Front)

Assembled PCB (Front)

Assembled PDC (Back)

Assembled PDC (Back)

Screen Concepts

Screen Concepts

Eli Laramie

During this phase the primary focus was on the bike side electronics. The alert LED was programed and tested. The new code moved away from creating a PWM signal to control the brightness. Now the LED is controlled by passing a value in the range of 0 to 255. For a reasonable level of brightness, a good range is 10 – 100.
LED Off Outside

LED Off Outside

The original voltage regulation circuitry was designed by Nicolas. From the breadboard design a protoboard was soldered together. The board is the start of the bike side break out board for all electrical components that will fit in the box.

12 to 3 Volt Regulator on a Protoboard

12 to 3 Volt Regulator on a Protoboard

12 to 3 Volt Regulator on a Protoboard

12 to 3 Volt Regulator on a Protoboard

Nicholas Jederlinic

public/MSD2/SubSysBuildTest/Nick/JRK_debug.PNG public/MSD2/SubSysBuildTest/Nick/JRK_error.PNG public/MSD2/SubSysBuildTest/Nick/JRK_PID.PNG

This was a simple setup on windows that allows us to debug the actuator. The little graph on the top right gives us a view of both the actuator signals being sent out and feedback levels when connected via USB. These values can also be accessed via serial commands, however that has not been explored yet. The initial testing involved simply using an analog voltage to move the actuator forwards and backwards at different speeds.

public/MSD2/SubSysBuildTest/Nick/Teensy_Pol_Actuator.jpg

Shown here are also the feedback connections (yellow, blue, and white wires), and the PWM output connection from the Teensy to the motor controller (teal and grey).

The actuator actually didn't come with a datasheet so it took a little bit of guessing and assumptions to get the feedback working. The feedback of the actuator is a simple potentiometer with the yellow and white wires as references. The JRK motor controller feeds 5V to to the pot and the blue wire produces the signal between 0-5V that corresponds to the position of the actuator. Simple testing using the configuration utility in analog voltage mode and an oscilloscope verified the accuracy of the feedback.

The PWM signal is fed into the RX pin on the JRK motor controller(shown as the teal wire). According to the datasheet, it will take a PWM signal between 10-150Hz with pulse widths of 400-2600 microseconds. The motor controller encodes this by multiplying the pulse width by 3/2 and producing a number between 0-4096, corresponding to 0-100% actuation. For example, a 1500us pulse width will encode into 2250, or half of its fully actuated position.

In practice, this is not 100% accurate. Using a little bit of fine tuning, the following values were used in the PWM module to figure out "landmarks" that are usable to control the actuator:

The math is shown: (1/(24MHz)) * (8 Prescale) * (count) = time (seconds)

Using an ~8ms period (count = 0x6000) to produce a ~125 Hz signal, the pwm triggers are as follows:

0x500 ~= Fully retracted

0x1000 = Middle

0x1E00 = Fully actuated

NOTE: The fully retracted is only an estimate. Anything below this falls below the 400us minimum pulse that the PWM input accepts. This leaves about ~1mm of actuation left before actual full retraction. This can possibly be solved by instead using a serial command to calibrate to a fully retracted state, or simply ignored as this value will always move the actuator to the same position.

Bike regulator wired with 3v3 output tested.

Bike regulator wired with 3v3 output tested.

The remote system was tested on the remote PCB as the IC was too small to test on a breadboard. It was verified to work within the 4.2~3.4V range (range of a healthy Lithium Ion battery).

Risk and Problem Tracking

Risk Management

Two main risks came into fruition during this phase. That was our budget concerns and actuator failure during testing. Thanks to the diligent financial lead Justin Kon, the budget risk was mitigated. Justin secured $200 of additional funding to help purchase the final Safe Stop components.

Risk of damaging the actuator was mitigated by Eli, Nicholas, and Steven. The circuit used for testing was safe and did not overload the motor controller or actuator itself. Also, a reasonable force was applied to the actuator during testing as to not damage the internal mechanism.

Phase #2 Risk Management

Phase #2 Risk Management

Problem Tracking

Small issues during building/testing were dealt with internally. However, larger problems effecting the project progress have been documented for review each week
Phase #2 Problem Tracking

Phase #2 Problem Tracking

During this phase $200 of additional funding was aquired, below is a breakdown of the previous $1000 budget and how it was spent.

General Budget Breakdown

General Budget Breakdown

Bike Budget Breakdown

Bike Budget Breakdown

Subsequent Phase

Phase 2 Schedule

Phase #2 Gantt Chart

Phase #2 Gantt Chart

Individual Plans

Eli

Steven

Gabe

Justin

Nick

Functional Demos


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