Team Status Report

 

Team Status Report for 12/07

Significant Risks & Mitigation Plans

Our most significant risk is for our SLAM, which has misaligned frames, causing the walls in our map to overlap with themselves when our robot makes a direction change. Since our mapping is contingent on SLAM and our locomotion is also dependent on SLAM maps because we use LIDAR based odometry.

Risk Mitigation

Our SLAM module needs to be resolved for complete integration of our system, so we need to it to run successfully. We’ll look through SLAM libraries and debug thoroughly as a team of three to ensure we fix it.

Contingency

In a worst-case scenario, we would present the different components separately without SLAM, having to drive the robot manually or with preplanned maps (although this would incur significant drift).

Changes to the existing design of the system

No design changes were made.

Updated Schedule

Since our SLAM is delayed, the bulk of our testing is not able to be completed as of this week. We will attempt further testing in the days leading up to our final demo.

Progress & Accomplishments

Kevin presented our preliminary results in our final presentation. We successfully configured the Lidar to publish odometry data to the /odom topic in ROS2. This lays the groundwork for utilizing SLAM Toolbox and starting real-world room mapping. We also finalized  a web interface for simulation visualization that incorporates our completed algorthims.

Addendum

List all unit tests and overall system test carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.

  1. LiDAR slam accuracy – it becomes completely wrong after spinning
  2. Algorithm speed – Our current A* based algorithm is more than 30% faster than the basic DFS + Backtracking algorithm on our self designed rooms.
  3. Motors going in a straight line – successful
  4. Controller motors through ROS2 – successful
  5. Getting an accurate cost map that allows us to send navigation instructions to the Arduino – successful

Team Status Report for 11/30/24

Significant Risks & Mitigation Plans

Our most significant risk at the moment is the integration of all our ROS nodes, which are responsible for all the software components between mapping, pathing, and driving.

Risk Mitigation

We are working piece by piece to ensure correctness of all components. We are now checking robot motor control, which is critical to driving our robot along the path.

Contingency

If the robot is unable to drive with commands, in the worst-case we will be able to showcase our SLAM and path planning functionality by moving the robot around manually and showing our simulations.

Changes to the existing design of the system

No design changes were made.

Updated Schedule

Our schedule remains unchanged from the previous week.

Progress & Accomplishments

We prepared slides for our final presentation, which Kevin will be presenting next week. We got the robot to drive with keyboard inputs which are controlled by Arduino PWM signals. The robot is also capable of accepting vector commands which are created from our path planning algorithm. We’re making progress on mapping and localization by testing different SLAM packages and experimenting with ROS.

Addendum

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

We’ve become adept at using ROS2 for our Jetson Orin Nano and its many packages. One tool in particular we’ve familiarized with is the SLAM Toolbox. We’ve approached learning how to integrate SLAM Toolbox into our project in various ways, from reading tutorials online, to playing with the robot controls and the maps we generate, to writing accompanying ROS nodes that perform robot control that require SLAM Toolbox outputs. Through navigating the outputs and dependencies of SLAM Toolbox, we’ve acquired the knowledge to use it for our project.

Team Status Report for 11/16/24

1.What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

•Significant Risks: Current risks include ensuring seamless integration between Lidar mapping, path planning, and robot execution, as well as achieving accurate localization using Lidar. Additionally, testing the full system in dynamic environments presents challenges.

•Risk Management: We have focused on testing the robot’s ability to interpret and execute paths generated by the planning algorithms. For Lidar localization, we are comparing point cloud data to actual positions to refine accuracy.

•Contingency Plans: If localization accuracy falls short, we will adjust parameters or implement additional verification through odometry or sensor fusion.

2.Were any changes made to the existing design of the system? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

•No major changes were made this week, but we adjusted the workflow to prioritize testing the integration of path-planning commands with the robot. This slight shift in focus ensures we can validate core functionality early, avoiding delays in system testing.

3.Provide an updated schedule if changes have occurred.

•Updated Schedule:

•Week 10-11: Continue testing integration of mapping, path planning, and localization with real-world navigation.

•Week 11-12: Conduct validation tests for runtime, navigation accuracy, and collision avoidance.

4.Progress and Accomplishments

•Lidar Localization Testing: Began evaluating Lidar localization by comparing point cloud data to the robot’s actual position.

•Command Integration: Worked on sending usable navigation commands from path-planning to the robot.

•Visual Demo: Further developed visuals to highlight mapping and navigation functionality during testing and demonstrations.

5.Additional Question – Verification and Validation Update

•Verification (Subsystem Level):

•Mapping: Verified by overlaying generated maps onto room layouts and manually checking for accuracy.

•Path Planning: Tested by simulating dynamic obstacles and ensuring paths avoid collisions.

•Validation (System Level):

•Tests Run:

1.Navigation Test: Place the robot in a mapped room and validate that it follows planned paths to specified waypoints.

2.Localization Test: Compare Lidar-based position estimates with manual measurements for accuracy.

3.Runtime Test: Measure battery performance during navigation tasks.

•Analysis:

•Navigation success is assessed by measuring waypoint deviations.

•Localization accuracy is evaluated based on errors between estimated and actual positions.

•Runtime is compared to power calculations to ensure it meets expectations.

Team Status Report for 11/09/24

1.What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

•Significant Risks: One of the primary risks last week was ensuring the Lidar could map accurately in real-world environments and that the path-planning algorithms generated practical and efficient paths. Another risk was related to integrating the mapped data into a usable format for navigation.

•Risk Management: These risks were mitigated by testing real point cloud data and refining the mapping process. We also focused on improving the quality of the paths generated to ensure they met practical navigation needs.

•Contingency Plans: If Lidar mapping failed to meet precision requirements, we prepared to implement additional filtering and algorithm refinements. For path-planning challenges, manual adjustments to the parameters were used as a fallback.

2.Were any changes made to the existing design of the system? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

•No major changes were made to the overall design, but we refined the path-planning algorithms to provide more efficient and realistic navigation paths. These adjustments required additional time for testing but did not incur additional costs.

3.Provide an updated schedule if changes have occurred.

•The team is still on schedule, focusing on completing Lidar mapping, path-planning integration, and visualization elements for demonstrations.

4.Progress and Accomplishments

•Improved Mapping: Successfully tested real-world Lidar point cloud data to improve mapping accuracy.

•Path Planning: Refined algorithms to generate smoother and more efficient paths, critical for obstacle avoidance and navigation.

•Demo Preparation: Developed initial visualizations to showcase mapping and path planning for presentations.

Team Status Report for 11/02/24

1. Significant Risks & Mitigation Plans

The LIDAR model we’re using has a blind spot in it’s detection radius. The manufacturing spec claims that this radius is 5cm. Empirically, we realized that the 5cm is measured from the edge of the LIDAR (radius ~3.5cm), and not the center. Further, the blind spot radius is slightly over 8cm, giving a roughly 23cm diameter blind spot from the center of the LIDAR. This presents a significant challenge, because it creates situations where obstacles are occluded and come into view too soon for the robot to react, creating a collision. Totally by chance, our laser cutouts for the frame of the robot we finished this week has around an 11inch diameter – it’s the perfect size that keeps us able to detect everything outside the range of the robot.  Our mitigation plan also involves a design change, which will be covered in the following section.

2. Changes to the existing design of the system

Original Design – Why the Change?:

Originally, we planned to situation the LIDAR on the front edge of our robot to have an incidental angle to detect objects on the ground. However, without significant amount of tilt, greatly reducing the overall information obtained from the LIDAR, this no longer looks like a feasible solution.

Changes Planned:

We will move forward by modifying the robot design, likely putting the LIDAR in the center of the robot to completely mitigate its blind spot, and update our mapping algorithms to match.

Potential Further Concerns:

A concern with this approach is that small obstacles e.g. tiny boxes on the ground, might be invisible to our detection system. Our robot will still be able to perform its desired objectives of avoiding larger obstacles such as beds, desks, lamps, and sofas. If we want to mitigate the risk for smaller obstacles, we could make the robot robust enough to push light objects out of the way, or add additional sensing modules to avoid bumping into objects.

3. Updated Schedule

We are currently still on pace and not needing to change the schedule.

4. Progress Pics

 

 

 

 

 

 

 

Jetson working with LIDAR visualization and example excerpt from datastream logs

Laser Cutting!

header:
  stamp:
    sec: 1730583058
    nanosec: 349649947
  frame_id: laser_frame
angle_min: -3.1241390705108643
angle_max: 3.1415927410125732
angle_increment: 0.005806980188935995
time_increment: 0.0001358969893772155
scan_time: 0.1466328650712967
range_min: 0.15000000596046448
range_max: 12.0
ranges:
- 4.815999984741211
- 4.76800012588501
- 4.76800012588501
- 4.76800012588501
- 4.760000228881836
- 4.760000228881836
- 4.760000228881836
- 4.751999855041504
- 4.74399995803833
- 4.736000061035156
- 4.71999979019165

Team Status Report for 10/26/24

1. Significant Risks & Mitigation Plans

One foreseeable risk that could jeopardize the success of the project is the form factor of the robot could be too small. This would cause us to make the room map into too many grids to cover efficiently algorithmically. Since we haven’t laser cut our parts yet, we still have the chance to redesign the robot such that it suits our plans well enough. We’ll make the robot the same size as a normal Roomba as it will divide our chosen room size into good proportions for the planning algorithm. Real time adjustments will be an interesting problem to tackle next.

2. Changes to the existing design of the system

There are no major changes to the design of our system. However, contrary to what we discussed in our weekly meeting about the prioritization of coverage, we believe that a prioritization of speed might be more important. As long as our testing environment isn’t too complicated, 95% coverage should be very doable efficiently with an algorithm.

3. Updated Schedule

We are currently still on pace and not needing to change the schedule.

4. Cool Things

Visualization of a DFS + Backtracking coverage algorithm in a room with a table and a half wall!

Team Status Report for 10/20/24

  1. Significant Risks & Mitigation Plans

Risks:
One key risk remains sensor integration and synchronization with the Nvidia Jetson Orin Nano and ROS. Although we’ve installed ROS and begun practicing with the Lidar, ensuring smooth coordination between sensors, motors, and software remains critical for performance. Another ongoing concern is the delivery of motors, as delays could impact our assembly timeline.

Risk Management:
We are addressing integration risks by running early tests with ROS and the Lidar to work out any communication issues before assembly. This ensures the system is functional once all components arrive. For motor delivery, we are monitoring shipping timelines closely and have already prepared to proceed with chassis manufacturing at TechSpark as soon as the parts arrive.

Contingency Plans:
If sensor integration with ROS poses challenges, we will consult online documentation and seek support from our TA. For motor delays, we will begin assembling the chassis and testing smaller sub-systems to maintain progress. This ensures that once the motors arrive, we can quickly complete integration and proceed with full-system tests.

  1. Changes to Existing Design

Changes Made:
No major changes have been made to the system design since the last report. However, our testing process has shifted slightly, focusing more heavily on early integration with ROS to ensure compatibility between the Jetson Orin Nano, Lidar, and the motors once they arrive.Why the Change:
This adjustment allows us to proactively address potential software and communication challenges. By testing early, we can minimize unexpected issues during final assembly.Costs and Mitigation:
The shift to earlier ROS testing comes with minimal cost since we are working with the existing hardware. This approach reduces the chance of delays once all parts are assembled, helping us stay on schedule.

  1. Updated ScheduleWe are currently still on pace and not needing to change the schedule.
  2. Progress and Accomplishments

This week, we successfully installed ROS on the Nvidia Jetson Orin Nano and began testing with the Lidar sensor. We are awaiting the motors, but in the meantime, we plan to start manufacturing the chassis at TechSpark. Early software integration with ROS is progressing well, and once the motors arrive, we’ll proceed with full hardware assembly and testing.

How MapSweep Meets Specified Needs

Part A: Global Factors – Written by Nick Zhong

The MapSweep vacuum robot addresses global factors by contributing to automation in household and commercial cleaning, a trend that spans markets worldwide. As more industries and households adopt automated systems, demand for affordable and effective solutions like MapSweep grows. Our use of a 2D Lidar ensures that the robot is accessible and affordable across different markets, making it suitable for homes and businesses globally. Additionally, the robot’s efficient design helps reduce labor costs and supports sustainability, reflecting a global push toward smarter and energy-efficient technologies.

Part B: Cultural Factors – Written by Kevin Huang

Culturally, the MapSweep robot is designed to be accessible to a wide range of users, regardless of age or technical proficiency. The customizable interface allows users to select specific cleaning areas, supporting cultural norms around personal space and cleanliness that may vary across regions. By automating cleaning tasks, MapSweep helps reduce the labor burden on individuals, contributing to a shift in traditional household roles and promoting more equitable task sharing in diverse cultural contexts.

Part C: Environmental Factors – Written by Matthew Coyle

The MapSweep robot addresses environmental factors by reducing the need for harsh chemical cleaners through efficient dust and debris removal. Additionally, the robot’s low energy consumption, achieved through careful power optimization using the 12V 5200mAh battery, contributes to environmental sustainability. By minimizing collisions and optimizing navigation, the robot also extends the lifespan of household items, preventing unnecessary waste and supporting sustainable living practices.

Team Status Report for 10/5/24

Significant Risks & Mitigation Plans

Risks:
One of the primary risks facing MapSweep is sensor integration and data processing. While we are currently testing the 2D Lidar sensor, ensuring smooth integration with motor controls and real-time mapping algorithms remains crucial for the project’s success. Calibration issues or delays in processing data could lead to inaccurate navigation and obstacle avoidance, impacting the robot’s functionality. Another concern is power management, as the robot’s battery life must be sufficient to allow for extended operation.

Risk Management:
To mitigate these risks, we are performing extensive testing with the 2D Lidar sensor to fine-tune its performance and ensure precise mapping. Initial tests are promising, but further calibration will be needed to avoid collisions and optimize pathfinding. For power management, we are monitoring the system’s power consumption closely during testing and have built a buffer into our runtime estimates. The 12V 5200mAh battery is going to be tested under different load conditions to ensure it can meet the project’s runtime goals.

Contingency Plans:
If we encounter issues with the Lidar sensor during testing, we will consider adding auxiliary sensors such as ultrasonic or infrared to enhance environmental detection. For power, if the battery fails to meet our requirements, we have the option to upgrade to a higher-capacity battery or optimize energy usage by adjusting non-essential functions during operation.

Changes to Existing Design

Changes Made:
Since the last report, no significant changes have been made to the overall system design. However, we are currently testing the 2D Lidar, and the results may prompt minor adjustments to sensor placement and data processing algorithms to improve real-time performance.

Why the Change:
Our decision to continue with the 2D Lidar instead of 3D remains unchanged due to its cost-effectiveness and suitability for our design. Testing and calibration are ongoing, and no further changes to system components have been necessary at this time.

Costs and Mitigation:
The cost of testing and fine-tuning remains minimal as we are using the hardware components already purchased. Should additional sensors or power solutions be needed, we are still within budget to accommodate such changes.

Progress and Accomplishments

We have successfully received and tested the 2D Lidar sensor, and initial testing shows that it performs well in mapping room layouts and detecting obstacles. This week, we also refined the CAD model, preparing it for production at TechSpark. Additionally, we have finalized the Bill of Materials (BOM), which includes the Nvidia Jetson Orin Nano, the 12V 5200mAh battery, and other critical components. Once the remaining parts arrive, we will move forward with assembly and integration.

Team Status Report for Sep 28, 2024

Significant Risks & Mitigation Plans

Risks: One of the most significant risks for MapSweep is sensor integration and real-time data processing. The lidar sensor must work in sync with the motor controls and mapping algorithms for accurate navigation. If there are issues with sensor calibration or data lag, the robot may struggle to avoid obstacles effectively, leading to potential failure in performance. Another risk is battery life, as the robot needs to operate for extended periods without frequent charging, and miscalculation in power consumption could lead to operational inefficiency.

Risk Management: To manage these risks, we’ve allocated additional time for testing the lidar system in various simulated environments. By running early-stage simulations, we are able to fine-tune the sensor calibration and assess performance before integrating it into the physical robot. For power consumption, we are running energy efficiency calculations based on motor requirements and operational hours to adjust the power system accordingly.

Contingency Plans: In case of major issues with the 2D lidar, a backup plan would involve using additional sensors such as infrared or ultrasonic sensors for enhanced environmental awareness. If the battery life becomes a problem, we have considered swapping to higher-capacity batteries or adjusting operational power usage to prioritize essential functions.

2. Changes to Existing Design

Changes Made: One of the key changes we made was switching from a 3D lidar system to a more affordable 2D lidar system. After reviewing the cost-benefit ratio, we realized that 3D lidar wasn’t necessary for our requirements, as vertical mapping wasn’t a critical factor in detecting obstacles for a floor-level cleaning robot.

Why the Change: This change was necessary to keep the project within budget while still ensuring high performance. Additionally, since the robot doesn’t need to map ceilings or other vertical features, the 2D lidar provides enough information for precise navigation and object detection. The design change simplifies the system and reduces computational load, freeing up resources for other critical tasks such as path planning and motor control.

Costs and Mitigation: The cost saved by switching to 2D lidar has been reallocated to improving other components, such as enhancing the robot’s battery capacity and investing in higher-quality motors. This cost shift has been mitigated by thorough research into sensor capabilities, ensuring that the selected 2D lidar provides the necessary functionality for our project.

Progress & Accomplishments

We are proud to report the arrival of our Nvidia Jetson Orin Nano, which will serve as the brain of our robot. Additionally, after several rounds of simulation, we have successfully modeled the 2D lidar sensor in different room configurations, validating its performance.

Part A: Public Health, Safety, and Welfare: Kevin Huang

The MapSweep vacuum robot enhances both public health and safety by maintaining clean, debris-free floors, which is essential for reducing dust, allergens, and potential pathogens in living and working environments. This contributes to a healthier environment, especially for individuals with respiratory issues. From a safety perspective, the robot is designed with robust obstacle detection and avoidance capabilities to minimize accidents, such as collisions with furniture or people, preventing potential injury or property damage. By using lidar for precise navigation, the robot ensures it can operate safely in dynamic environments without posing hazards. Moreover, its autonomous operation frees users from manually cleaning, improving their overall well-being and quality of life.

Part B: Social Factors: Nick Zhong

The MapSweep robot also considers social factors by ensuring accessibility and ease of use for a wide range of users. Whether in homes, offices, or public spaces, it can cater to diverse social groups, offering a user-friendly interface and customizable settings to accommodate different cleaning needs. The robot promotes equality in tasks like cleaning, which is traditionally associated with manual labor, potentially reducing the division of household chores. Additionally, it supports people who might face physical challenges, providing a convenient and efficient cleaning solution, and improving their standard of living and sense of autonomy.

Part C: Economic Factors: Matthew Coyle

From an economic standpoint, the MapSweep vacuum robot aims to provide a cost-effective solution by balancing performance with affordability. By opting for a 2D lidar system instead of the more expensive 3D lidar, the project significantly reduces hardware costs while still delivering high precision and functionality. This makes the product more accessible to a broader market. Additionally, the robot’s autonomous operation could reduce the need for hired cleaning services in some settings, offering long-term savings to both residential and commercial users. Its energy-efficient design and potential for easy maintenance also contribute to lowering operational costs, making it a sustainable investment.

Team Status Report for Sep 22, 2024

The most significant risks that could jeopardize the success of the project would be the uncertainty of the quality of the 3D LiDAR. We have explored the space of lidars and found that most high quality 3D LiDARs tend to be on the more expensive side of things (usually up to a couple thousand dollars), and the one that we are looking at right now is $349. We have downloaded some sample point cloud data from this LiDAR and are playing around with it to see if we can create a mapping of the room. We’re also prepared to use a $99 dollar 2D LiDAR with IMUs if the 3D LiDAR does not end up working.

There were not that many existing changes to the system that we have planned. We’ve fleshed out the concept a little more and have order the jetson nano. We’re on our way to start the project.