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.
- Bike side PCB design
- Select supplier
- PID prototype for precise motor control
- Remote casing
- Button design/prototype
- Fabricate main actuator mounting plate
- Contact Pam about future use of bike
- Troubleshooting screen
- Xbee testing on the PCB
- Information packet design
- 3D print remote casing
- Basic (teensyduino) sketch of speed sensor
- Finish PWM module in Rust
- Voltage level sensing circuit
- Actuator frame mounts
- Source outside vender for actuator mounting plate
- Integrate sliding mechanism onto test mounting plate
- PCB Completed**
- Charging tested w/ battery
- User inputs functioning
- Test remote casing and faceplate complete w/ buttons
- PCB design complete and ordered
- Obtained tricycle
- Speed sensor functionality
- Further Teensy PWM function integration
- XBee library tested on PCB
- Actuator control tuning
- Actuator calibration procedure
- Completed base functional prototype
- Xbee communication on PCB demo
- Actuator clamp sliding mechanism
- Remote casing/buttons
Technical Paper Sections
- Actuator and controller selection
- Remote PCB design
- Harness design
- Braking force feasibility/validation testing
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.
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.
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.
These new revisions turned out well in the initial print.
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.
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
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.
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:
- E-stop : Fully brake.
- Overspeed : Brake the bike as necessary to lower the speed to a safe value.
- Slider : Move to position related to the position of the slider.
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.
Packet CommunicationUsing 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 InitializationThe 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 BugsThe 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.
StevenThis 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.
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.
Machining Actuator Components
- Components Completed
- Main Actuator Mounting Plate
- Brake Cable Housing Mount
- Frame Clamps
- Actuator Clamp Plate
- Slider Modifications
- Prototype Remote Buttons
Bike Electronics EnclosureWorking 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.
With the components all laid out inside the box, final work can begin on installing wire grommets and the power switch.
Remote RevisionsAs 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 EnclosureTo prepare the final prototype, the bike enclosure was mounted onto the bike using existing frame mounts.
Plans for next phase
- Finalize remote
- Select final enclosure hardware
- Maintain budget and purchasing
- Finalize wiring harness
- Mount final electrical components like hall effect sensor
- Work with team to create poster and report
- Fabricate actuator mount
- Finalize brake cable routing
- Integrate actuator brake cable into existing system
- Complete modifications to bike enclosure
- Facilitate system level testing
- Develop functioning actuator initialization algorithm
- Integrate previously tested screen functionality into remote system
- Integrate alert mechanisms for both bike and remote
- Integrate speedometer functionality into bike system
- Integrate battery level sensing for both bike and remote
- Work with Gabe for bike battery level sensing integration.
- Assist with integration of alert on bike.
- Finalize wiring harness.
- Assist with poster creation.