Michael Meidinger, M.Sc.

As systems-on-chip (SoCs) consist of increasing numbers of processing elements, be it separate CPU cores in traditional SoCs or distinct processing dies in chiplet-based architectures, the requirements for transmission bandwidth between these and other system elements keep rising. While this can be achieved by scaling the transfer rate and the number of parallel transmission lanes, see, for example, the evolution over PCIe's generations, area and power consumption for the interconnect are rising as well.

Another approach to manage the interconnect load is to reduce the amount of data to transfer in the first place. Besides optimizing the system architecture and applications to require fewer transfers between system components, on-the-fly data compression can be used in systems where area and power consumption are more critical than transmission latency. After data is generated or given as input, it can be compressed before transmitting it over particularly longer-distance links. It can be either decompressed or used as is on the receiving end, depending on the application and the destination element. Example use cases are compressing sensor values or camera images before being processed or stored in memory on the other side of the link or compressing (sparse) matrices into a certain format to be processed by AI applications.

Many algorithms for lossless data compression exist. Those focusing on compression and/or decompression speed instead of compression ratio are more relevant for a system as described. A potential candidate could be the Lempel-Ziv 4 algorithm. This seminar work should investigate the viability of this and other lossless compression algorithms, how data should be structured for efficient operation, and what applications could especially benefit from this approach compared to more classical methods to handle high interconnect bandwidth requirements. Further literature research could look into hardware implementations of the considered algorithms.

Potential starting points could be the following papers:
https://ieeexplore.ieee.org/abstract/document/1549812
https://ieeexplore.ieee.org/abstract/document/7818601
https://koreascience.kr/article/JAKO201313660603091.page
https://cdn.zeropoint-tech.com/f/174713/x/2ef77c7d31/ziptilion-memorycompression-
ip-zeropoint-technology-whitepaper-2023-10-18-ver-2-6.pdf

At LIS, we leverage the Duckietown hardware and software ecosystem to experiment with our reinforcement learning (RL) agents, known as learning classifier tables (LCTs), as part of the Duckiebot control system. More information on Duckietown can be found here.

In previous work, we developed a tool called DuckieVisualizer to monitor our Duckiebots, evaluate their driving performance, and visualize and interact with the actively learning RL agents.

This student assistant position will involve extending the tool and its respective interfaces on the robot side by further features, e.g., more complex learning algorithms or driving statistics. The underlying camera processing program should also be ported from Matlab to a faster programming language to enable real-time robot tracking. Furthermore, more robust Duckiebot identification mechanisms should be considered.

Besides these extensions to the DuckieVisualizer, the student will also do some general system maintenance tasks. This may include the hardware of the Duckiebots and their software stack, for example, merging different sub-projects and looking into quality-of-life improvements to the building process using Docker. Another task will be to help newly starting students set up their development environment and to assist them in their first steps. Finally, the student can get involved in expanding our track and adding new components, e.g., intersections or duckie pedestrian crossings.

Prerequisites

At LIS, we leverage the Duckietown hardware and software ecosystem to experiment with our reinforcement learning (RL) agents, known as learning classifier tables (LCTs), as part of the Duckiebot control system. More information on Duckietown can be found here.

We use a Duckiebot's Time-of-Flight (ToF) sensor to measure the distance to objects in front of the robot. This allows it to stop before crashing into obstacles. The distance measurement is also used in our platooning mechanism. When another Duckiebot is detected via its rear dot pattern, the robot can adjust its speed to follow the other Duckiebot at a given distance.

Unfortunately, the measurement region of the integrated ToF sensor is very narrow. It only detects objects reliably in a cone of about 5 degrees in front of the robot. Objects outside this cone, either too far to the side or too high/low, cannot reflect the emitted laser beam to the sensor's collector, leading to crashes. The distance measurement is also fairly noisy, with measurement accuracy decreasing for further distances, angular offsets from the sensor, and uneven reflection surfaces. This means that the distance to the other Duckiebot is often not measured correctly in the platooning mode, causing the robot to react with unexpected maneuvers and to lose track of the leading robot.

In this student assistant project, the student will investigate how to resolve these issues. After analyzing the current setup, different sensors and their position on the robot's front should be considered. A suitable driver and some hardware adaptations will be required to add a new sensor to the Duckiebot system. Finally, they will integrate the improved distance measurement setup in our Python/ROS-based autonomous driving pipeline, evaluate it in terms of measurement region and accuracy, and compare the new setup to the baseline.

These modifications should allow us to avoid crashes more reliably and enhance our platooning mode, which will be helpful for further development, especially when moving to more difficult-to-navigate environments, e.g., tracks with intersections and sharp turns.

Prerequisites

At LIS, we leverage the Duckietown hardware and software ecosystem to experiment with our reinforcement learning (RL) agents, known as learning classifier tables (LCTs), as part of the Duckiebot control system. More information on Duckietown can be found here.
In previous work, the default deterministic controller for the robot's speed was replaced by an RL agent. It uses an LCT with current speed as the system state and actions that cause relative speed changes. To enable platooning via this agent, a second version includes the distance to a Duckiebot driving ahead as a second entry to the state vector. With this limited set of rules and a modified SARSA/Q-learning method for Q-value updates, the agent quickly learns to let the bot drive at a given target speed.
However, the RL-based speed controller does not consider the track's properties. A given target speed might be too high to take turns properly, especially when the agent is eventually combined with the separately developed steering agent. On the other hand, consistently letting the robot drive slowly would be a waste of time on a mostly straight track.
To resolve this problem, this thesis should introduce the curvature of the track into the state observation. To detect curves in the camera images, the student will extend the image processing pipeline beyond how the steering mechanism takes care of turns. The student will expand the rule set, adapt the reward function, and investigate the effects on learning performance. A likely consequence of a more extensive rule set is the need for a more advanced Q-value update method. Additional improvements might concern the speed measurement accuracy of the wheel encoders. The enhanced speed controller will be evaluated for learning speed, driving performance in terms of deviation from target speed in different scenarios, and resource utilization.
With these extensions to the speed controller, those to the steering controller, and the object recognition algorithm developed in further student work, we will set the foundation to deploy our RL-based Duckiebots in more difficult-to-navigate environments, e.g., tracks with intersections and sharp turns.

At LIS, we leverage the Duckietown hardware and software ecosystem to experiment with our reinforcement learning (RL) agents, known as learning classifier tables (LCTs), as part of the Duckiebot control system. More information on Duckietown can be found here.
In previous work, an algorithm to detect obstacles in the path of a Duckiebot was developed. It uses its Time-of-Flight (ToF) sensor for general obstacles in front of the robot. It can also specifically detect duckies in the camera image, mainly used for lane detection, by creating a color-matching mask with bounding rectangles within a certain size range and position on the track. If the robot detects any obstacle in its path, it slows down, then stops and waits for the obstacle to disappear if it is too close.
While this algorithm works well for large obstacles right in front of the ToF sensor and duckies on straight tracks, it struggles to detect obstacles in other scenarios. The ToF sensor only covers a narrow measurement region and misses objects that are off-center or too high/low. Its measurement results are also not very reliable, especially for higher distances. The camera-based recognition sometimes interchanges duckies with the track's equally yellow centerline. It can fail to detect them due to blind spots (caused by a dynamic region of interest, not an actual blind spot of the camera) when driving on a curved track.
We also want to include other objects besides duckies in our recognition algorithm, e.g., stop lines or traffic signs at intersections. Since the camera approach is tuned to the size and color of duckies, manual effort would be needed to extend it to different objects. Therefore, in this Bachelor's thesis, we want to overhaul our object recognition to be more reliable and detect various objects in different scenarios. A good approach could be using the YOLO (You Only Look Once) algorithm, a single-pass real-time object detection algorithm based on a convolutional neural network. There is also some related work around this topic in the Duckietown community.
The student will start with a continued analysis of the problems of the previous method and literature research regarding viable object detection algorithms. Afterward, they will implement and integrate the selected algorithm into the existing framework. Depending on the approach, some training will be necessary. The student will start with a continued analysis of the current problems and literature research regarding viable object detection algorithms. Afterward, they will implement and integrate the selected algorithm into the existing framework. Depending on the approach, some training will be necessary. Furthermore, they will evaluate the detection pipeline for accuracy in different scenarios, latency, and resource utilization. Once a reliable detection system is established, our system can be extended to more complex behavior, such as circumnavigating duckies or responding to intersectional traffic signs.

Prerequisites

In the BCDC project, a working group at TUM collaborates on designing a RISC-V-based chiplet demonstration chip, of which at least two will be connected via an interposer to simulate a system of interconnected chiplets. At LIS, we work on a high-performance, low-latency chiplet interconnect with additional application-specific features managed by a smart protocol controller. It closes the gap between the underlying physical layer that takes care of data transmission across the interposer, and the system bus that attaches the inter-chiplet interface to the other components of the demonstration chip.

A high-level simulation of our system should be set up during this research internship to investigate the viability and performance of different architecture configurations. The simplest topology involves two connected identical chiplets; more complex arrangements could consist of more chiplets or other architectural elements, like an FPGA. The chiplets should be abstracted to mainly generate and process data in manners like the RISC-V CPU cores and further processing units attached to the AXI bus. A bus functional model should represent the interconnect and simulate it regarding transmission width, throughput, and latency. The modeled interconnect standard, for example, UCIe, PCIe, or modified versions of MII or SPI, and the level of modeling detail are to be explored.

As a first step, approaches to simulate specifically chiplet architectures should be researched theoretically. After choosing a suitable framework, e.g., SystemC or Matlab/Simulink, the system model should be created, and different configurations should be investigated. Ultimately, the simulation should help identify the benefits and drawbacks of these configurations and support a future HDL implementation.

Prerequisites

At LIS, we leverage the Duckietown hardware and software ecosystem to experiment with our reinforcement learning (RL) agents, known as learning classifier tables (LCTs), as part of the Duckiebots' control system (https://www.ce.cit.tum.de/lis/forschung/aktuelle-projekte/duckietown-lab/).
More information on Duckietown can be found at https://www.duckietown.org/.

In previous work, an LCT agent to steer Duckiebots has been developed using only the angular heading error for the system state. In this Bachelor's thesis, the vehicle steering agent should be improved and its functionality extended.
Starting with the existing Python/ROS implementation of the RL agent and our image processing pipeline, multiple system parts should be enhanced. On the environment side, detecting the lateral offset from the center of a lane should be improved for reliability. This will require an analysis of the current problems and some adaptations in the pipeline, possibly some hardware changes.
With more reliable lane offset values, the agent's state observation can also include it, allowing us to move further from the default PID control towards a purely RL-based steering approach. This will involve modifications to the rule population, the reward function, and potentially the learning method. Different configurations are to be implemented and evaluated in terms of their resulting performance and efficiency.
The thesis aims to shift the vehicle steering entirely to the RL agent, ideally reducing the effort for manual parameter tuning while being comparable in driving performance and computation effort.

Prerequisites