Preliminary Detailed Design
Table of Contents
Team Vision for Preliminary Detailed Design Phase
- Continue research of LIDAR localization implementation
- Plan odometry updates
- Begin design and prototype of path planning algorithms
- Evaluate current obstacle avoidance performance
- Research new GUI monitor
- Draft sketches of new GUI
- Design brake switch
- Update risk register
- Create a Bill of Materials
Prototyping, Engineering Analysis, Simulation
Brake Switch Upgrades
- This switch will determine when the brake pedal has been depressed by a driver.
- A proximity sensor mounted directly behind the linkage bracket will require minimal manufacturing and allows adjustment.
- We have already tested this proximity sensor with the odometry prototyping.
- I have used CAD to model what this would look like.
- I plan to implement this next semester during the build phases.
RTK GPS LocalizationWe have have decided not to use an RTK GPS since the benefits it offers does not fit the final goal of this project. In order to obtain an RTK lock, GPS's require clear skies 30 degrees and up from the ground on all sides. This is not practical for the canyon-like area that is the RIT campus. Even if the GPS was able to get a consistent lock on campus, delivering a person in front of building would cause an immediate loss in the RTK lock. There is also a wait time associated with gaining that RTK lock. Depending on the GPS, it can take between 5 and 15 minutes get to the RTK state. The final aspects considered was development time and cost. Getting our current RTK GPS to work will require a vast amount of effort for almost no gain. Alternatively, if we wanted to purchase a GPS that would be working quickly, it would cost us almost $1000. With all of this information, we have decided that it is not worth the pursuit of a working RTK GPS.
SLAM (Simultaneous Localization and Mapping)
- We have implemented a stock SLAM package.
- First test
- Initial mapping in an area with obstacles was good.
- As we moved to different locations outside of the map SLAM mapped incorrectly due to error in odometry.
- We realized there was no parallel scan.
- The first test revealed that we needed a better
odometry solution. Some options are:
- Use the LIDAR to produce odometry.
- Update current encoder odometry.
- Improve the algorithm for the IMU.
Odometry from LIDAR
- Alternative method to capture odometry directly from LIDAR.
- Almost done implementing a package (laser scan
matching) to accomplish this.
- Most of the code has been written, testing is not yet complete.
- Once we are confident the odometry is working properly, we will test it with SLAM and see how well we localize.
Odometry Encoder Upgrades
- Factors driving change to the odometry system:
- Mechanical slop in the steering system causing inaccuracy in the measurement of the steering angle.
- Linear model of the non-linear steering system.
- The rear differential adds a source of noise and error that is not well understood and quantified.
- Feasibility, Analysis and Prototyping
- Initially inspiration was taken from the automotive industry using proximity sensors.
- We would like to add encoders to the rear wheels.
- Datasheet spaced teeth that were ~1cm apart mentioning that finer resolution may work with testing.
- A prototype was designed to test an effective tooth pitch of 100 teeth per revolution.
- The prototype proved that only 50 teeth would be feasible on the actual wheel dimension.
- The current plan is a digital hall effect sensor that
will pick up magnets mounted to the inside edge rim of
the rear wheels.
- 200 magnets around the rim is mechanically feasible using a milled or laser cut ring to affix and locate them.
- The design will protect against a lack of resolution by leaving space for more sensors to be affixed.
- 2 sensors provide 4 states per one magnetic cycle and 4 sensors provide 8 boosting the number states per wheel revolution to 200 and 400 worst case.
- This is not a specific customer requirement nor engineering requirement, but should be done to mitigate the risk of an electrical short.
- Consideration has been made for an implementation of a fuse box on the front of the car for protection. There is a particular 12 V line that is powering the Lidar sensor, display, indicator light, etc. The 12 V line goes into a connector which spreads the voltage between the various devices.
- The plan is to replace this connector with a fuse box to provide more protection for the expensive devices like the LIDAR, and monitor.
- Click here to see a fuse box.
- Furthermore, the power to the wicked steering, and braking should have a dedicated fuse on them as well.
- At the front of the cart, all the grounding is attached to a bolt through which, through a general ground wire, is connected to the chassis ground. While this has not posed an issue so far, we are considering replacing with a ground terminal.
- There is also an issue where if the cart takes an e-stop command, the cart's computer system reboots itself. We believe that the motor driver is driving in so much current from the 48 V battery, for an unconfirmed reason, that the buck converter does not have enough to function, and thus shutting off the system momentarily. If this was proven to be true, through testing, a fix can be made by putting a capacitor, and a bleed resistor in parallel at the input of the buck converter.
- This version of the GUI shows all essential information including LIDAR, GPS, and Speed. In addition, it gives all needed input selection, including destination locations and control type. The downsides are that the UI is crowded, and can be overwhelming at a quick glance.
- This version of the GUI separates the destination selection from the actual UI using a physical device to select destinations. It allows the UI to show more information, or show current information more visibly as shown above. In addition, there would be no need for users to interact with the computer outside of one simple device.
- This version of the GUI strips away all unneeded visuals, leaving only the basic selections needed for use. This can be used if simplicity is needed over showing visual data. Users will not be overwhelmed with attempting to decipher the UI, and instead will easily be able to select their destination and get going. The only downside is that the interesting information from the differing sensors will not be shown.
- Create and add functionality to modules
- Link modules to necessary data inputs
- Create method for opening GUI with all modules loaded in automatically
- The current display monitor, while compact and efficient, does not display data in a readable fashion when viewed in direct sunlight.
Here is a list of possible replacement monitors:here.
- Decide on a monitor to order
- Gather funding
- Contact manufacturer and place order
- Updated list of engineering requirements.
- A data sheet has been created to begin to compile the performance metrics of the APM.
- These metrics will be updated overtime and will be tested for as time permits.
Plans for next phase
Click here to download the full project plan document.