Preliminary Detailed Design
Team Vision for Preliminary Detailed Design Phase
- Team Vision
- Break into individual groups (communications/mechanical/electrical) and work towards high risk design items. Focused on feasibility of designs and system integration.
- Remote handlebar mounting
- Brake force testing
- Actuator selection
- Actuator frame mounting design
- Electronics enclosure frame mounting design
- Mechanical disconnect linkage design
- Alert cluster prototype
- Testing brake force and obtained result to help in selecting an actuator
- Selected actuator through RIT approved supplier
- Created system mounting designs for actuator and electronics enclosure
- Selected IP65 enclosure for braking system electronics.
- Designed mechanical disconnect and integrated into frame mounting
- Remote handlebar mounting
- Incomplete because final remote shape/size/shell is not approved by customer.
- Remote handlebar mounting
- Alert Cluster Circuit Design
- Alert Cluster Hardware Selection
- Prototype Alert Cluster and Handlebar Mount
- Prototype Remote Concepts
- Actuator and motor controller selection
- Microcontroller and Wireless Module selection
- Alert Cluster Circuit Design – Mocked up a rough circuit schematic for the cluster
- Alert Cluster Hardware Selection – Tested a buzzer that was on hand and selected an LED that already had handlebar mounting capabilities, started testing the LED
- Prototype Remote Concepts - Once Justin had CAD prototype, I facilitated the 3D printing of the models
- Actuator and motor controller selection - Benchmarked motor controllers once the actuator was selected
- Microcontroller and Wireless Module selection – Helped Gabriel select the Teensy LC and Xbee for the components to be used in this project
- Battery usage calculations were performed in order to assess compliance with new requirement E43.
- 18650 MXJO Lithium-Ion battery selected for remote power. Actuator battery not yet selected. Rhino brand 12V battery being looked at, testing required to ascertain actual power requirements.
- Battery charging circuit design finished for remote. BQ25600 3A TI chip chosen. Actuator battery charging solution not yet selected. Trickle charger has been considered.
- Power management for remote is finished. LD1117 Linear regulator chosen to step down voltage from 3.7 to 3.3V. Efficiency analysis considered. Circuit designed via datasheet.
- Power management for actuator in progress. LTM4633 considered to step down voltage from 12V to add a 3.3V rail for peripherals including Teensy.
- A wireless module was selected.
- A microcontroller and development board was selected.
- Range Testing was completed
- Libraries for interfacing with the microcontroller hardware and wireless module were created. Both libraries need additional features to be added to be of use for the project.
- A working prototype of the wireless portion of the system was not created as the libraries were not brought to a state where this was possible.
- The code flow for communicating through the wireless module and and controlling the actuator was planned.
- Purchase test components
- Remote hardware selection and circuit design
- Updated CAD models to accurately represent internal capacity.
- Purchased testing and prototyping components
- Narrowed down remote hardware selections
- Met with Dr. Marshall for remote consultation
- Created and maintained BOM and purchased components
- Generated remote circuit diagram
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.
- In-line Load Cell - Placing a tension load cell rated to the estimated force of ~80 lbf in-line with the existing rear brake cable. Using an onboard DAQ system, real time force measurements would be taken during a variety of braking events.
- Pressure Sensor - Using a small piezoelectric pressure sensor placed between the brake pads, the clamping force could be determined. The system would not be able to measure during a brake application.
- Displacement Measurement - Measuring the displacement of the brake caliper would provide an estimate of force due to the cable/caliper spring constant being constant.
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.
LTM4633A LTM4633 10A switching regulator is being considered, with a boasted efficacy of ~92%.
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
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)
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.
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.
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
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).
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)
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)
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 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)
Bill of Material (BOM) (Justin)
Test Plans (Steven)
Risk Assessment (Steven)
Plans for next phase (Steven)
- Consult machine shop staff on manufacturability of mounting components
- Select material and suppliers
- Complete strength analysis on actuator mounting
- Include fail-safe mechanism on actuator tensioning
- Finalize cable attachments to caliper
- Finalize electronics enclosure mounting
- Prototype final remote housing
- Aid Gabriel with range testing
- Continue Alert Cluster circuit design and Prototyping
- Design preliminary wiring harness
- Work with Justin to breadboard remote
- Assist with adding software modules to Teensy and assist with testing.
- Detailed design of actuator circuitry and enclosure.
- Detailed design of wiring harness.
- Finalize actuator battery charging and power circuitry.
- Assist in remote hardware selection.
- Additional range testing with obstacles (e.g. trees, cars, etc.)
- Add functionality for and test Teensy to XBee communication over SPI
- Test Teensy to Teensy communication over XBee
- Finalize remote CAD concepts
- Select remaining remote hardware
- Continue to maintain BOM and purchasing document