Posted on

Sean Johnson Status Report April 25

What I Personally Accomplished This Week

This week I focused on finalizing the navigation system for our demo. I debugged remaining map stability issues to minimize drift during extended navigation sessions. I also worked with the team to plan the logistics of our final demonstration, including defining the test environment layout, determining demo scenario sequences, and identifying what equipment we’ll need for the 15×15 foot test area. Additionally, I contributed to developing content for the final poster.

Progress Status

Progress is on track. All deliverables are progressing as planned for final submission.

Deliverables for Next Week 

Next week I will complete the final poster with all navigation system content and test results. We will conduct the final demonstration. All project components will be complete and ready for final submission.

Posted on

Team status report for 4/25/26

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.

 

Unit and System Testing

This week, testing focused on validating the navigation stack across multiple environments and durations. For mapping, the team ran Cartographer SLAM across several different room configurations to evaluate map quality and consistency. Output maps were reviewed for accuracy in both open spaces and constrained corridors, with attention to how well scan-matched features held up as the robot traversed room boundaries. Navigation endurance tests were also conducted at varying durations  1, 10, and 15 minute runs to observe how localization and path tracking degraded over time and whether any systematic drift or replanning failures emerged during longer operation.

Design Changes from Test Results

Analysis of the navigation test runs revealed that the previous controller, Regulated Pure Pursuit (FollowPath/RPP), exhibited goal convergence issues near the destination, where the robot would oscillate and fail to settle cleanly. In response, the local controller was migrated from RPP to the Dynamic Window Approach (DWB) planner within Nav2. DWB samples a set of candidate trajectories at each control cycle and scores them across multiple critics including path alignment, goal heading, and obstacle clearance, giving the controller more flexibility for clean stopping and heading recovery. Critic weights were tuned to make the controller more aggressive in correcting heading error, which reduced the oscillation behavior observed during testing.

Separately, odometry performance was identified as a contributing factor to map drift during longer runs. The SparkFun OTOS sensor exposes linear and angular scalar calibration parameters that were adjusted based on measured ground truth. The linear scalar was tuned by driving a known tape-measured distance and comparing against OTOS-reported displacement, and the angular scalar was tuned by commanding a full 360-degree rotation and verifying heading return to within tolerance. Tightening these scalars reduced odometry drift and improved Cartographer’s pose estimate stability during extended navigation runs.

Planned Future Testing

The next phase of system testing will focus on end-to-end delivery runs using a pre-saved map of the target environment. The plan is to define a waypoint sequence in Nav2 that represents a realistic delivery mission: starting from a home position, navigating to a pickup location, proceeding to a delivery destination, and returning back to the origin. This will exercise the full autonomy stack in a mission-relevant context rather than isolated navigation trials. Key metrics to evaluate during these runs include total mission completion time, localization consistency across the full route, and how reliably the robot reaches and confirms each waypoint before proceeding. Any failures in goal convergence, replanning, or behavioral FSM state transitions triggered by the KR260 person detections during the run will be logged and used to drive further tuning of the DWB critic weights and Nav2 parameters.

Posted on

Paul Wright’s status report for 4/25/26

What I personally accomplished this week:

I worked with justin and sean on navigation. To avoid reiteration, see their posts. I also looked into how we would actually set up our final test enviornment. We are hoping we get a 10×15 area, but will probably get a 10×10 area. Carboard boxes are fine, but we will need a ton of them, they will move pretty easily and their width will cut down on their effective area. Cardboard sheets have a lower profile, but will also move easily. What I am thinking of doing is just going down to techspark and getting wooden board to cut as walls. I can then make some triangle mounts to drill in to the boards, giving us a low profile and being sturdy. Regardless, our walls need to be 16 inches tall at the minimum.

Progress relative to schedule:

We are on schedule aside from running detection.

Deliverables for our final week:

Finish our final demo plans and rehearse

make the video

make the poster

construct the test area

Posted on

Justin Bell Status Report 4/25/2026

This week I switched the Nav2 local controller from Regulated Pure Pursuit (RPP) to the Dynamic Window Approach (DWB) controller. RPP had been working but showed consistent issues near the goal, the robot would oscillate and fail to converge when it got close, partly because RPP computes a single curvature command along the path and doesn’t sample the velocity space dynamically. DWB samples a set of trajectory candidates at each control cycle, scoring them against a set of critics (path alignment, goal heading, obstacle clearance, etc.), which gives it more flexibility for stopping cleanly and recovering from heading errors.

The SparkFun OTOS node publishes in inches internally and converts to meters with the * 0.0254 factor on both linear.x and linear.y. The main tuning work this week was on the linear and angular scalar calibration exposed by the OTOS firmware.

To tune these, I drove the robot a known distance (measured by tape) and compared against the OTOS-reported displacement, then adjusted the scalar proportionally. Same process for angular: rotate a full 360 degrees and check that the heading returns to within a degree or two of zero. These scalars live in the otos_odom_node.py startup block just after calibrateImu().

Posted on

Justin Bell Status Report 4/18/2026

This week I spent a good amount of time working on the odometry sensor. It was reading about 90 degrees off from where it should have been, which was causing some issues with how the robot understood its own orientation. I went through the recalibration process to get it lined up correctly so that the heading data coming from the sensor actually matched the real world. Once that was sorted out, I also worked on calibrating the motors. The drive behavior was not quite where it needed to be, so I made some adjustments to get the left and right motors responding more consistently and accurately to velocity commands.

On top of that, I made some changes to the local costmap configuration. Specifically, I increased the inflation radius so that obstacles get bigger bubbles around them during path planning. This should help the robot keep a safer distance from walls and objects instead of trying to squeeze through tight gaps. I also took some time this week to test out the pan tilt system, running it through its range of motion and making sure it was tracking and responding properly. Overall it was a productive week focused on tightening up a lot of the core subsystems on the robot.

A lot of what I have been learning this semester has come from a mix of self teaching and prior experience. For the SLAM side of things, I learned how to use Google Cartographer by watching videos and reading articles online, working through tutorials and documentation to understand how it processes lidar data and builds occupancy grid maps. It took some time to get comfortable with how all the parameters and configuration files work together, but the online resources were really helpful in getting me up to speed. On the FPGA side, a lot of that knowledge came from a previous internship where I got hands on experience working with FPGA development tools and hardware design workflows. That background has been really valuable for this project, especially when it comes to working with the Kria board and understanding how to integrate hardware accelerated components into the overall system.

Posted on

Sean Johnson’s Status Report for 4/18

What I Personally Accomplished This Week

This week I focused on fine tuning navigation system parameters to improve performance and reliability. I adjusted multiple Nav2 configuration values including obstacle inflation radius in the costmap, local and global path planning refresh rates, and motion filter parameters in Cartographer. I also calibrated motor duty cycle trims to compensate for asymmetry at different speeds, ensuring consistent velocity control across the operating range.

I debugged a critical coordinate frame issue in the OTOS odometry publisher where the sensor’s 90-degree mounting orientation caused X and Y position data to be swapped.I identified and corrected the issue by swapping the X/Y assignments in the odometry publisher code. I also adjusted covariance values to balance trust between odometry and LiDAR scan matching.

I conducted navigation testing including timed distance runs to verify velocity accuracy, localization tests to measure position error, and extended SLAM sessions to check map stability. I also created the final presentation PowerPoint.

Progress Status

Progress is on track with the project timeline. The navigation subsystem is functional with ongoing parameter optimization. 

Deliverables for Next Week 

Next week I will finalize navigation parameter tuning to minimize drift and improve path following accuracy. We will conduct integrated system tests combining computer vision detection outputs with navigation costmap updates to validate human aware path planning. I will also perform the remaining real-world integration tests with team members simulating various scenarios (fallen person obstacle, running detection, multi-person navigation).

New Tools and Knowledge Acquired

Throughout this project, I needed to learn several new tools and frameworks. The most significant was the ROS2 navigation stack, including Cartographer SLAM for mapping and Nav2 for path planning. I had no prior experience with SLAM algorithms or costmap based navigation, so understanding how to configure occupancy grids, inflation layers, and path planners required substantial learning through online guides and youtubes.

I also relied heavily on trial and error testing. For example, tuning the odometry covariance values required running multiple SLAM sessions, observing drift patterns, then systematically adjusting values and re-testing. When debugging, I used a systematic experimental approach: I would make a hypothesis, design a quick test, observe the result, then iterate. This strategy was more effective than randomly trying solutions. I also searched GitHub issues and ROS Answers forums when encountering specific errors, which often provided insights from others who solved similar problems. 

This project also required working with the Raspberry Pi 5 beyond what I have done in the past. More significantly, this was my first experience integrating a large multi-subsystem. Issues could stem from hardware connections, software interfaces, or coordinate transformations. I learned to use isolation testing and found importance in clear interface definitions between modules developed by different team members.

Posted on

Team status report for 4/18/26

Most significant risks: We feel pretty good about our progress on mapping and navigation. It has improved significantly in the last 2 weeks. Now, we need to properly implement running detection and make a physical test environment.

Changes to the system: We realized that our odometry sensor was rotated 90 degrees off of where it should be, which contributed to our general navigation issues. Thankfully, correcting this was simple. We flipped X and Y and then negated X. Something else that we worked on was changing the size of obstacles seen on the cost map and adjusting the robot size to have better navigation control. We also created new maps that were cleaner that better represented areas that the robot would be navigating in. We Also, tested the pan tilt for 3 directions fully as well.

We also printed a cable shroud to attach to the back of the robot. This does not accomplish anything functional, and is really just there to look nicer.

 

No changes in our schedule have occurred.

Posted on

Paul Wright status report for 4/18/26

What I personally accomplished this week:

This week, I worked with Justin and Sean on the final presentation as well as some minor work on navigation. I did not do as much with them as I had hoped because 18447 has required much more time than expected. I also designed and printed a cable shroud alongside the bucket mentioned in previous posts. During the work on the presentation, we also discussed new validation tests because old ones from our design report were no longer particularly relevant.

 

Progress relative to schedule:

We are on schedule.

 

Deliverables for next week:

Work on navigation and the final assignments with Justin and Sean.

 

Extra portion:

 

There were multiple topics on this project that I knew little about before this project, such as computer vision, ROS, navigation and using FPGAs beyond synthesis in 18240. To actually implement anything on this project, I needed to learn more about these topics on a conceptual level. Frankly, youtube tutorials/project showcases and my project partners have been some of my best resources. After reading more formally on these topics, watching someone actually use those concepts and the interfaces associated with software helped to get a better understanding of how I could do it. My partners were especially influential on my learning during that introductory stage because they offered rapid feedback and answers to my questions.

Posted on

Team status report for 4/4/26

Most significant risks: Currently, our navigation can be a bit buggy depending on the area that we have mapped. We have also experienced great variance in the quality of the mapping process in HH 1307 and just outside of it. We believe that this is due to the amount of glass (which lidar struggles with) and the density of small objects. We want to try testing in “simpler” areas for the lidar like Wean 4th floor.

No changes to the design of the system have been made. We are in the endgame, so navigation is what needs to be solved

No changes to the schedule have been made

Validation:

Verification tests were discussed in the individual reports. Once mapping and basic navigation are improved sufficiently, We plan to start mapping larger areas like an entire corridor on the 4th floor of wean or the physics area there.  With larger areas, we can better test the robot’s ability to avoid people and crowds, which will signify meeting our use case requirements. To test those abilities, we plan to give it a longer route (25-40m), and first see if it can properly navigate there without moving obstacles. We then plan to use ourselves as moving obstacles along the path on future runs to see how it reacts.

Posted on

Paul Wright status report for 4/4/26

What I personally accomplished this week:

This week I worked with Justin and Sean on refinement of our nvaigation, demo,  and integrating some reprinted parts, as we encountered navigation and structual integrity issues on sunday night.

Progress Status:

I have not printed the new storage attachment yet, but I am also not really worried about that, as it would not affect any of the functionality of the rest of the system. For the parts of the system that matter, we are on track.

Deliverables for next week:

Print the storage attachment

Continue to work on navigation and the final demo with Justin and Sean

Verification:

Sean and I performed verification testing for Physical movement/battery runtime. For physical movement, we ran basic movement scripts for moving/turning at different speeds and verified that we could go a desired speed. For example, if we wanted to go ~0.15m/s for mapping, we would need to have our left and right motor duty cycles at 18 and 21 respectivley. For our desired speed of 1m/s, the motors no longer had to be run at different speeds, as we were now in the standard duty cycle operating range for the motors (41-91), meaning that we can move properly. For the battery testing, we  just charged the battery and had the system run everything while doing loops at ~1m/s.  We could do this for over 45 minutes repeatedly, so we well exceeded our goal of a 30 minute runtime. Movement and power working properly means that we can properly direct the robot, so our constraint becomes giving the proper directions through navigation, not following them.

More testing was done as a group of 3, so see Justin’s report for that.