P18392: Remote Control Bicycle Braking System
/public/

Integrated System Build & Test

Table of Contents

Team Vision for Integrated System Build & Test Phase

The main goal for this phase was to integrate the previously completed sub systems and reach the next step of functional demos. Core functions of communication, actuation, user interaction, and mounting are to be demonstrated.

Individual Plans

Accomplished

Functional Demos

Technical Paper Sections

Test Results Summary

Test #13 (Drop Testing) Steven/Gabriel

Upon completion of the initial remote enclosure, drop testing was performed to ensure robustness during normal use. Initially, a chest high drop was performed with the remote. This did not yield any damage to either the face or body. No additional damage was seen in the following 3 drops from this height.

After the chest height tests were complete, a more damaging scenario was tested. This time, the remote was thrown slightly upward with an induced spin. It was with test case that the remote body failed.

Remote Body Failure

Remote Body Failure

Remote Body Failure

Remote Body Failure

Upon inspection, the remote failed directly at the insertion point of the thermal set thread inserts. It is inferred that the remote landed directly onto the exposed bolt which inflicted stress directly at the thread insert jpoint. The stress caused the 3D printed layers to separate on the body and faceplate.

Remote Body Failure Detail

Remote Body Failure Detail

After observing this failure, it was clear that the face mounting hardware could not be exposed. This would reduce the potential stress concentration in the event of a remote drop. In addition, recessing the hardware will make the remote more comfortable to hold during use.

Remote & Faceplate Revisions

Remote & Faceplate Revisions

These new revisions turned out well in the initial print.

Initial protoboard used for testing

Initial protoboard used for testing

Eli

The phase started with the plan to create a functioning protoboard for the bike electronics and additionally work on a PCB. The protoboard will be used as a back up if needed. The majority of the effort was concentrated on the PCB design.

Initial protoboard used for testing

Initial protoboard used for testing

The schematic needed slight rework to account for the appropriate footprints of each component and slight changes to some connections. The design was then reviewed and continued to the next phase of PCB design

KiCad Bike Circuit Schematic

KiCad Bike Circuit Schematic

KiCad Bike PCB Layout

KiCad Bike PCB Layout

The PCB layout is generated in KiCad. The design only required a two-layer board. The main concern was the high currents passing through the 12-amp fuse. A copper pore was used to handle higher currents, additionally no thermal reliefs were used on the through hole connections. KiCad offers a 3d viewer and gives and idea what the PCB will look like when produced. Not all components have 3d models.
KiCad Bike PCB 3D View

KiCad Bike PCB 3D View

Printed PCB from PCBway

Printed PCB from PCBway

The PCB was printed by PCBway and arrived sooner than expected, with the help of Gabe the PCB was populated and tested for functionality. It has been successful and functions as expected.
Populated Bike PCB

Populated Bike PCB

Bike PCB Connected to the Motor Controller

Bike PCB Connected to the Motor Controller

The wiring harness has been started and the below figure shows the wire wrap and connectors that will be used. Heat shrink was also used to tidy up the end product.
Final cabling example

Final cabling example

Justin

Communication Protocol

Communication Protocol

Communication Protocol

Screen Generation

Remote User Interface Screen Layout

Remote User Interface Screen Layout

During this phase I continued to work on finalizing the remote, both in updates to the remote casing and minor work on the remote PCB as well. I generated a simple sketch for reading from the speed sensor that will be used to monitor rider speed. I generated the internal component mounting plate for the bike enclosure.

Budget

Budget Breakdown for New Funding

Budget Breakdown for New Funding

Nicholas

UART control

The Pololu comes with the option to use digital control using UART. This is more robust over PWM as it allows for monitoring of different parameters such as errors, current, and position.

With UART control a very basic calibration demo was created where it was able to fully extend from its current position, then fully pull back until it sensed a load by detecting when more current than usual was being drawn. This was done physically by tying a 25lb weight to the end of the actuator with slack, then having it run through the calibration and stop right when it began to pull the weight.

ADC Battery Monitoring

Lead acid batteries have a very linear voltage curve. Using this curve we are able to estimate remaining battery life by measuring voltage. A simple voltage divider was created using a 10k and 33k resistor to scale the ~12V from the battery down by a factor of about 4. There is a passive trickly current of approximately 280uA when the battery is connected to the divider (8500 hours to drain a connected 2.5mAh batery).

A healthy lead acid battery can range as high as 13V, and the divider scales the voltage down far enough for this to still be safe for the teensy ADC pin. A healthy lead acid battery can also be as low as 12.3V, which is where we set the detection to consider as 100%. This avoids the case where a new battery would appear to be permanently at less than 100%, despite being healthy. A lead acid battery will be dangerously close to being rendered unchargeable when as it reaches 11V. Currently our low battery alert will be set to activate at 11.5V. We will have a resolution of ~6% for monitoring in between these two thresholds, based on ADC precision and the amount of bits we set aside in the remote communication packet.

PWM control for alert cluster

Once the PWM module was implemented we were able to turn the alert cluster on and off in software using the Teensy PWM pins.

Overall bike-side barebones system and handoff to Gabe.

Once each portion was individually working, a very rough mockup of the barebones functionality of the overall bike side system was created and tested in Rust. Three different braking states were established:

This is also the order of priority for events at the time of the mockup. All alerts were turned on during the event, then turned off when the event was finished.

NOTE ABOUT BATTERY MONITORING

When a battery is sufficiently loaded, the voltage will drop down to 12V. This occurs when a braking system occurs and thus battery monitoring must be turned off during these events. The voltage will logarithmically approach back to its nominal state once the battery is only passively loaded. It takes approximately 50 seconds to approach ~95% its nominal state.

Gabriel

Packet Communication

Using the packets designs created by Justin, packet packing and unpacking code was created and placed in a library to be shared between bike and remote code implementations. Methods were used for accessing and setting the appropriate bits to prevent copy-pasting errors.

Motor Control and Initialization

The motor control code was taken from Nick and the communication to the motor controller was moved to a separate structure with methods to send and receive values. This was done so that easy to remember names could be used rather than raw control codes.

Next, the load sensing algorithm was modified to act as a initialization sequence. To deal with possible stretching of the brake cable, it is necessary to find both the point where the brake begins to be applied and where it cannot be pulled any more without damaging the braking system. Simply reading the current values and basing the start of braking from that was first tried, but the system would sometimes see a longer than normal inrush current when first starting the motor and determine that as the starting point for braking. As this inrush current was fairly consistent in value a simple differential filter was applied and a significant spike was detected. This method was tested with a weight and worked fairly consistently, but when used on the first full assembly was found not to work. Additional work will occur in the next few weeks to develop this into a working algorithm.

Wireless Communication Bugs

The wireless communication between the bike and remote systems was fine in simple tests, but once placed in a system closer to the final design problems started to occur. The primary problem manifested its self as packets no longer being received by one or both sides despite packets continuing to be sent. When communication stopped, the system continued to respond in all other ways. Packets were confirmed to still being sent by scanning for packets using a third XBee connected to a PC. The problem would become more or less probable, and sometimes even disappear, as code unrelated to communication was changed, particularly when serial outputs were added or removed.

The problem was found to be caused by the frequency of packets being sent. The packet frequency was decreased by an order of magnitude while keeping adequate user responsiveness, and the problem disappeared. The sheer magnitude of packets was most likely causing some sort of buffer overflow, crashing some aspect of the XBee subsystem, though the specific cause has not been found.

Steven

This phase, my work was focused on integrating the various mechanical systems to work together on the tricycle. The actuator plate was the main goal in that once it was mounted on to the frame, the rest of the components could be bolted on. After running into even further delays with the RIT water jet, an outside vendor was found to cut the main plate.
Water Jetting Main Mounting Plate

Water Jetting Main Mounting Plate

With the plate on the tricycle frame, the previously machined actuator sliding components were integrated into one assembly. As a final check of the system fitment, the actuator limits were tested. The fully retracted and extended position were checked for clearance with the clamp open & closed. This would ensure the actuator could never damage the mounting hardware by interfering with it during a brake application.

Mounted Actuator (Clamp Open)

Mounted Actuator (Clamp Open)

Mounted Actuator (Clamp Closed)

Mounted Actuator (Clamp Closed)

Machining Actuator Components

Mounting Actuation Components

Mounting Actuation Components

Bike Electronics Enclosure

Working alongside Justin, all perentant electronic equipment was able to be mounted inside the purchased enclosure. Due to the larger size of the box, the entire charger was mounted internally as well.
Enclosed Tricycle Electronic Components

Enclosed Tricycle Electronic Components

With the components all laid out inside the box, final work can begin on installing wire grommets and the power switch.

Remote Revisions

As mentioned previously in Test #13, modifications had to be made to the remote to increase its robustness to accidental drops. These included moving the face plate bolts inside counter sinks and increasing the shell thickness.

Upon printing this new remote, more potential improvements were found and implemented by Justin.

Bike Enclosure

To prepare the final prototype, the bike enclosure was mounted onto the bike using existing frame mounts.
Mounted Bike Enclosure

Mounted Bike Enclosure

Risk Tracking

Phase 3 Risks

Phase 3 Risks

Problem Tracking

Phase 3 Problem Tracking

Phase 3 Problem Tracking

Plans for next phase

Phase 4 Team Plan

Phase 4 Team Plan

Individual Plans

Justin

Eli

Steven

Gabriel

Nick


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