Our most major risk is being behind on physical movement, which delays our physical tests and integration of computer vision/localization and movement systems.
We did not receive the correct batteries that we had ordered. They had the capacity we need, but with a maximum continuous current of 3A compared to the 6A that was specified. This would make the batteries unable to handle the surge in current draw from our motors during stalling or startup, which presents a serious physical safety risk. We have already addressed this by adjusting our testing and procuring a different battery and power delivery system that should fit our needs. Portions of physical controls testing were done by using power supplies on campus, which allows for us to test basics such as starting, speed controls and stopping. Given the inability to do a large portion of movement testing, Paul has been temporarily reassigned to assist Justin and Sean. Until the new parts arrive, we have been using the most advanced of testing for our Lidar and computer vision: dragging the chassis with a wire:
This week the majority of work focused on the software navigation stack running on the Raspberry Pi 5. The goal was to get from a bare ROS2 Jazzy install to a fully functional autonomous navigation system with human interaction protocols, and most of that was achieved by the end of week with hardware integration remaining.
SLAM and TF Tree Debugging
The first major thing was getting GoogleCartographer working with the RPLiDAR A1 on ROS2 Jazzy. TF tree configuration required significant debugging. Cartographer needs a specific chain of coordinate transforms to function: map -> odom -> base_link -> laser_frame. Each of these transforms has to come from a specific source, and if any of them are missing or have timestamp issues, Cartographer silently drops all incoming laser scans and produces no map.
The first issue was that the LaserScan messages were being dropped by the ROS2 MessageFilter before they even reached Cartographer. This happens when the transform from the scan frame to the fixed frame does not exist at the timestamp of the scan message. The fix was ensuring robot_state_publisher was running with the correct URDF describing the static joint between base_link and laser_frame, so that transform was always available.
The second issue was t/*-he robot_state_publisher was broadcasting the base_link to laser_frame transform with timestamps that were 507 seconds in the past, derived from stale joint state messages. Cartographer would reject any transform older than a few seconds, so even though the transform existed it was effectively invisible. This was fixed by setting ignore_timestamp: True in robot_state_publisher’s parameters, forcing it to always publish with the current time regardless of the joint state timestamp.
The third issue came after integrating the OTOS odometry node. Cartographer has a parameter called published_frame which controls what frame it publishes its pose estimate into. When odometry is enabled, this must be set to odom, not base_link. Setting it to base_link caused Cartographer to publish a map->base_link transform at the same time the OTOS node was publishing an odom->base_link transform, creating a direct conflict in the TF tree that made the robot’s position undefined. Once published_frame was correctly set to odom the two systems no longer conflicted.
OTOS Odometry Integration
The PAA5160E1 is an optical flow sensor combined with an IMU that tracks the robot’s position and orientation by watching the floor surface, similar to how an optical mouse works. Integrating it into ROS2 required writing a custom node that reads from the sensor over I2C, converts the native units (inches and degrees) to ROS standard units (meters and radians), and publishes both a nav_msgs/Odometry message on the /odom topic and a TF broadcast of the odom->base_link transform. A few things mattered a lot for stability. The QoS profile for the odometry publisher needed to be set to BEST_EFFORT to match what Cartographer expects on its odometry subscriber, using RELIABLE caused messages to be silently dropped. The publishing rate also needed to be as high as possible, so the node uses a tight while loop rather than a ROS2 timer, which gave more consistent TF timestamp continuity and reduced Cartographer’s transform lookup failures.
The OTOS is sensitive to mounting. During early testing the sensor was held by hand while moving around the room and the resulting maps were unusable, every small vibration or tilt registered as robot movement, causing Cartographer to accumulate errors rapidly and produce false loop closures where the map would suddenly jump to a completely wrong position. Mounting it firmly on a flat surface dramatically improved map quality.
Motor Controller
The motor controller node was written for the two Pololu VNH5019 H-bridge motor driver boards that will drive the Hiwonder DC motors in a differential drive configuration. This is entirely WIP until we get the actual motor drivers.
Design changes:
Due to the aformentioned battery issue, we have transitioned to a different power delivery system based on what we were able to quikcly procure. Our new battery is a bienno 12afaf, which is a 12V battery with a 20A max continuous current. This also requires new equipment such as a power delivery block and adapters for the powerpole system.
Part A: Written by Paul Wright
Hospitals are well-known for their huge cost struggles and that need high uptime on equipment. With the prohibitive cost of healthcare, an expensive product can decrease the total amount of care provided if it drives up cost more than the benefit it offers. Our product solution addresses this through a low cost and the use of available, off-the-shelf parts. These parts have large amounts of publicly available documentation and open-source projects that use them, allowing for easier repairability and modification. A decrease in the need for a specialist is of special benefit to rural or disconnected areas, as they face a greater time and monetary penalty than urban centers when they use them. Every minute that a device is not working when expected harms people by affecting logistics and lowering the standard of care. Any device with moving parts will inevitably need maintenance and/or repair, so making it more accessible should increase uptime and reduce costs.
Hospital populations are generally under high stress and have a large variation in the physical condition of patients. For any high-stress environment, assistive products should allay concerns, not introduce new ones. Our product solution avoids becoming a new source of stress through proper detection of people and avoiding them. To properly understand what it needs to avoid, the robot needs to be able to properly distinguish between soft (movable) and hard (nonmoving) obstacles and know where it is. Classification of obstacles is achieved through proper tuning of mapping parameters, while localization uses both lidar and odometry to more accurately find it’s location even with rapid changes in the environment. Ultimately, patients and employees should not have to concern themselves with the vehicle.
Part B: Cultural Factors, by Sean
Our autonomous hospital delivery robot is designed with careful consideration of the cultural factors important to healthcare environments. Hospital culture places paramount importance on patient safety, dignity, and privacy, which directly influences our design decisions. The emergency detection protocols of fall detection and running detection reflect the cultural values of healthcare institutions where staff are expected to immediately respond to patient emergencies. Our behavioral finite state machine implements culturally appropriate responses such as stopping and alerting staff rather than attempting autonomous intervention, respecting the cultural norm that medical emergencies require human healthcare professional judgment. Additionally, hospitals have behavioral codes and regulations including HIPAA privacy requirements, which our system respects by not storing or transmitting images, only processing them in real time for detection. Also, cultural acceptance of autonomous robots varies significantly across patient populations, like how elderly patients may be less comfortable with robotic systems. Our design addresses this by ensuring the robot operates predictably, maintaining appropriate clearance distances from all individuals.
Part C: Environmental Factors, by Justin
Our delivery robot addresses environmental factors through energy efficient design and sustainable operational practices. By utilizing rechargeable lithium ion batteries rather than disposable power sources, the system minimizes battery waste. The robot’s energy consumption is optimized through efficient path planning algorithms that minimize unnecessary travel distance, and the 0.5 m/s maximum velocity specification balances delivery efficiency with power consumption. Our component selection prioritizes longevity and repairability with a modular design and off the shelf components (Raspberry Pi, RPLidar, motors) that allows for individual component replacement. This approach reduces electronic waste compared to proprietary integrated systems. Acoustic pollution is minimized through quiet motor operation and scarce use of audio alerts only during emergency conditions. While the manufacturing of electronic components has environmental costs, the system’s ability to potentially operate continuously for years with minimal maintenance provides a net environmental benefit over its lifecycle.
