index.json

[{"content":"I’m a Computer Science \u0026amp; Engineering graduate from Amity University Noida, passionate about Linux, open-source technologies, and software development. I love building tools, experimenting with systems, and contributing to meaningful tech communities.\nI’m a two-time Google Summer of Code contributor under Automotive Grade Linux (AGL), a The Linux Foundation project, where I developed Qt-based applications to simulate CAN Bus signals. I also interned as an SDE at FOSSEE, IIT Bombay, contributing to the eSim platform, a free and open-source EDA tool, where I worked on installer tooling and Flatpak packaging.\nCurrently, I work as a Global Technical Support Engineer at Ciena, where I handle live network issues, triage and troubleshoot on Linux environments, and provide support for Network Management Systems.\nOutside of tech, I enjoy playing guitar, football, table tennis, and diving into science fiction and new discoveries.\n🏆 Highlights \u0026amp; Achievements # 🏅 Recognition at Ciena\nAcknowledged within the Global Customer Care (GCC) team for consistent, detail-oriented problem solving and a methodical approach to complex network issues. Praised for structured investigations and technical ownership in customer-impacting scenarios.\n🌍 Google Summer of Code 2023 \u0026amp; 2024\nContributed to AGL with gRPC/websocket based feature development on the YOCTO platform, recognized by the global open-source community.\n🎤 Conference Speaker\nPresented at AGL All Members Meet Japan 2024 and Open Source Summit Japan 2023 on Linux systems and embedded software.\n🧑‍💻 Internship at FOSSEE, IIT Bombay\nImproved the eSim EDA tool through installer enhancements and Flatpak packaging.\n📜 Certifications\nSoftware Engineering – Goldman Sachs Forage Joy of Computing with Python – NPTEL, IIT Madras 🎓 Academics\nGraduated with 82% in B.Tech (CSE) from Amity University, with practical exposure to multiple App development, Open-source Contribution, Embedded/ OS development, and networking technologies.\n🧠 Core Competencies # 🔖 Category Skills 💻 Programming Languages Python, C/C++, Bash, Java, SQL, Rust, Dart, Kotlin, Golang 🗄️ Databases \u0026amp; Storage Cassandra, Firebase, PostgreSQL, MySQL, SQLite, MongoDB 🐧 Linux \u0026amp; Operating Systems Linux Systems, Shell scripting, System optimization, Performance tuning, Kernel Modules 🌐 Networking CAN Bus, Ethernet/LAN, TCP/IP, Network protocols, Linux network stack, Troubleshooting ⚙️ System \u0026amp; Infrastructure Docker, Kubernetes, Microservices, Infrastructure design, gRPC, Kafka 🔁 Version Control \u0026amp; Collaboration Git, Gerrit, Bitbucket, Github, GitLab 📟 Embedded Systems \u0026amp; Emulation Yocto Project, Raspberry Pi, AGL (Automotive Grade Linux), QEMU, KVM, VMware, ESXi 🧱 Development Frameworks Qt6/QML, PyQt5, Flutter, Django, NodeJS 🧭 Philosophy \u0026amp; Learning # I believe in building things that last—and that starts with continuous learning. I stay curious by:\nExploring new technologies and skills Engaging with open-source communities and projects Sharing through documentation and occasional tech talks 🤝 Let’s Connect # I\u0026rsquo;m always open to interesting collaborations, learning opportunities, or a good conversation about Linux, embedded systems, open-source, and networking innovations.\n📡 You can follow updates via my RSS feed.\n","date":"1 May 2025","externalUrl":null,"permalink":"/about/","section":"Homepage","summary":"I’m a Computer Science \u0026amp; Engineering graduate from Amity University Noida, passionate about Linux, open-source technologies, and software development.","title":"About Me","type":"page"},{"content":" What is GSoC? # Google Summer of Code (GSoC) is a global program that offers students an opportunity to contribute to open-source projects. The program is sponsored by Google and has been running since 2005. The program aims to bring together students and open-source organizations to work on real-world projects. The program has three phases: the community bonding period, the coding period, and the final evaluation period.\nWhat is The Linux Foundation and Automotive Grade Linux? # The Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux. Automotive Grade Linux is an open-source project hosted by The Linux Foundation that is building an open operating system and framework for automotive applications.\nMy work # The objective of this project was to develop a Qt5 application that simulates CAN bus traffic using Kuksa.val to integrate with the AGL Demo platform. The application developed allows the end-users to emit signals using the kuksa-client SDK and Python-can to visualize and interact with AGL Demo applications, such as the IC, IVI, HVAC, and the Green Machine, that display CAN data through Kuksa.val.\nGSoC 2023 Blogs → Click Here\nFinal Report → Click Here\n# Source Code \u0026amp; Documentation # → Gerrit: agl-demo-control-panel\n→ GitHub: AGL_Demo_Control_Panel\n→ Documentation: AGL/documentation\n","date":"1 May 2025","externalUrl":null,"permalink":"/portfolio/ciena/","section":"Portfolio","summary":"What is GSoC?","title":"Ciena - Global Technical Support","type":"portfolio"},{"content":" ","date":"1 May 2025","externalUrl":null,"permalink":"/","section":"Homepage","summary":" ","title":"Homepage","type":"page"},{"content":" Resume # Download CV Key Accomplishments # Contributed to Google Summer of Code 2023 \u0026amp; 2024, advancing Automotive Grade Linux under the The Linux Foundation with innovative Ethernet and gRPC-based features, earning recognition within the global open-source community. Presented at AGL all Members Meet Japan 2024 and Open Source Summit Japan 2023, establishing thought leadership in Linux and open-source software engineering. Contributed to the FOSSEE project at IIT Bombay as a Semester long SDE Intern. Certified in Software Engineering (Goldman Sachs Forage) and Joy of Computing with Python (NPTL, IIT Madras), reinforcing my technical depth in Linux-centric development. Achieved an 82% in B.Tech (Computer Science) from Amity University, underpinned by practical experience with Yocto, gRPC, WebSocket, and Ethernet technologies. Experience # Global Technical Support Eng. 08/01/24 - present Ciena Ciena is a leading networking systems, services, and software company specializing in high-performance optical and packet networking solutions. It enables telecom carriers, cloud providers, and large enterprises to build adaptive, resilient, and scalable networks. Troubleshooting live network issues on remote nodes/ Linux environments and Network Management Systems. Configure NMS software and issue patches and rollbacks. Performed patching and troubleshooting on RHEL/ CentOS for NNCS/ MCP NMS Deployment on ESXi VM and bare-metal infrastructure Configuring and troubleshooting IPsec site-to-site connections for GR Deployments on Linux servers. Network configurations on Ciena Network Elements and NMS platform. Perform Log analysis and provide Root Cause to customers More Google Summer of Code Contributor May 2023 - Nov 2024 Automotive Grade Linux/ The Linux Foundation Google Summer of Code (GSoC) is a global program by Google that offers students and new contributors the opportunity to work on open-source projects with mentoring from established organizations. Automotive Grade Linux (AGL) is a collaborative open-source project under The Linux Foundation, aiming to build a unified software platform for in-vehicle infotainment and other automotive applications. I Contributed to the Open-source Automotive Grade Linux project for two consecutive years (2023 and 2024) as a GSoC contributor. Developed a Qt6/QML-based application to simulate and playback CAN bus signals, using multi-threading and design-pattern concepts. Collaborating with CIS and new contributors to add new features Utilized the Kuksa-client SDK and CAN frame messages to communicate with kuksa-val-server \u0026 Databroker over ethernet/LAN and CAN bus interface Built AGL Images using Yocto tools, tested against virtual machines and on-target hardware Added support for real-time and playback of CARLA - the car simulator (Unreal Engine). More on GSoC 2023 More on GSoC 2024 SDE Intern Feb - May 2023 FOSSEE, IIT Bombay With other shortcodes FOSSEE is an IIT Bombay initiative promoting open-source software in education and research. eSim, developed under FOSSEE, is a free EDA tool for circuit design, simulation, and PCB layout. It integrates open tools like KiCad and Ngspice, offering an alternative to proprietary EDA software. FOSSEE also conducts training to support eSim adoption in academic and engineering communities. Developed a Flatpak-based demo application to install eSim tools and dependencies. Ul improvements to eSim to show the progress of ongoing simulations. Submitted an Appimage application to install verilator from source and implemented initial port of Qt5 to Qt6. More Skills # Details # ","date":"1 May 2025","externalUrl":null,"permalink":"/portfolio/","section":"Portfolio","summary":"Resume # Download CV Key Accomplishments # Contributed to Google Summer of Code 2023 \u0026amp; 2024, advancing Automotive Grade Linux under the The Linux Foundation with innovative Ethernet and gRPC-based features, earning recognition within the global open-source community.","title":"Portfolio","type":"portfolio"},{"content":"","date":"27 October 2024","externalUrl":null,"permalink":"/tags/agl/","section":"Tags","summary":"","title":"AGL","type":"tags"},{"content":"","date":"27 October 2024","externalUrl":null,"permalink":"/articles/","section":"Blog Posts","summary":"","title":"Blog Posts","type":"articles"},{"content":"","date":"27 October 2024","externalUrl":null,"permalink":"/tags/gsoc-24-wpr/","section":"Tags","summary":"","title":"GSoC '24 WPR","type":"tags"},{"content":"","date":"27 October 2024","externalUrl":null,"permalink":"/tags/gsoc-2024/","section":"Tags","summary":"","title":"GSoC 2024","type":"tags"},{"content":"","date":"27 October 2024","externalUrl":null,"permalink":"/tags/gsoc-final-report/","section":"Tags","summary":"","title":"GSoC Final Report","type":"tags"},{"content":" Introduction # This report is a requirement of the Final evaluation phase of the Google Summer of Code 2024 the Google program. I worked with the Linux Foundation, under Automotive Grade Linux to Extend AGL\u0026rsquo;s Demo Control Panel, which was my contribution during GSoC 2023 under the GSoC project Qt5 Application to Visualise/ Simulate CAN bus traffic using Kuksa.val\nYou can find the proposal for this year\u0026rsquo;s project here.\nThe Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux. Automotive Grade Linux is an open-source project hosted by The Linux Foundation that is building an open operating system and framework for automotive applications.\nProject Overview # The objective of this year\u0026rsquo;s project was to build upon my last year\u0026rsquo;s contribution to Extend AGL\u0026rsquo;s Demo Control Panel. The application developed allows the end-users to emit signals using the kuksa-client SDK and Python-can to visualize and interact with AGL Demo applications, such as the IC, IVI, HVAC, and the Green Machine, that display CAN data through Kuksa.val.\nDemo Video # # Source Code \u0026amp; Documentation # → Code Hosted on Gerrit: agl-demo-control-panel\n→ Documentation: AGL/documentation\n# Deliverables # Porting the app from Qt5 to Qt6 framework. Adding better QML widgets/ animations for gauges and spin-wheel inputs. Adding file playback (e.g. for CARLA recordings) Visualizing signals (real-time and playback) Adding New Controls and Keypad Features IC keypad feature Power-control feature Integrate the application with the AGL Demo platform. Packaging and distribution of the Application. Update documentation pages based on work. Work Done # # Progress Reports # → Community Bonding Period: During the GSoC 2024 community bonding period, I had a fantastic learning experience. I got to re-connect with my GSoC mentors and the AGL community, I re-familiarized myself with AGL tools, and set up my working environment. I also tackled some technical challenges and ventured into working with CARLA, Qt6/QML, and AGL images. Overall, the community bonding period was a great start.\n→ Coding Period: The coding period of GSoC is a dedicated timeframe during which the accepted contributors work on their projects. The standard coding period is 12 weeks. However, my mentors and I saw it fit to have a longer coding period of 22 weeks to complete our Large-Scale project.\nDuring this period, I was able to:\nWrite and submit my code to Gerrit/GitHub. Issue patches and bug fixes based on review. Regularly communicate with my mentors. (Mondays) Participate in the AGL and GSoC community. (Thursdays) Submit my work for mid-term and final evaluations. Below I have compiled all my Weekly Progress Reports for the duration of the coding period of GSoC \u0026lsquo;24.\nWeek 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Week 11 Week 12 Week 13 Week 14 Week 15 Week 16 Week 17 Week 18 Week 19 Week 20 Week 21 Week 22 # Major Gerrit Commits # 29969: Port AGL Demo Control Panel to Qt6 30049: Add Python Script to Convert CARLA data into CAN messages 30275: Add New Custom Gauges and CARLA playback refactored 30327: Update Carla Playback Mode 30401: Add Tire Pressure, Keypad elements and misc. UI Changes 30454: agl-demo-control-panel: Update dependency and Bump SRCREV 30456: Bug fixes for Control Panel 30444: agl-demo-control-panel: Update Documentation Conclusion # # What did I learn? # I was able to dive deeper into the OpenEmbedded Yocto Project and create layers and recipes for our specific application. I learnt how to create and port applications to Qt6, PyQt and QML. Learnt about gRPC and WebSocket and how they are implemented in Kuksa.val and its Python SDK. I had the opportunity to test my application and AGL images on a Raspberry Pi 4 kindly provided by my AGL mentors last year. I also had the opportunity to learn about the CARLA Simulator, a simulation platform developed from the ground up to support development, training, and validation of autonomous driving systems. Making use of its flexible APIs; I was able to provide the File Playback feature to the agl-demo-control-panel. I also learned a lot more about the Automotive Grade Linux organization, its development tools, workflow, and pipeline. # Post GSoC # I plan to maintain and add to the Automotive Grade Linux’s repository for my project for the foreseeable future and work on continually improving it. I will keep contributing and help other new contributors to explore and learn projects in this organization. Acknowledgments # I would like to express my gratitude to my mentors Jan-Simon Möller, Justin Noel, Scott Murray, Marius Vlad, and Walt Miner and for mentoring me through another year of GSoC and also to the whole AGL community for being so inclusive and friendly.\nIt has been one of the best professional experiences. Learning about new tools and technologies, and working on an open-source project along with experienced developers from all over the world has been a great experience for me. I would love to continue working with AGL, improving my project, and whatever I feel that I can contribute to.\n","date":"27 October 2024","externalUrl":null,"permalink":"/articles/gsoc24/gsoc2024-final-report/","section":"Blog Posts","summary":"Introduction # This report is a requirement of the Final evaluation phase of the Google Summer of Code 2024 the Google program.","title":"GSoC2024 Final Report","type":"articles"},{"content":"","date":"27 October 2024","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"27 October 2024","externalUrl":null,"permalink":"/tags/the-linux-foundation/","section":"Tags","summary":"","title":"The Linux Foundation","type":"tags"},{"content":" Tasks Completed: # During the twenty-second and final week of my Google Summer of Code 2024 (GSoC) project, I pushed updated documentation and patches for AGL-Demo-Control-Panel to Gerrit for review. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\nChange log: # Issued bug fixes and patches for the agl-demo-control-panel. Updated/ Completed documentation for agl-demo-control-panel and CARLA with AGL resp. Completed GSoC final report. (WIP) Demo Setup Video will be posted along with the final report later next week. # Code pushed for review: # 30453: Patch Update: Fix Floating Tire Pressure Visibility 30444: agl-demo-control-panel: Update Documentation 30454: agl-demo-control-panel: Update dependency and Bump SRCREV # Code Merged this week: # 30437: Fix Visual Bugs and Add options for Keypad input 30438: agl-demo-control-panel: Bump SRCREV What I plan to do next: # Submission of the GSoC project and its Report for evaluation. Complete Demo Setup (Video). ","date":"27 October 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-22/","section":"Blog Posts","summary":"Tasks Completed: # During the twenty-second and final week of my Google Summer of Code 2024 (GSoC) project, I pushed updated documentation and patches for AGL-Demo-Control-Panel to Gerrit for review.","title":"Week 22","type":"articles"},{"content":" Tasks Completed: # During the twenty-first week of my Google Summer of Code (GSoC) project, I pushed the last changes for AGL-Demo-Control-Panel to. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\nChange log: # Fix Visual Bugs and Add options for Keypad input\nFixed spin wheel input alignment for HVAC controls Minor tweaks to Gauge input, Added new tick marks and improved gradient Adding option(s) in config to handle Keypad input settings Reconnect QML signals to enable two way input for Speed, RPM and other QML elements Refactor and Add CLI option to start and stop playback. Make Tire Pressure Dock into floating window and align to screen center. Update resources to include keypad icons. Bump SRCREV\nBump SRCREV for agl-demo-control-panel. Add cantools as runtime dependency. Updated Documentation\nExplain new Config options Provide Tips and Workarounds to CARLA playback steps Update Steps required to run Qt6 version of Demo Control Panel # Code pushed for review: # 30437: Fix Visual Bugs and Add options for Keypad input 30438: agl-demo-control-panel: Bump SRCREV 30444: (WIP) agl-demo-control-panel: Update Documentation # Code Merged this week: # 30401: Add Tire Pressure, Keypad elements and misc. UI Changes. What I plan to do next: # Finalize report for GSoC \u0026lsquo;24. Demo Setup (Video). ","date":"20 October 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-21/","section":"Blog Posts","summary":"Tasks Completed: # During the twenty-first week of my Google Summer of Code (GSoC) project, I pushed the last changes for AGL-Demo-Control-Panel to.","title":"Week 21","type":"articles"},{"content":" Tasks Completed: # During the twentieth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the CARLA playback features for the AGL-Demo-Control-Panel. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# Tire Pressure, Keypad elements and misc. UI Changes # This week I integrated the Tire Pressure and Keypad widgets into the control panel, refactored some UI elements and backend code and fixed bugs and issues.\nChange log: # Increased slider grab handle size Add floating menu for Tire Pressure UI Show errow in Playback toggle when CAN interface is not available Update Half gauges to show Unit and logo correctly Update App resources Add new tumbler input for HVAC temp Add new get function to KuksaClient to get Tire Pressure unit and Current value to increment Fixes: # Check for vcar dbc file at \u0026lsquo;/etc/kuksa-dbc-feeder/\u0026rsquo; Increase font size in Settings page Allow for tumbler/ spin wheel values to wrap around # Code pushed for review: # 30401: Add Tire Pressure, Keypad elements and misc. UI Changes. # Code Merged this week: # 30327: (WIP) Update Carla Playback Mode. What I plan to do next: # Bug fixing and update documentation as required. Start drafting the final report for GSoC \u0026lsquo;24. Demo Setup (Video). ","date":"13 October 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-20/","section":"Blog Posts","summary":"Tasks Completed: # During the twentieth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the CARLA playback features for the AGL-Demo-Control-Panel.","title":"Week 20","type":"articles"},{"content":" Tasks Completed: # During the nineteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the CARLA playback features for the AGL-Demo-Control-Panel. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# Tire Pressure Widget and Keypad inputs # This week I integrated the Tire Pressure and Keypad widgets into the control panel.\n# Bug fixes: # (WIP): Garbage values displayed on Half-Gauge widgets when Demo playback is enabled. CARLA playback implementation fixed threaded playback. Updated IC page sliders height/ width to improve touch input. Display correct icons for Gauges (Fuel and Coolant) # Code pushed for review: # 30327: (WIP) Update Carla Playback Mode. # Code Merged this week: # 30275: Add New Custom Gauges and CARLA playback refactored 30324: AGL Demo Control Panel: Enable Networking and QtQuick What I plan to do next: # Finalize all changes and push code to Gerrit. Update documentation as required. ","date":"6 October 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-19/","section":"Blog Posts","summary":"Tasks Completed: # During the nineteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the CARLA playback features for the AGL-Demo-Control-Panel.","title":"Week 19","type":"articles"},{"content":" Tasks Completed: # During the eighteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the CARLA playback features for the AGL-Demo-Control-Panel. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# CARLA Playback in Demo Mode # This week I implemented the playback of the recorded \u0026lsquo;can-messages.txt\u0026rsquo; file, allowing the agl-demo-control-panel to playback the same CAN data on its UI elements.\nThis includes:\nSpeed Gauge Engine RPM Gauge Coolant Temp Gauge Fuel level Gauge Indicator buttons and Drive modes These signals have been mapped out of the carla client and translated into their CAN message format by the carla_to_CAN.py module.\nI also implemented the file-playback-path and the can-interface options to the config.ini file to allow for default configurations to be specified during the build process.\n# Gradient Effect and Progress Ticks on Gauge # # Bug fixes: # Incorrect encoding of Indicator states in carla_to_CAN.py. (WIP): Garbage values displayed on Half-Gauge widgets when Demo playback is enabled. # Code pushed for review: # 30275: Add New Custom Gauges and CARLA playback refactored 30324: AGL Demo Control Panel: Enable Networking and QtQuick 30327: (WIP) Update Carla Playback Mode What I plan to do next: # Continue working on the new UI for the Demo Control Panel. Bug fixing and pushing code to Gerrit. ","date":"29 September 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-18/","section":"Blog Posts","summary":"Tasks Completed: # During the eighteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the CARLA playback features for the AGL-Demo-Control-Panel.","title":"Week 18","type":"articles"},{"content":" Tasks Completed: # During the seventeenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# (WIP) New QML UI # This week I continued working on the QML-based UI elements for the AGL-Demo-Control-Panel. Custom gauges for Engine RPM, Speed, fuel level and coolant temp. have been implemented.\nFixes: Units and Values not updating when Parent is main application for QML elements. Fixes: Widget not scaling to parent window size\nCode pushed for review: 30275: (WIP) Add New Custom Gauges and CARLA playback refactored\n# Continued working on Coolant and Fuel Gauges: These widgets are still WIP. # Next Week Tasks: # Continue working on the new UI for the Demo Control Panel. Bug fixing and pushing code to gerrit for review. ","date":"22 September 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-17/","section":"Blog Posts","summary":"Tasks Completed: # During the seventeenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel.","title":"Week 17","type":"articles"},{"content":" Tasks Completed: # During the sixteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# (WIP) New QML UI # This week I continued working on the QML-based UI elements for the AGL-Demo-Control-Panel. Custom gauges for Engine RPM, Speed, fuel level and coolant temp. have been implemented.\nFixes: No transparent background for QML elements; for the time being, matching the background color of the parent window. Fixes: Widget not scaling to parent window size\n# Continued working on Coolant and Fuel Gauges: These widgets are still WIP. # Next Week Tasks: # Add a floating menu for Tyre pressure UI. Revisit CARLA and Kuksa bindings. Refine playback implementation. ","date":"15 September 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-16/","section":"Blog Posts","summary":"Tasks Completed: # During the sixteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel.","title":"Week 16","type":"articles"},{"content":" Tasks Completed: # During the fifteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# (WIP) New QML UI # This week I continued working on the QML-based UI elements for the AGL-Demo-Control-Panel. Custom gauges for Engine RPM, Speed, fuel level and coolant temp. have been implemented.\nFixes: No transparent background for QML elements; for the time being, matching the background color of the parent window. Fixes: Widget not scaling to parent window size\n# Continued working on Coolant and Fuel Gauges: These widgets are still WIP. # Next Week Tasks: # Add a floating menu for Tyre pressure UI. Revisit CARLA and Kuksa bindings. Refine playback implementation. ","date":"8 September 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-15/","section":"Blog Posts","summary":"Tasks Completed: # During the fifteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel.","title":"Week 15 Progress Report","type":"articles"},{"content":" Tasks Completed: # During the fourteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# Keypad Features # This week I pushed code for review via 30231: Abstract Momikey Input Events using Individual Key Scripts ; where I proposed to abstract the events triggered by momikey input by splitting them into individual scripts.\nThis would have allowed external users/apps (Demo Control Panel: Keypad) to trigger input events by simply running the scripts over cli/ssh session.\nHowever, maintainer: Naoto Yamaguchi San recommended using the momiweb interface APIs to change guest by command.\nwget http://localhost:8080/cgi-bin/flutter.cgi wget http://localhost:8080/cgi-bin/qt.cgi wget http://localhost:8080/cgi-bin/momi.cgi wget http://localhost:8080/cgi-bin/bomb.cgi This has been accomplished using the Paramiko library.\nThe keys execute the following command on the host system, for reference; momikey.sh\n# (WIP) New QML UI # This week I continued working on the QML-based UI elements for the AGL-Demo-Control-Panel.\n# New Gauge for Vehicle Speed and Engine RPM # Bug: Integrating new QML widget into PyQt6 Application leads to the issue of Scaling and Widget transparency, I will be addressing these in the coming week.\n# Continued working on Coolant and Fuel Gauges: These widgets are still WIP. # Next Week Tasks: # Continue working on the new UI elements. Push changes to Gerrit for review by mentors. ","date":"1 September 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-14/","section":"Blog Posts","summary":"Tasks Completed: # During the fourteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel.","title":"Week 14 Progress Report","type":"articles"},{"content":" What is GSoC? # Google Summer of Code (GSoC) is a global program that offers students an opportunity to contribute to open-source projects. The program is sponsored by Google and has been running since 2005. The program aims to bring together students and open-source organizations to work on real-world projects. The program has three phases: the community bonding period, the coding period, and the final evaluation period.\nWhat is The Linux Foundation and Automotive Grade Linux? # The Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux. Automotive Grade Linux is an open-source project hosted by The Linux Foundation that is building an open operating system and framework for automotive applications.\nMy work # The objective of this project was to develop a Qt5 application that simulates CAN bus traffic using Kuksa.val to integrate with the AGL Demo platform. The application developed allows the end-users to emit signals using the kuksa-client SDK and Python-can to visualize and interact with AGL Demo applications, such as the IC, IVI, HVAC, and the Green Machine, that display CAN data through Kuksa.val.\nGSoC 2024 Blogs → Click Here\nFinal Report → Click Here\n# Source Code \u0026amp; Documentation # → Gerrit: agl-demo-control-panel\n→ GitHub: AGL_Demo_Control_Panel\n→ Documentation: AGL/documentation\n","date":"1 September 2024","externalUrl":null,"permalink":"/portfolio/gsoc_2024/","section":"Portfolio","summary":"What is GSoC?","title":"GSoC '24 The Linux Foundation @ Automotive Grade Linux (May - Nov 2024)","type":"portfolio"},{"content":" Tasks Completed: # During the thirteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# Keypad Features # This week I refactored the Keypad Page, changes include:\nSSH Session is retained, User is prompted upon disconnect Config File support to enable or disable visibility of page This has been acomplished using the Paramiko library.\nUsing Paramiko over direct system calls for SSH operations offers several advantages,\nSession Reuse: Paramiko supports reusing SSH sessions, which can significantly reduce connection overhead when executing multiple commands against the same server. Managing such connections efficiently with system calls requires additional logic. SFTP Support: Beyond just executing commands, Paramiko also supports SFTP operations, allowing for secure file transfers over SSH. Implementing SFTP functionality via system calls would require additional tools and more complex setup. and more. The keys execte the following command on the host system, for reference; momikey.sh\nclass MomiKeyHandler: def __init__(self): config_data = config.get_ssh_config() self.ssh_client = None self.host = config_data.get(\u0026#34;host\u0026#34;) if config_data.get(\u0026#34;host\u0026#34;) else None self.username = config_data.get(\u0026#34;username\u0026#34;) if config_data.get(\u0026#34;username\u0026#34;) else None self.password = config_data.get(\u0026#34;password\u0026#34;) if config_data.get(\u0026#34;password\u0026#34;) else None self.ssh_key_path = config_data.get(\u0026#34;ssh_key_path\u0026#34;) if config_data.get(\u0026#34;ssh_key_path\u0026#34;) else None def establish_ssh_connection(self): try: self.ssh_client = paramiko.SSHClient() self.ssh_client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) if self.password is None: self.password = getpass(\u0026#34;Enter password for {}: \u0026#34;.format(self.username)) if self.ssh_key_path: private_key = paramiko.RSAKey.from_private_key_file(self.ssh_key_path) self.ssh_client.connect(hostname=self.host, username=self.username, pkey=private_key) else: self.ssh_client.connect(hostname=self.host, username=self.username, password=self.password) except Exception as e: print(f\u0026#34;Connection failed: {e}\u0026#34;) sys.exit(1) def execute_script(self, command): if not self.ssh_client or not self.ssh_client.get_transport().is_active(): self.establish_ssh_connection() try: stdin, stdout, stderr = self.ssh_client.exec_command(command) output = stdout.read().decode() error_output = stderr.read().decode() if output: print(output) if error_output: print(error_output) except Exception as e: print(f\u0026#34;Execution failed: {e}\u0026#34;) class KeypadWidget(Base, Form): def __init__(self, parent=None): super(self.__class__, self).__init__(parent) self.setupUi(self) self.momi_key_handler = None # Mapping of keys to commands self.key_commands = { \u0026#34;Key_1\u0026#34;: \u0026#34;echo \u0026#39;Key 1 pressed\u0026#39; # cmcontrol --change-active-guest-name=agl-flutter-ivi-demo \u0026amp;\u0026amp; cmcontrol --shutdown-guest-role=ivi\u0026#34;, \u0026#34;Key_2\u0026#34;: \u0026#34;echo \u0026#39;Key 2 pressed\u0026#39; # cmcontrol --change-active-guest-name=agl-qt-ivi-demo \u0026amp;\u0026amp; cmcontrol --shutdown-guest-role=ivi\u0026#34;, \u0026#34;Key_3\u0026#34;: \u0026#34;echo \u0026#39;Key 3 pressed\u0026#39; # cmcontrol --change-active-guest-name=agl-momi-ivi-demo \u0026amp;\u0026amp; cmcontrol --shutdown-guest-role=ivi\u0026#34;, \u0026#34;Key_4\u0026#34;: \u0026#34;echo \u0026#39;Key 4 pressed\u0026#39; # cmcontrol --change-active-guest-name=agl-html5-ivi-demo \u0026amp;\u0026amp; cmcontrol --shutdown-guest-role=ivi\u0026#34;, \u0026#34;Key_5\u0026#34;: \u0026#34;echo \u0026#39;Key 5 pressed\u0026#39; # cmcontrol --force-reboot-guest-role=ivi\u0026#34;, } # Connect all keys to the same slot for key_name in self.key_commands.keys(): key_button = self.findChild(QPushButton, key_name) key_button.clicked.connect(lambda _, x=key_name: self.execute_script(x)) def execute_script(self, key_name): if self.momi_key_handler is None: self.momi_key_handler = MomiKeyHandler() command = self.key_commands[key_name] self.momi_key_handler.execute_script(command) if __name__ == \u0026#39;__main__\u0026#39;: app = QApplication(sys.argv) w = KeypadWidget() w.show() sys.exit(app.exec()) # (WIP) New QML UI # This week I continued working on the QML-based UI elements for the AGL-Demo-Control-Panel.\nThese new widgets are written in QML, being more flexible and versatile will lead to the UI elements being more expressive.\nHere is the reference design shared by the ICS team amd Justin Noel which I\u0026rsquo;m using as refernce for the new UI.\nThe AGL Demo Control Panel will still use PyQt6 for the main application while the new QML elements will be handled by separate modules to be rendered as child QObjects.\nThis week I also collaborated with Justin Noel / ICS to refer to their generated code for the Control Panel demo app written in C++ and GreenHouse code generator.\nWhile the code is generated and not a drop in solution to the AGL-Demo-Control-Panel, it gives me a good base for reference.\nNext Week Tasks: # Continue working on the new UI elements. Build and test images for the new UI and features. Push changes to Gerrit for review by mentors. ","date":"24 August 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-13/","section":"Blog Posts","summary":"Tasks Completed: # During the thirteenth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel.","title":"Week 13 Progress Report","type":"articles"},{"content":" Tasks Completed: # During the twelfth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# (WIP) New QML UI # This week I continued working on the QML-based Engine RPM and Vehicle Speed Gauges and updated the colour scheme and UI elements for the AGL-Demo-Control-Panel.\nThese new widgets are written in QML, being more flexible and versatile will lead to the UI elements being more expressive.\nHere is the reference design shared by the ICS team amd Justin Noel which I\u0026rsquo;m using as refernce for the new UI.\nThe AGL Demo Control Panel will still use PyQt6 for the main application while the new QML elements will be handled by separate modules to be rendered as child QObjects.\n# Implemented keypad features, to execute commands via ssh, added target script bindings. # This week I concluded my work on implementing the Keypad Page, where the keypad buttons makes calls using \u0026ldquo;ssh root@ -c \u0026lsquo;wrapper-script-xyz.sh\u0026rsquo; \u0026quot; on remote host by splicing out the actual commands from momikey into separate scripts that momikey (new) and the ssh calls invoke.\nNext Week Tasks: # Continue working on the new UI elements. Build and test images for the new UI and features. Push changes to Gerrit for review by mentors. ","date":"17 August 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-12/","section":"Blog Posts","summary":"Tasks Completed: # During the twelfth week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel.","title":"Week 12  Progress Report","type":"articles"},{"content":" Tasks Completed: # During the eleventh week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# (WIP) New Gauges # This week I focused on refactoring the Engine RPM and the Vehicle Speed Gauges.\nThese new widgets are written in QML, being more flexible and versatile will lead to the UI elements being more expressive.\nHere is the reference design shared by the ICS team amd Justin Noel which I\u0026rsquo;m using as refernce for the new UI.\nThe AGL Demo Control Panel will still use PyQt6 for the main application while the new QML elements will be handled by separate modules to be rendered as child QObjects.\nThese widget has to be designed from scratch since Qt6 does not support the CircularGauge QML Type.\n# (WIP) Keypad features # This week I continued working on implementing the Keypad Page, where the keypad buttons make calls using \u0026ldquo;ssh root@ -c \u0026lsquo;wrapper-script-xyz.sh\u0026rsquo; \u0026quot; on remote host by splicing out the actual commands from momikey into separate scripts that momikey (new) and the ssh calls invoke.\nNext Week Tasks: # Continue working on the new UI elements and keypad page. Push changes to Gerrit for review by mentors. ","date":"11 August 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-11/","section":"Blog Posts","summary":"Tasks Completed: # During the eleventh week of my Google Summer of Code (GSoC) project, I continued working on refactoring developing the UI elements and the Keypad features for the AGL-Demo-Control-Panel.","title":"Week 11  Progress Report","type":"articles"},{"content":" Tasks Completed: # During the ninth week of my Google Summer of Code (GSoC) project, I made significant strides in implementing the CARLA-CAN-File playback feature within the Automotive Grade Linux (AGL) ecosystem. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# Successfully built the Demo Control Panel image and tested it on RPi4 and Qemu. # This week involved building and texting the AGL Demo Control Panel on actual hardware and testing it\u0026rsquo;s compatibility with other AGL apps.\nTo replicate the build follow the steps to set up your build environment from the AGL Docs.\nThen follow the steps below to build the new Qt6 AGL-Demo-Control-Panel image.\n$ source meta-agl/scripts/aglsetup.sh -m qemux86-64 -b demo-control-panel-qemu agl-demo-control-panel $ ln -sf $AGL_TOP/site.conf conf/ $ source agl-init-build-env $ bitbake agl-demo-control-panel # Working with ICS to improve/ refactor the UX/UI elements in QML. # This week myself and Justin (from ICS) had a discussion in regards to improving the UX/UI for the AGL-Demo-Control-Panel by refactoring part(s) of it to be more legible, aesthetic and intuitive for the end user.\nQML, being more flexible and versatile will lead to the UI elements being more expressive.\nThe AGL Demo Control Panel will still use PyQt6 for the main application while the new QML elements will be handled by separate modules to be rendered as child QObjects.\n# Initial work on keypad features, to execute commands via ssh. # This week I also started work on implementing the Keypad Page, where the keypad page calls \u0026ldquo;ssh root@ -c \u0026lsquo;wrapper-script-xyz.sh\u0026rsquo; \u0026quot; on remote host by splicing out the actual commands from momikey into separate scripts that momikey (new) and the ssh calls invoke.\nNext Week Tasks: # Continue working on the new UI elements and keypad page. ","date":"3 August 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-10/","section":"Blog Posts","summary":"Tasks Completed: # During the ninth week of my Google Summer of Code (GSoC) project, I made significant strides in implementing the CARLA-CAN-File playback feature within the Automotive Grade Linux (AGL) ecosystem.","title":"Week 10 Progress Report","type":"articles"},{"content":" Tasks Completed: # During the ninth week of my Google Summer of Code (GSoC) project, I made significant strides in implementing the CARLA-CAN-File playback feature within the Automotive Grade Linux (AGL) ecosystem. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# Successfully built the Demo Control Panel image and tested it on RPi4 and Qemu. # This week involved building and texting the AGL Demo Control Panel on actual hardware and testing it\u0026rsquo;s compatibility with other AGL apps.\n# Minor Bug fixes and Refactoring. # Fix Playback File selection dropdown not populating when no recorded file is found. Fix Crash for when playback mode is not specified in config.ini Started Refactoring the vehicle_simulator module to simulate tyre pressure readings; CARLA does not provide this data vai APIs. # Code Merged: # 30049: Add Python Script to Convert CARLA data into CAN messages: V1: - Add carla_to_CAN.py script to convert CARLA data into CAN messages - Add README and requirements.txt V2: - Add script to record and playback messages from can interface - Fix mappings to agl-vcar.dbc file V3: - Fix playback feature for record_playback.py - Update requirements.txt - Update README to explain setup and usage of Scripts with CARLA V4: - Add file playback feature to Demo Control Panel - Remove dependency on numpy to calculate vehicle speed, use math lib instead - record_playback.py can now be imported and also be used in standalone mode - Fix: Now data is sent to CAN interface only when it is updated - Fix: Delay is now based on previous timestamp and not the starting timestamp - Fix: Send correct Gear messages, compatible with the agl-vcar signals 30107: Pre-compile resources and remove unused dependencies: V1: - Use rcc to compile qrc resource file on host, and remove post install step to compile on target. - Remove PySide6 as dependency for demo control panel as python3-qtwidgets is no longer used to provide toggle button, and pyside6-rcc is not provided. V2: - Replace PySide6 with PyQt6 at the resouce compile step - Add dynamic layer for meta-qt6 to provide QtWidgets and QtSvg - Update runtime dependencies to provide bash and python3-rich for CLI interface Next Week Tasks: # Work with Justin from ICS to improve the UX/UI elements. Continue working on the New Page to display tyre pressure data. Work on keypad features. ","date":"26 July 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-09/","section":"Blog Posts","summary":"Tasks Completed: # During the ninth week of my Google Summer of Code (GSoC) project, I made significant strides in implementing the CARLA-CAN-File playback feature within the Automotive Grade Linux (AGL) ecosystem.","title":"Week 09 Progress Report","type":"articles"},{"content":" Tasks Completed: # During the eighth week of my Google Summer of Code (GSoC) project, I made significant strides in implementing the CARLA-CAN-File playback feature within the Automotive Grade Linux (AGL) ecosystem. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# Fixed file playback bug for the Control Panel # This week, I refactored the file playback toggle, such that now the playback of recorded CAN messages is executed on a separate QThread, and once the demo is toggled off, the thread process is killed.\nThis was implemented to avoid GUI freezing due to the App and playback being run on a single thread.\n# Implemented the Skeletal Tyre pressure Page # This week I also implemented the new Tyre Pressure Page for the AGL Demo Control Panel.\nWhile it is not currently hooked to any VSS signal, once the signal has been added to the vspec file, I will map the relevant signals to the various widgets on the page.\n# Fixed the \u0026ldquo;Out of Range\u0026rdquo; error for the Transmission signal when CARLA is run in manual mode. # I submitted code changes to Gerrit for review and integration into the AGL demo control panel repository. The specific change can be found here :- 30049: Add Python Script to Convert CARLA data into CAN messages\nThe carla_to_CAN.py script can be run run alongside an existing CARLA simulation to fetch data and convert it into CAN messages based on the agl-vcar.dbc file.\nNOTE: This does not require the CARLA server to be running.\nBug fixes this week:\nThis week\u0026rsquo;s work addressed the edge case where the CARLA hero car is in manual transmission, and the provided int value goes out of range for the 1: Drive signal.\n0 = Neutral (N)\n-1 = Reverse gears (R)\n126 = Park (P)\n127 = Drive (D)\n1/2/3/.. = Manual Forward gears (M)\n30049: Add Python Script to Convert CARLA data into CAN messages\n# Updated Settings Page. # Improved the alignment of toggle toggle elements in the settings page. Added a new dropdown menu to select the playback file. # Resource Compilation # Since there’s no pyrcc6 tool for PyQt6 and pyside6-rcc is not available with PySide6 on the Host and Target while building AGL, We can instead use Qt’s own rcc tool to convert the assets/res.qrc file.\nThe rcc tool is available by default in a full Qt6 installation. Infact, the PySide6 tool , pyside6-rcc locates and runs the Qt6 rcc tool via subprocess, resulting in the same output.\nTo convert the .qrc file, we run the following command:\n$ /usr/lib64/qt6/libexec/rcc -g python assets/res.qrc | sed \u0026#39;0,/PySide6/s//PyQt6/\u0026#39; \u0026gt; res_rc.py Changes pushed to meta-agl-demo include:\nUse rcc to compile qrc resource file on host, and remove post install step to compile on target.\nRemove PySide6 as dependency for demo control panel as python3-qtwidgets is no longer used to provide toggle button, and pyside6-rcc is not provided.\n30107: Pre-compile resources and remove unused dependencies\nNext Week Tasks: # Continue working on the New Page to display tyre pressure data. Build the Demo Control Panel image and test. Start work on keypad features. ","date":"21 July 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-08/","section":"Blog Posts","summary":"Tasks Completed: # During the eighth week of my Google Summer of Code (GSoC) project, I made significant strides in implementing the CARLA-CAN-File playback feature within the Automotive Grade Linux (AGL) ecosystem.","title":"Week 08 Progress Report","type":"articles"},{"content":" Tasks Completed: # During the seventh week of my Google Summer of Code (GSoC) project, I made significant strides in implementing the CARLA-CAN-File playback feature within the Automotive Grade Linux (AGL) ecosystem. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# CARLA Playback # I submitted code changes to Gerrit for review and integration into the AGL demo control panel repository. The specific change can be found here :- 30049: Add Python Script to Convert CARLA data into CAN messages\nConversion of CARLA data to CAN messages # The carla_to_CAN.py script can be run run alongside an existing CARLA simulation to fetch data and convert it into CAN messages based on the agl-vcar.dbc file.\nNOTE: This does not require the CARLA server to be running.\nThis weeks work addressed the incorrect Gear signals. The new values compatible with the agl-vcar are transmission gear (\u0026lsquo;P\u0026rsquo;, \u0026lsquo;R\u0026rsquo;, \u0026lsquo;N\u0026rsquo;, \u0026lsquo;D\u0026rsquo;). Where,\n0 = Neutral (N) 1/2/.. = Forward gears (Applicable when CARLA hero car is in manual transmission) -1/-2/.. = Reverse gears (R) 126 = Park (P) 127 = Drive (D) def send_gear(self, gear): if gear == \u0026#34;P\u0026#34;: data = self.gear_message.encode({\u0026#39;Gear\u0026#39;: 126}) elif gear == \u0026#34;R\u0026#34;: data = self.gear_message.encode({\u0026#39;Gear\u0026#39;: -1, \u0026#39;Gear\u0026#39;: -2}) elif gear == \u0026#34;N\u0026#34;: data = self.gear_message.encode({\u0026#39;Gear\u0026#39;: 0}) elif gear == \u0026#34;D\u0026#34;: data = self.gear_message.encode({\u0026#39;Gear\u0026#39;: 127}) message = can.Message( arbitration_id=self.gear_message.frame_id, data=data) self.can_bus.send(message) Bug fixes this week:\nFix: Now data is sent to CAN interface only when it is updated Fix: Send correct Gear messages, compatible with the agl-vcar signals Remove dependency on numpy to calculate vehicle speed, use math lib instead To convert CARLA data into CAN messages, follow these steps:\n$ python -u carla_to_CAN.py # OR $ python -u carla_to_CAN.py --host \u0026lt;carla_server_ip\u0026gt; --port \u0026lt;carla_server_port\u0026gt; Implemented File Playback via Demo Control Panel # The record_playback.py module now allows file playback using the Control Panel from the ICPage Demo Toggle.\nThis feature can be enabled using the config.ini file for now, with UI option in settings page soon to be implemented.\nThe toggle, by default checks for the recorded CAN signals in the can_messages.txt file.\nFix: Delay is now based on previous timestamp and not the starting timestamp record_playback.py can now be imported and also be used in standalone mode # Updated Resource Compilation Step # Since there’s no pyrcc6 tool for PyQt6 and pyside6-rcc is not available with PySide6 on the Host and Target while building AGL, We can instead use Qt’s own rcc tool to convert the assets/res.qrc file.\nThe rcc tool is available by default in a full Qt6 installation. Infact, the PySide6 tool , pyside6-rcc locates and runs the Qt6 rcc tool via subprocess, resulting in the same output.\nTo convert the .qrc file, we run the following command:\n$ /usr/lib64/qt6/libexec/rcc -g python assets/res.qrc | sed \u0026#39;0,/PySide6/s//PyQt6/\u0026#39; \u0026gt; res_rc.py Next Week Tasks: # Continue Adding support in AGL Demo Control Panel to Playback CAN Dump files. Continue working on New Page to display tyre pressure data. Test CARLA Playback on AGL Apps. ","date":"13 July 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-07/","section":"Blog Posts","summary":"Tasks Completed: # During the seventh week of my Google Summer of Code (GSoC) project, I made significant strides in implementing the CARLA-CAN-File playback feature within the Automotive Grade Linux (AGL) ecosystem.","title":"Week 07 Progress Report","type":"articles"},{"content":" Tasks Completed: # During the sixth week of my Google Summer of Code (GSoC) project, I made significant strides in implementing the CARLA-CAN-File playback feature within the Automotive Grade Linux (AGL) ecosystem. Below, I provide detailed information about the tasks completed, documentation updates, and plans for the upcoming week.\n# CARLA Playback # I submitted code changes to Gerrit for review and integration into the AGL demo control panel repository. The specific change can be found here :- 30049: Add Python Script to Convert CARLA data into CAN messages\nConversion of CARLA data to CAN messages # The carla_to_CAN.py script can be run run alongside an existing CARLA simulation to fetch data and convert it into CAN messages based on the agl-vcar.dbc file.\nNOTE: This does not require the CARLA server to be running.\nTo convert CARLA data into CAN messages, follow these steps:\n$ python -u carla_to_CAN.py # OR $ python -u carla_to_CAN.py --host \u0026lt;carla_server_ip\u0026gt; --port \u0026lt;carla_server_port\u0026gt; Implemented Recording of CAN messages and File Playback # The record_playback.py script is responsible for recording amd playing back the CAN data for later sessions.\nTo use the recording and playback features, execute the script:\n$ python -u record_playback.py # OR $ python -u record_playback.py --interface (or) -i can0 # default vcan0 CLI Options:\n1: Captures CAN messages and writes them into \u0026lsquo;can_messages.txt\u0026rsquo; 2: Replays captured CAN messages 3: Exit # Updated Documentation # In addition to code contributions, I focused on enhancing the AGL documentation related to CARLA and the demo control panel. The following updates were made:\nAGL Demo Control Panel Documentation: I revised the existing documentation to reflect the transition to Qt6. Clarified usage instructions and provided examples for better understanding. CARLA Integration with AGL Documentation: I created new documentation specifically addressing the integration of CARLA with AGL. Highlighted use cases and provided step-by-step setup instructions. The code changes related to documentation updates can be found here :- 30097: GSoC \u0026lsquo;24 Add and Update Documentation for CARLA and Demo Control Panel\nNext Week Tasks: # Continue Adding support in AGL Demo Control Panel to Playback CAN Dump files. Continue working on New Page to display tyre pressure data. Test CARLA Playback on AGL Apps. ","date":"6 July 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-06/","section":"Blog Posts","summary":"Tasks Completed: # During the sixth week of my Google Summer of Code (GSoC) project, I made significant strides in implementing the CARLA-CAN-File playback feature within the Automotive Grade Linux (AGL) ecosystem.","title":"Week 06 Progress Report","type":"articles"},{"content":" Tasks Completed: # # Code Merged this week: # 29992: Update Dockerfile for PyQt6 Compatibility. 29969: Port AGL Demo Control Panel to Qt6. # Kuksa-client # This kuksa-client was bumped up from 0.4.2 to 0.4.3.\n# carla_to_CAN # This week I pushed 30049: (WIP) Add Python Script to Convert CARLA data into CAN messages.\nThe carla_to_CAN.py script can be run run alongside an existing CARLA simulation to fetch data and convert it into CAN signals.\nSteps to set up # python3.8 -m venv carlaenv source carlaenv/bin/activate pip3 install -r requirements.txt Steps to run # ./vcan.sh # To set up the vcan0 interface python -u carla_to_CAN.py # OR python -u carla_to_CAN.py --host \u0026lt;carla_server_ip\u0026gt; --port \u0026lt;carla_server_port\u0026gt; These CAN messages can now be written into the Playback text file, which will be read by the AGL-Demo-Control-Panel for the playback feature.\nNext Week Tasks: # (WIP) New page for tyre pressure readings. Add support in AGL Demo Control Panel to Playback CAN Dump files. Test and debug the AGL Demo Control Panel. Prepare for mid-term evaluation. ","date":"28 June 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-05/","section":"Blog Posts","summary":"Tasks Completed: # # Code Merged this week: # 29992: Update Dockerfile for PyQt6 Compatibility.","title":"Week 05 Progress Report","type":"articles"},{"content":" Tasks Completed: # # New Animations # This week I made significant changes to the UI elements and animations of the AGL Demo Control Panel to make it more responsive optimized.\nChanges can be reviewed here in 29969: Port AGL Demo Control Panel to Qt6\nToggle Button # This week I rewrote the animatedToggle.py module to remove dependency on the qtwidgets library (Not compatible with Qt6 yet).\nNavigation Bar # The Navigation Bar Animation was also updated to have Bounce effect using \u0026ldquo;OutBounce\u0026rdquo; QEasingCurve.\n# Converting Data from CARLA to CAN messages # This Week I modified the manual_control.py module from the CARLA Python API examples programs to convert the extracted data into their equivalent CAN format using the agl-vcar.dbc file.\nclass convert_to_can(object): def __init__(self): self.db = cantools.database.load_file(\u0026#39;test.dbc\u0026#39;) self.can_bus = can.interface.Bus(\u0026#39;vcan0\u0026#39;, bustype=\u0026#39;socketcan\u0026#39;) self.speed_message = self.db.get_message_by_name(\u0026#39;Vehicle_Status_1\u0026#39;) self.gear_message = self.db.get_message_by_name(\u0026#39;Transmission\u0026#39;) self.speed_cache = 0 self.steer_cache = 0 self.gear_cache = \u0026#34;P\u0026#34; def send_car_speed(self, speed): if int(speed) != int(self.speed_cache): if(int(speed) != 0): self.send_gear(\u0026#34;D\u0026#34;) else: self.send_gear(\u0026#34;P\u0026#34;) self.speed_cache = speed data = self.speed_message.encode({\u0026#39;CAR_SPEED\u0026#39;: speed}) message = can.Message(arbitration_id=self.speed_message.frame_id, data=data) self.can_bus.send(message) . . . . Next week I will continue working on and writing it into a CAN-dump file along with its timestamp for playback purposes.\nThis CAN dump file will be used by the AGL Demo Control Panel to feed data into the CAN interface using python-can.\nNext Week Tasks: # Continue work on file playback using CARLA. Add support in AGL Demo Control Panel to Playback CAN Dump files. Continue working on New Page to display tyre pressure data. Bump up kuksa-client from 0.4.2 to 0.4.3 (Latest). ","date":"23 June 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-04/","section":"Blog Posts","summary":"Tasks Completed: # # New Animations # This week I made significant changes to the UI elements and animations of the AGL Demo Control Panel to make it more responsive optimized.","title":"Week 04 Progress Report","type":"articles"},{"content":" Tasks Completed: # # Updated Docker File # This week I Updated the Dockerfile to support the PyQt6 version of the AGL Demo Control Panel.\n29992: Update Dockerfile for PyQt6 Compatibility\nUpdate packages required to run PyQt6 apps in Debian base. Update set up script to compile resources. Use Python venv to resolve requirements to avoid native package conflicts. # Replaced the Animated Toggle Button # I also replaced the Animated Toggle button with a new checkbox like button to provide the On and Off states of the toggle controls for Settings Page \u0026amp; the IC Page (Demo Toggle)\n# WIP: Using CARLA APIs to Write Out CAN files # Last week, I created the carla_to_CAN.py script, which works in parallel with the manual_control.py or start_replaying.py scripts. It listens to the CARLA server, fetches the required ego vehicle data, and prints it to the console.\nI referred to the existing CARLA Python API example scripts and the official documentation for the various APIs used in this script.\nThe data currently being pulled and reported to the console are:\nVehicle Speed Throttle Data Left Indicator Status Right Indicator Status Gear Selection This week I was able to convert the extracted data into equivalent CAN signals and push it into the local can0 interface.\nNext week I will continue working on and writing it into a CAN-dump file along with its timestamp for playback purposes.\nThis CAN dump file will be used by the AGL Demo Control Panel to feed data into the CAN interface using python-can.\nFor converting the required data into CAN Frames, I\u0026rsquo;m using the agl-vcar.dbc file as a reference.\nNext Week Tasks: # Continue work on file playback using CARLA. Push changes made to Animated Toggle button on Gerrit. Add new signals to fetch tyre pressure. ","date":"16 June 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-03/","section":"Blog Posts","summary":"Tasks Completed: # # Updated Docker File # This week I Updated the Dockerfile to support the PyQt6 version of the AGL Demo Control Panel.","title":"Week 03 Progress Report","type":"articles"},{"content":" Tasks Completed: # # Changes Pushed to Gerrit this Week # This week I made a few revisions to last week\u0026rsquo;s commit 29969: Port AGL Demo Control Panel to Qt6 based on code review in two patches:\nPatch 2 - Refactored set_icon function in Dashboard module to make use of QIcon directly instead of using the QtSvg library (Invalid in PyQt6) - Syntax changes in UI_Handeler to use PyQt6 Patch 3 - Update gitignore - Remove dependency on qtpy # Pulling Data from CARLA APIs for Recording and Playback Sessions. # This week, I created the carla_to_CAN.py script, which works in parallel with the manual_control.py or start_replaying.py scripts. The script listens to the CARLA server, fetches the required ego vehicle data, and prints it to the console.\nI referred to the existing CARLA Python API example scripts and the official documentation for the various APIs used in this script.\nThe data currently being pulled and reported to the console are:\nVehicle Speed Throttle Data Left Indicator Status Right Indicator Status Gear Selection Tasks in Progress: # # Write out data file for playback # This part of carla_to_CAN.py is still a work in progress. We are converting the extracted data into equivalent CAN signals and writing it into a CAN-dump file along with its timestamp for playback purposes.\nThis CAN dump file will be used by the AGL Demo Control Panel to feed data into the CAN interface using python-can.\nFor converting the required data into CAN Frames, I\u0026rsquo;m using the agl-vcar.dbc file as a reference.\n# Update Docker File # I have also started updating the Docker File to run the Qt6 port of the Control Panel properly, resolving all dependencies.\nNext Week Tasks: # Continue work on file playback using CARLA Push updated Docker File Add new signals to fetch tyre pressure ","date":"9 June 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-02/","section":"Blog Posts","summary":"Tasks Completed: # # Changes Pushed to Gerrit this Week # This week I made a few revisions to last week\u0026rsquo;s commit 29969: Port AGL Demo Control Panel to Qt6 based on code review in two patches:","title":"Week 02 Progress Report","type":"articles"},{"content":" # Migrated from PyQt5 to PyQt6/PySide6. # This week, our focus was on porting the UI framework of the AGL Demo Control Panel from Qt5 to Qt6. The migration process was relatively straightforward since the syntax changes between PyQt5 and PyQt6 are minimal.\n# Patched Animated Toggle Module to work with PyQt6. # In the previous version of the Control Panel, we relied on the ‘qtwidgets’ module to render animated toggle switches. However, this package did not support PyQt6 out of the box. To address this, I extracted the relevant module and patched it to work with the Qt6 framework. Instead of relying on qtpy (a Python library that abstracts various Qt APIs), we now use native PyQt6 components.\n# Updated the README. # I also updated the README file to include new instructions for compiling the PyQT6 resources. While this change was minor, I still need to update other instructions to fully reflect recent modifications.\n# Conclusion # All the code changes have been pushed to Gerrit. Additionally, We’ve created a new JIRA issue to track this year’s contributions under GSoC 2024.\nGerrit: 29969: Port AGL Demo Control Panel to Qt6 JIRA: SPEC-5161 - GSoC: Extend AGL Demo Control Panel # What Next? # Implement improved UX/UI. Utilize CARLA APIs for recording and playback sessions. Discuss the CARLA server setup intent with mentors. ","date":"2 June 2024","externalUrl":null,"permalink":"/articles/gsoc24/week-01/","section":"Blog Posts","summary":"# Migrated from PyQt5 to PyQt6/PySide6.","title":"Week 01 Progress Report","type":"articles"},{"content":"","date":"20 May 2024","externalUrl":null,"permalink":"/tags/community-bonding-period/","section":"Tags","summary":"","title":"Community Bonding Period","type":"tags"},{"content":" What is GSoC \u0026amp; What Have I Been Up To During The CBP? # Google Summer of Code (GSoC) is a global program that offers students an opportunity to contribute to open-source projects. The program is sponsored by Google and has been running since 2005. The program aims to bring together students and open-source organizations to work on real-world projects. The program has three phases: the community bonding period, the coding period, and the final evaluation period.\nThe community bonding period is the three weeks between GSoC student acceptance and the start of the coding date (1st - 26th May ). During this period I engaged with my GSoC mentors, Jan-Simon Möller ,Walt Miner, Scott Murray, Marius Vlad, Justin Noel and the rest of the AGL community. I used this period to get familiar with the various tools used in AGL and set up my work environment for the coding period. This also allowed me to better understand the requirements of my project.\nI also participated in the AGL Weekly Dev Meet events to better understand the work done at AGL and its various technical groups.\nWhat\u0026rsquo;s the Goal for GSoC \u0026lsquo;24? # I\u0026rsquo;m be participating in a Google Summer of Code (GSoC 2024) as a contributor again this year, where I will extend up my previous year\u0026rsquo;s GSoC ‘23 project on the AGL Demo Control Panel.\nMy tasks for this year\u0026rsquo;s contribution include:\nPorting the app from Qt5 to Qt6 Adding file playback capability using CARLA Visualise signals (real-time and playback) Integrating new controls and keypad features Implementing an IC keypad, and developing a power-control feature -\u0026gt; For a detailed review of my GSoC \u0026lsquo;24 Proposal, click here.\nSetting Up # On our weekly GSoC meetings during the bonding period, we had detailed discussions regarding this years project, where we discussed:\nQt6 support for AGL: Work in progress, I revied the Sandboxed progress. ICS\u0026rsquo;s contribution to the UI/UX side of the AGL Demo Control Panel POA of adding file playback using CARLA Python APIs Reviewing all the patches made to the control panel since GSoC \u0026lsquo;23 compleatoin: 29910: Simplify server configuration 29911: Add ability to disable HVAC and steering wheel pages 29912: Improve vehicle simulator CARLA # During the CBP, my focus was on reviewing the documentation for CARLA and reviewing it\u0026rsquo;s various Python APIs.\nConfiguration # Running headless server:\n./CarlaUE4.sh -quality-level=Low -prefernvidia -RenderOffScreen # What Next? # Initial work on porting the AGL Demo Control Panel from Qt5 to Qt6. Start work on a demo CARLA script to pull ego vehicle data. ","date":"20 May 2024","externalUrl":null,"permalink":"/articles/gsoc24/community-bonding-period/","section":"Blog Posts","summary":"What is GSoC \u0026amp; What Have I Been Up To During The CBP?","title":"GSoC 2024 Community Bonding Period","type":"articles"},{"content":"","date":"31 October 2023","externalUrl":null,"permalink":"/tags/gsoc-2023/","section":"Tags","summary":"","title":"GSoC 2023","type":"tags"},{"content":" Introduction # This report is a requirement of the Final evaluation phase of the Google Summer of Code the Google program. I worked with the Linux Foundation, under Automotive Grade Linux to develop a Qt5 Application to Visualise/ Simulate CAN bus traffic using Kuksa.val\nYou can find the proposal for this project here.\nThe Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux. Automotive Grade Linux is an open-source project hosted by The Linux Foundation that is building an open operating system and framework for automotive applications.\nProject Overview # The objective of this project was to develop a Qt5 application that simulates CAN bus traffic using Kuksa.val to integrate with the AGL Demo platform. The application developed allows the end-users to emit signals using the kuksa-client SDK and Python-can to visualize and interact with AGL Demo applications, such as the IC, IVI, HVAC, and the Green Machine, that display CAN data through Kuksa.val.\n# Source Code \u0026amp; Documentation # → Gerrit: agl-demo-control-panel\n→ GitHub: AGL_Demo_Control_Panel\n→ Documentation: AGL/documentation\n# Deliverables # Building a modern Qt5 application using PyQt5/QML that can simulate CAN-Bus signals using kuksa.val. Integrate the application with the AGL Demo platform. Packaging and distribution of the Application. Update documentation pages based on work. Work Done # # Progress Reports # → Community Bonding Period: During the GSoC 2023 community bonding period, I had a fantastic learning experience. I got to know my GSoC mentors and the AGL community, familiarized myself with AGL tools, and set up my working environment. I also tackled some technical challenges and ventured into working with Kuksa-val-server, Kuksa-client, and AGL images. Overall, the community bonding period was a great start.\n→ Coding Period: The coding period of GSoC is a dedicated timeframe during which the accepted contributors work on their projects. The standard coding period is 12 weeks. However, my mentors and I saw it fit to have a longer coding period of 22 weeks to complete our Large-Scale project.\nDuring this period, I was able to:\nWrite and submit my code to Gerrit/GitHub. Issue patches and bug fixes based on review. Regularly communicate with my mentors. (Mondays) Participate in the AGL and GSoC community. (Thursdays) Submit my work for mid-term and final evaluations. Below I have compiled all my Weekly Progress Reports for the duration of the coding period of GSoC \u0026lsquo;23.\nWeek 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Week 11 Week 12 Week 13 Week 14 Week 15 Week 16 Week 17 Week 18 Week 19 Week 20 Week 21 Week 22 # Major Gerrit Commits # 29339: agl-demo-control-panel: Improve gRPC Mode 29311: agl-demo-control-panel: Add Fullscreen / maximized option 29302: agl-demo-control-panel: Save user preferences for next session 29291: agl-demo-control-panel: Fix Svg icons scaling on Dashboard 29279: agl-demo-control-panel: Refactor Settings, Config and UI scaling 29275: agl-demo-control-panel: Add installation steps for debian/RPiOS 29270: agl-demo-control-panel: Add grpc support for databroker 29060: Upload progress on AGL demo control panel in one batch Conclusion # # What did I learn? # I was able to learn about the OpenEmbedded Yocto Project and create layers and recipes for our specific application. I learnt how to create quality applications using Qt, PyQt. Learnt about gRPC and WebSocket and how they are implemented in Kuksa.val and its Python SDK. I had the opportunity to test my application and AGL images on a Raspberry Pi 4 kindly provided by my AGL mentors. I was also provided a pair of CAN to USB adapters for testing CAN signals. While we ended up not using it for our demo it did help me learn more about CAN interfaces, Linux kernel modules, and Python-can. I was also able to test my application using the agl-ivi-demo-control-panel image on ARM, X86 using QEMU/KVM. Additionally, we also got a docker image to work for the agl-demo-control-panel thanks to Lisandro Pérez Meyer. I also learned a lot more about the Automotive Grade Linux organization, its development tools, workflow, and pipeline. # Post GSoC # I plan to maintain and add to the Automotive Grade Linux’s repository for my project for the foreseeable future and work on continually improving it. I will keep contributing and help other new contributors to explore and learn projects in this organization. Acknowledgments # I would like to express my gratitude to my mentors Jan-Simon Möller, Scott Murray, Marius Vlad, and Walt Miner for mentoring me through GSoC and also to the whole AGL community for being so inclusive and friendly.\nIt has been one of the best professional experiences that I have had this year. Learning about new tools and technologies, and working on an open-source project along with experienced developers from all over the world has been a great experience for me. I would love to continue working with AGL, improving my project, and whatever I feel that I can contribute to.\n","date":"31 October 2023","externalUrl":null,"permalink":"/articles/final-report/","section":"Blog Posts","summary":"Introduction # This report is a requirement of the Final evaluation phase of the Google Summer of Code the Google program.","title":"GSoC 2023 Final Report","type":"articles"},{"content":"","date":"28 October 2023","externalUrl":null,"permalink":"/tags/gsoc-23-wpr/","section":"Tags","summary":"","title":"GSoC '23 WPR","type":"tags"},{"content":" # Topics To Be Covered In This Post # What I did this week Pushing code and bug fixes to Gerrit. Added flag in config file to start control panel in full-screen mode. Added persistent user configurations. Updated documentation and Readme file. Created the first draft of the final GSoC report. What I plan to do next # Pushing to Gerrit # This week, major work was completed for the AGL Demo Control Panel and commits were made for review on Gerrit. The following changes and bug fixes were pushed this week:\n29291: agl-demo-control-panel: Fix Svg icons scaling on Dashboard | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29291 (merged) 29300: agl-demo-control-panel: Fix circular import problem | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29300 (merged) 29302: agl-demo-control-panel: Save user preferences for next session | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29302 (merged) 29303: agl-demo-control-panel: Fix typo in docker installation script | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29303 (merged) 29311: agl-demo-control-panel: Add Fullscreen / maximized option | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29311 (merged) 29339: agl-demo-control-panel: Improve grpc connection | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29339 Full-screen Mode # This week I added a flag in the default config.ini file to:\nMaximize the window at start up Hide the window controls since In the dedicated AGL and Docker image, the control panel will be the only application running, and it should not be possible to minimize or close it. Disable the curved window corners. This avoids needing to worry about the background color showing up in the corners and potentially needing to get a custom Weston configuration file in place to avoid the default background. User Preference # This week I also added the ability to save user preferences for the next session, thereby making the preferred configuration persist across sessions. The user preference is now saved in the format given below every time the user attempts a connection with the provided fields.\n1 [default] 2 preferred-config=user-session 3 fullscreen-mode=true 4 5 [user-session] 6 ip = 7 port = 8 protocol = 9 insecure = 10 tls_server_name = 11 token = default 12 cacert = default 13 14 # [cutom-config-template] 15 # ip=\u0026lt;ip address\u0026gt; 16 # port=\u0026lt;port number\u0026gt; 17 # protocol=\u0026lt;ws|grpc\u0026gt; # ws/grpc -\u0026gt; kuksa-val-server, # grpc -\u0026gt; databroker 18 # insecure=\u0026lt;true|false\u0026gt; # Use insecure mode only if server # is also running in insecure mode 19 # cacert=\u0026lt;default|/path/to/CA.pem\u0026gt; 20 # token=\u0026lt;default|/path/to/token\u0026gt; 21 # tls_server_name=\u0026lt;name\u0026gt; # What Next? # Issue bug fixes as required. Final submission of the GSoC project for evaluation. Finalize the final report for GSoC. ","date":"28 October 2023","externalUrl":null,"permalink":"/articles/week-22/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Pushing code and bug fixes to Gerrit.","title":"Week 22 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Pushing code and bug fixes to Gerrit Tweaked UI to simplify and make text more legible. Fixed SVG icon scaling issues in the dashboard (Updated Docker file to resolve dependencies) Refactored subscription updates (UI updates are blocked when sending values to Kuksa). Update documentation and Readme file. What I plan to do next # Pushing to Gerrit # This week, major work was completed for the AGL Demo Control Panel and commits were made for review on Gerrit. The following changes have been pushed so far:\nChanges pushed so far:\n29279: agl-demo-control-panel: Refactor Settings, Config and UI scaling | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29279 (merged) 29291: agl-demo-control-panel: Fix Svg icons scaling on Dashboard | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29291 29292: agl-demo-control-panel: Update documentation | https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/29292 Bug Fixes # This week I patched a small bug where setting the temperature values would cause an exception/crash when going beyond the min/max values available. The bug was reported in SPEC-4939. I also patched the scaling issue of the SVG icons for the dashboard of the control panel using the QtSvg module of PyQt5, however on Debian-based systems, this sub-module is only available through the python3-PyQt5.QtSvg package. Fixed a bug where new-config would not be created due to a key error when stating the client in the AGL-kuksa-val-server config. UI Tweaks # Increased DejaVu font sizes for QLabels and QPushButtons to make the text more legible. Removed QScrollbar components to better adjust to smaller screens and remove clipped borders in QStacked widget frames. Start/Stop button was redone to help manage sessions of the client more easily. The client is now stops when AGL_Demo_Control_Panel is closed using the window controls. Refactored Kuksa Subscription # This week I also refactored the way subscribed updates are handled in the control panel, previously the application would both subscribe to any changes made to a signal and also set the updated values, and since the new values set on the control panel trigger a send_values function when an event occurs, the values would be set twice.\nThis week I refactored by making use of pyqtsignals and slotted functions which not only help in sending interpreters communication between modules but also threads. Now whenever the values are being set by the control panel, all updates made via the subscription module are blocked temporarily. This helps remove the jittery feeling in the sliders when setting new values.\nDocumentation and README # This week I also updated the documentation and README to include updated screen-shots, installation, and setup processes. This included,\nUpdate installation steps. Steps to including/defining custom config files (.ini) and where to place them. Fix typos in the assets directory name. # What Next? # Issue bug fixes as required. Continue pushing code and documentation to Gerrit. Prepare for the final submission of the GSoC project evaluation. ","date":"23 October 2023","externalUrl":null,"permalink":"/articles/week-21/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Pushing code and bug fixes to Gerrit Tweaked UI to simplify and make text more legible.","title":"Week 21 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Pushing code to Gerrit. Added drop-down in settings to pick configs. Refactored config.py and settings.py to handle user preferences better. What I plan to do next # Pushing to Gerrit # This week, major work was completed for the AGL Demo Control Panel and commits were made for review on Gerrit. The following changes have been pushed so far:\nChanges pushed so far:\n29255: agl-demo-control-panel: Update and add new assets | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29255 (merged) 29270: agl-demo-control-panel: Add grpc support for databroker | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29270 (merged) 29279: agl-demo-control-panel: Refactor Settings, Config and UI scaling | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29279 User preference # The settings page saw the inclusion of new parameters for the user to configure including\nPort: No longer hard-coded into the application. AGL\u0026rsquo;s CA.pem (Toggle): Optional parameter if the user wants to test on local builds of databroker and kuksa-val-server. Drop-down combo box to pick default configs specified in config.ini. Config # The default configuration is no longer loaded into the settings page by the config.py module, instead, it acts as a relay module to parse the user\u0026rsquo;s preferred configuration(s) specified in the config.ini file.\nThe new implementation allows the user to reconnect to a different instance of the kuksa server(s) seamlessly, as the new config is loaded and fed to the kuksa_instance.py module based on the state of the parameters of the settings page.\nUI Tweaks # The main UI of the AGL Demo Control Panel saw some quality and functional changes this week, including:\nGrab handle is now available at the bottom-right of the main window to help resize the window. Settings page was revised to follow a 2 column layout to make the preferences more accessible and legible. # What Next? # Improve handling for script toggle for IC page. Update documentation. Continue pushing code to Gerrit and issue patched as required. ","date":"16 October 2023","externalUrl":null,"permalink":"/articles/week-20/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Pushing code to Gerrit.","title":"Week 20 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Pushing code to Gerrit. Refactor acceleration and script for IC page. Add compatibility for Databroker. What I plan to do next # Pushing to Gerrit # This week, major work was completed for the AGL Demo Control Panel and commits were made for review on Gerrit. The following changes have been pushed so far:\nChanges pushed so far:\n29255: agl-demo-control-panel: Update and add new assets | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29255 (In review) 29270: agl-demo-control-panel: Add grpc support for databroker | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29270 IC acceliration and Script # The IC script and the acceleration function triggered by the controls in the IC page were refactored to better show the acceleration and deceleration of a car. The triggers for the Cruise controls for the Steering Controls page were also reworked. The IC Widget module now uses a Virtual car to simulate acceleration and deceleration, for the Instrument Cluster app when the Demo Mode is toggled.\nDatabroker # This week, grpc/databroker support was added to the AGL demo control panel. This included:\nUsing specific JWT tokens for grpc and ws protocols. Making grpc the default protocol for the control panel. Patching an issue where the client keeps disconnecting while using grpc. # What Next? # Improve handling for script toggle for IC page. Update documentation. Continue pushing code to Gerrit and issue patched as required. ","date":"9 October 2023","externalUrl":null,"permalink":"/articles/week-19/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Pushing code to Gerrit.","title":"Week 19 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Pushing code to Gerrit. Simplified settings page. Add compatibility for Databroker. Refactor acceleration and script for IC page. What I plan to do next # Pushing to Gerrit # This week saw major documentation work for the AGL Demo Control Panel and partial commits were made for review on Gerrit.\nChanges pushed so far:\n29237: Update UI files | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29237 (Merged) 29243: agl-demo-control-panel: Upload Draft 1 documentation | https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/29243 (Merged) 29255: agl-demo-control-panel: Update and add new assets | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29255 (In review, merge conflict due to renaming of CA.pem file) Settings Page # This week I worked to simplify the settings page and add new icons to better shop connection to the server, auto-refresh the status after the reconnect button is pressed, and better showcase the available options for the Steering wheel signals.\nDatabroker # This week I also added initial support for databroker. This is still a work in progress and even though the client is successfully authorized, the connection drops.\nEnable Secure Connection on Target # databroker --address 0.0.0.0 --tls-cert /etc/kuksa-val/Server.pem --tls-private-key /etc/kuksa-val/Server.key --jwt-public-key /usr/lib/python3.10/site-packages/kuksa_certificates/jwt/jwt.key.pub --vss /usr/share/vss/vss_rel_3.1.1-agl.json Connecting to Databroker Secure Mode # kuksa-client --cacertificate /home/suchinton/Repos/AGL_Demo_Control_Panel/assets/CA.pem --tls-server-name Server --protocol grpc --ip 10.42.0.95 --port 55555 kuksa-client --cacertificate /etc/kuksa-val/CA.pem --tls-server-name Server --protocol grpc --ip 10.42.0.95 --port 55555 Test Client\u0026gt; authorize eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJsb2NhbCBkZXYiLCJpc3MiOiJjcmVhdGVUb2tlbi5weSIsImF1ZCI6WyJrdWtzYS52YWwiXSwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE3NjcyMjU1OTksInNjb3BlIjoiYWN0dWF0ZSBwcm92aWRlIn0.x-bUZwDCC663wGYrWCYjQZwQWhN1CMuKgxuIN5dUF_izwMutiqF6Xc-tnXgZa93BbT3I74WOMk4awKHBUSTWekGs3-qF6gajorbat6n5180TOqvNu4CXuIPZN5zpngf4id3smMkKOT699tPnSEbmlkj4vk-mIjeOAU-FcYA-VbkKBTsjvfFgKa2OdB5h9uZARBg5Rx7uBN3JsH1I6j9zoLid184Ewa6bhU2qniFt5iPsGJniNsKsRrrndN1KzthO13My44s56yvwSHIOrgDGbXdja_eLuOVOq9pHCjCtorPScgEuUUE4aldIuML-_j397taNP9Y3VZYVvofEK7AuiePTbzwxrZ1RAjK74h1-4ued3A2gUTjr5BsRlc9b7eLZzxLJkrqdfGAzBh_rtrB7p32TbvpjeFP30NW6bB9JS43XACUUm_S_RcyI7BLuUdnFyQDQr6l6sRz9XayYXceilHdCxbAVN0HVnBeui5Bb0mUZYIRZeY8k6zcssmokANTD8ZviDMpKlOU3t5AlXJ0nLkgyMhV9IUTwPUv6F8BTPc-CquJCUNbTyo4ywTSoODWbm3PmQ3Y46gWF06xqnB4wehLscBdVk3iAihQp3tckGhMnx5PI_Oy7utIncr4pRCMos63TnBkfrl7d43cHQTuK0kO76EWtv4ODEHgLvEAv4HA Configuration in Control Panel # import os import platform python_version = f\u0026#34;python{\u0026#39;.\u0026#39;.join(platform.python_version_tuple()[:2])}\u0026#34; CA = os.path.abspath(os.path.join(os.path.dirname(__file__), \u0026#34;../assets/cert/CA.pem\u0026#34;)) KUKSA_CONFIG = { \u0026#34;ip\u0026#34;: \u0026#39;10.42.0.95\u0026#39;, \u0026#34;port\u0026#34;: \u0026#34;8090\u0026#34;, \u0026#39;protocol\u0026#39;: \u0026#39;ws\u0026#39;, \u0026#39;insecure\u0026#39;: False, \u0026#39;cacertificate\u0026#39;: CA, \u0026#39;tls_server_name\u0026#39;: \u0026#34;Server\u0026#34;, } WS_TOKEN = os.path.join(os.path.expanduser(\u0026#34;~\u0026#34;), f\u0026#34;.local/lib/{python_version}/site-packages/kuksa_certificates/jwt/super-admin.json.token\u0026#34;) GRPC_TOKEN = os.path.abspath(os.path.join(os.path.dirname(__file__), \u0026#34;../assets/token/grpc/actuate-provide-all.token\u0026#34;)) Note: the config only holds the default configuration, changes made in preference of protocol, SSL (insecure) mode, and jwt token are handled by the settings module.\nIC acceliration and Script (WIP) # This week I also started refactoring the IC script and the acceleration function triggered by the controls in the IC page to better show the acceleration and deceleration of a car, also reworking the triggers for the Cruise controls for the Steering Controls page.\n# What Next? # Continue testing Continue work on supporting databroker Continue pushing code to Gerrit and issue patched as required. ","date":"27 September 2023","externalUrl":null,"permalink":"/articles/week-18/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Pushing code to Gerrit.","title":"Week 18 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Pushing code to Gerrit. Fixing scaling of Dashboard icons. Completed initial draft of documentation. What I plan to do next # Pushing to Gerrit # This week saw major documentation work for the AGL Demo Control Panel and partial commits were made for review on Gerrit.\nChanges pushed so far:\n29237: Update UI files | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29237 29243: agl-demo-control-panel: Upload Draft 1 documentation | https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/29243 # Testing Qt IVI # This week when testing the Qt IVI image on the Pi I noticed that the can0 interface does not show when using the shell, however, I am still able to configure the can0 interface and cannelloni and kuksa by ssh-ing into the image.\n# Fixing the scaling issue # This week I also made a minor fix for the scaling issue of the Dashboard icons for the control panel by using QPainter to scale up the images.\n# What Next? # Continue testing Add databroker support Continue pushing code to Gerrit and issue patched as required. ","date":"25 September 2023","externalUrl":null,"permalink":"/articles/week-17/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Pushing code to Gerrit.","title":"Week 17 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Pushed partial code to Gerrit for review. Completed initial documentation. Resolved minor bugs and UI tweaks. Refactored code wherever needed. What I plan to do next # Pushing code to Gerrit # This week saw major refactoring and documentation of the code for the AGL Demo Control Panel and partial commits were made for review on Gerrit.\nChanges pushed so far:\n29189: Update Resources and Requirements | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29189 29196: Update extra modules | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29196 29190: Update default config | https://gerrit.automotivelinux.org/gerrit/c/src/agl-demo-control-panel/+/29190 # Initial Documentation # I took the time to document each module in the code base, explaining its features and usage. The next week, these changes will be submitted to Gerrit.\nI also began working on the documentation that would be released to AGL\u0026rsquo;s official docs, to create a comprehensive resource that defines the project\u0026rsquo;s overview, technical features, setup techniques, and usage instructions.\n# UI tweaks and Bug fixes # Sliders for the Instrument Cluster page were made wider and spaced out to enable easier touch controls. QSS styling for widgets was redone to better show hower, click, and push events. Resolved dependency naming and path in the res.qrc file. # VSS subscription # I also refactored the VSS subscription module by merging it with the UI_Handler module to resolve circular imports and avoid complications. The list of subscribed VSS Paths was also updated to include:\n\u0026ldquo;Vehicle.Speed\u0026rdquo; \u0026ldquo;Vehicle.Powertrain.CombustionEngine.Speed\u0026rdquo; \u0026ldquo;Vehicle.Body.Lights.DirectionIndicator.Left.IsSignaling\u0026rdquo; \u0026ldquo;Vehicle.Body.Lights.DirectionIndicator.Right.IsSignaling\u0026rdquo; \u0026ldquo;Vehicle.Body.Lights.Hazard.IsSignaling\u0026rdquo; \u0026ldquo;Vehicle.Powertrain.FuelSystem.Level\u0026rdquo; \u0026ldquo;Vehicle.Powertrain.CombustionEngine.ECT\u0026rdquo; \u0026ldquo;Vehicle.Powertrain.Transmission.SelectedGear\u0026rdquo; \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Left.Temperature\u0026rdquo; \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Left.FanSpeed\u0026rdquo; \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Right.Temperature\u0026rdquo; \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Right.FanSpeed\u0026rdquo; After validating the app\u0026rsquo;s functionality in the target environment, any changes issued to these signals will be reflected on the GUI.\nNote: It is a known issue that every time the call-back function receives an update the value is updated again (double setting), but this will be resolved by simply adding flags in a later patch to the UI_Handler module.\n# What Next? # Continue pushing code to Gerit and issue patched as required. Start preparing the final report for GSoC. ","date":"16 September 2023","externalUrl":null,"permalink":"/articles/week-16/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Pushed partial code to Gerrit for review.","title":"Week 16 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week First draft of the \u0026ldquo;AGL Demo Control Panel\u0026rdquo; documentation. Minor Adjustments to UI Simplified Settings Page. Refactoring the VSS subscription Module What I plan to do next # First draft of the \u0026ldquo;AGL Demo Control Panel\u0026rdquo; documentation. # I started writing the initial draft of the documentation for AGL Demo Control Panel by following the steps provided in the official documentation of AGL.\ncloning the docs # git clone \u0026#34;ssh://suchinton2001@gerrit.automotivelinux.org:29418/AGL/documentation\u0026#34; \u0026amp;\u0026amp; scp -p -P 29418 suchinton2001@gerrit.automotivelinux.org:hooks/commit-msg \u0026#34;documentation/.git/hooks/\u0026#34; Building a local site # Change into the directory\n$ cd documentation Install MkDocs and rtd-dropdown theme\n$ sudo pip install -r requirements.txt Serve locally (default rendered at 127.0.0.1:8000/):\n$ sudo mkdocs serve The documentation for AGL Demo Control Panel will be found under 06 Component Documentation after it has been reviewed and merged.\n# Minor Adjustments to UI # Sliders for the Instrument Cluster page were made wider and spaced out to enable easier touch controls. QSS styling for widgets was redone to better show hower, click, and push events. Resolved dependency naming and path in the res.qrc file. # Simplified Settings Page. # This week I also simplified the steps to enable a connection with the server to just two buttons where the Reconnect and Refresh buttons have now been merged into one and the UI no longer hangs while the client connects to the server.\n# Refactoring VSS subscription Module # This week I also refactored the VSS subscription module to use the subscribe method from the kuksa-client and updated the control panel widgets to show values accurately whenever a change is registered.\nVSS Paths the are subscribe to are:\nVehicle Speed: \u0026ldquo;Vehicle.Speed\u0026rdquo; Engine RPM: \u0026ldquo;Vehicle.Powertrain.CombustionEngine.Speed\u0026rdquo; Fuel Level: \u0026ldquo;Vehicle.Powertrain.FuelSystem.Level\u0026rdquo; Coolant Temp: \u0026ldquo;Vehicle.Powertrain.CombustionEngine.ECT\u0026rdquo; Left Temp: \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Left.Temperature\u0026rdquo; Left Fan Speed: \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Left.FanSpeed\u0026rdquo; Right Temp: \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Right.Temperature\u0026rdquo; Right Fan Speed: \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Right.FanSpeed\u0026rdquo; # What Next? # Complete Documentation. Continue pushing code to Gerrit for review. ","date":"9 September 2023","externalUrl":null,"permalink":"/articles/week-15/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week First draft of the \u0026ldquo;AGL Demo Control Panel\u0026rdquo; documentation.","title":"Week 15 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Enabled Secure Mode Switched to Carbon icons. Animated Navigation of Control Panel What I plan to do next # Enable Secure Mode # Till now, our testing of the AGL Demo Control Panel was being conducted in Insecure mode, i.e. SSL encryption was disabled when connecting to the server (had to run both with the --insecure flag).\nThis week, I made progress in enabling secure communication between the Kuksa-val-server and the Kuksa-client by using the AGL-signed CA.pem certificate and specifying the --tls-server-name to Server.\nCommand line:\nkuksa-client --ip \u0026lt;kuksa ip-addr\u0026gt; --cacertificate ./assets/CA.pem --tls-server-name Server Testing the new implementation,\nimport os import kuksa_client as kuksa import time # AGL CA file ca_file = \u0026#34;./assets/CA.pem\u0026#34; config = { \u0026#34;ip\u0026#34;: \u0026#39;10.42.0.95\u0026#39;, \u0026#34;port\u0026#34;: \u0026#34;8090\u0026#34;, \u0026#39;protocol\u0026#39;: \u0026#39;ws\u0026#39;, \u0026#39;insecure\u0026#39;: False, \u0026#39;cacertificate\u0026#39;: ca_file, \u0026#39;tls_server_name\u0026#39;: \u0026#34;Server\u0026#34;, } token = os.path.join(os.path.expanduser(\u0026#34;~\u0026#34;), f\u0026#34;.local/lib/python3.10/site-packages/kuksa_certificates/jwt/super-admin.json.token\u0026#34;) class Test_class(): def __init__(self): try: self.client = kuksa.KuksaClientThread(config) self.client.start() time.sleep(1) self.client.authorize(token) except Exception as e: print(e) print(\u0026#34;Could not connect to Kuksa\u0026#34;) def do_test(self): self.client.setValue(\u0026#34;Vehicle.Speed\u0026#34;, \u0026#34;100\u0026#34;, \u0026#39;value\u0026#39;) if __name__ == \u0026#34;__main__\u0026#34;: test = Test_class() test.do_test() print(\u0026#34;Done\u0026#34;) The kuksa-client configuration has now been updated to use the same logic, hence both the server and the client can connect in secure mode.\n# Switched to Carbon Icons. # I also updated the icons being used, from feather icons to carbon icons, and removed the various redundant assets from the project.\nUpdated Look\n## # Animated Navigation of Control Panel This week, I made some changes in the UI_Handler module such that in the revised version of the FaderWidget, the QPropertyAnimation object animates the opacity of the QGraphicsOpacityEffect applied to the new widget. The animation starts when the start method of the QPropertyAnimation object is called.\nThe QEasingCurve.OutCubic easing curve is used to make the transition smoother. When the animation is finished, we close the old widget and show the new one.\nAdditionally, I also added an animation to move in and out of the Dashboard such that the Navigation bar collapses when in the Dashboard as the user can use the navigation tiles instead.\n# What Next? # Upload to Gerrit and issue patches based on review. Improve Error Handling. Start documentation and improve README. ","date":"2 September 2023","externalUrl":null,"permalink":"/articles/week-14/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Enabled Secure Mode Switched to Carbon icons.","title":"Week 14 Progress Report","type":"articles"},{"content":" What is GSoC? # Google Summer of Code (GSoC) is a global program that offers students an opportunity to contribute to open-source projects. The program is sponsored by Google and has been running since 2005. The program aims to bring together students and open-source organizations to work on real-world projects. The program has three phases: the community bonding period, the coding period, and the final evaluation period.\nWhat is The Linux Foundation and Automotive Grade Linux? # The Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux. Automotive Grade Linux is an open-source project hosted by The Linux Foundation that is building an open operating system and framework for automotive applications.\nMy work # The objective of this project was to develop a Qt5 application that simulates CAN bus traffic using Kuksa.val to integrate with the AGL Demo platform. The application developed allows the end-users to emit signals using the kuksa-client SDK and Python-can to visualize and interact with AGL Demo applications, such as the IC, IVI, HVAC, and the Green Machine, that display CAN data through Kuksa.val.\nGSoC 2023 Blogs → Click Here\nFinal Report → Click Here\n# Source Code \u0026amp; Documentation # → Gerrit: agl-demo-control-panel\n→ GitHub: AGL_Demo_Control_Panel\n→ Documentation: AGL/documentation\n","date":"1 September 2023","externalUrl":null,"permalink":"/portfolio/gsoc_2023/","section":"Portfolio","summary":"What is GSoC?","title":"GSoC '23 The Linux Foundation @ Automotive Grade Linux (May - Nov 2023)","type":"portfolio"},{"content":" # Topics To Be Covered In This Post # What I did this week Subscribe to VSS signals for registering changes made on target. Refactored the toggle inputs as animated switches. Start working with Kuksa-client 0.4.0 What I plan to do next # Subscribing to VSS signals # This week I added support for subscribing to VSS Signals for the IC and HVAC Pages such that any changes made to their values through a different interface will now also be reflected on the Control Panel without delay.\n# Refactoring Toggles # I also replaced the checkbox inputs for Insecure Mode and CAN to Kuksa toggles with animated toggle switches, Making the inputs more touch friendly and easy to understand.\n# Kuksa-client 0.4.0 # This week also saw slight modifications made to the Kuksa_Insatance module to support the newly released kuksa-client version 0.4.0.\nHowever, I am facing setbacks while enabling SSL communication (Insecure Mode: False) between the host and the server when running on separate machines connected via LAN.\nCommand line mode:\nkuksa-client --ip 10.42.0.95 --port \\ 8090 --protocol ws \\ --cacertificate ./kuksa_certificates/CA.pem Control Panel Config: I also tried modifying the configuration to specify the default config as follows,\nKUKSA_CONFIG = { \u0026#34;ip\u0026#34;: \u0026#39;localhost\u0026#39;, \u0026#34;port\u0026#34;: \u0026#34;8090\u0026#34;, \u0026#39;protocol\u0026#39;: \u0026#39;ws\u0026#39;, \u0026#39;insecure\u0026#39;: False, \u0026#39;cacertificate\u0026#39;: os.path.join(os.path.expanduser(\u0026#34;~\u0026#34;), f\u0026#34;.local/lib/{python_version}/site-packages/kuksa_certificates/CA.pem\u0026#34;), \u0026#39;certificate\u0026#39;: os.path.join(os.path.expanduser(\u0026#34;~\u0026#34;), f\u0026#34;.local/lib/{python_version}/site-packages/kuksa_certificates/Client.pem\u0026#34;), \u0026#39;keyfile\u0026#39;: os.path.join(os.path.expanduser(\u0026#34;~\u0026#34;), f\u0026#34;.local/lib/{python_version}/site-packages/kuksa_certificates/Client.key\u0026#34;), } While both of these allow for Secure and Insecure connections on the same machine, I am yet to be able to replicate this on the intended setup.\n# What Next? # Add tool tips \u0026amp; and support for notifications. Revisit the script for the IC page. Refactor the code wherever necessary \u0026amp; and clean up unused assets. Submit new patch set on Gerrit for review. ","date":"26 August 2023","externalUrl":null,"permalink":"/articles/week-13/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Subscribe to VSS signals for registering changes made on target.","title":"Week 13 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Created CAN interface using cannelloni Implemented the FeedCAN module. Added support for sending Steering wheel CAN messages. Created a test script for sending CAN frames using the USB CAN adapter. What I plan to do next # How to use cannelloni # To test the AGL Demo Control Panel for sending CAN messages to the target machine, we can create a virtual CAN interface using cannelloni. Cannelloni is a SocketCAN over Ethernet tunnel that uses UDP to transfer CAN frames between two machines. Here are the steps used to create a vcan interface using Cannelloni between the host machine (laptop) and target machine (Raspberry Pi) running the AGL IVI Image:\nNote: Since I am using the IVI image for testing this, there is no need to install cannelloni and configure the can0 interface on the target machine.\nOn both machines, create the virtual CAN interface with the command: sudo ip link add dev can0 type vcan On both machines, bring the virtual CAN interface online with the command: sudo ip link set up can0 On both machines, install cannelloni from its GitHub repository On one machine (e.g. the laptop), run cannelloni as a server with the command: cannelloni -I can0 -R \u0026lt;raspberry pi IP address\u0026gt; -L \\ \u0026lt;laptop IP address\u0026gt; -S 20000 -D 20000 On the other machine (e.g. the Raspberry Pi), run cannelloni as a client with the command: cannelloni -I can0 -R \u0026lt;laptop IP address\u0026gt; -L \\ \u0026lt;raspberry pi IP address\u0026gt; -S 20000 -D 20000 You should now be able to send and receive CAN frames between the two machines using the vcan interface and Cannelloni. To test connection # On the sender machine (Laptop):\ncansend can0 021#FFFFFFFF80000000 On receiver machine (RPi4):\ncan_viewer.py -c can0 -i socketcan # OR candump can0 # FeedCAN module # The \u0026ldquo;FeedCAN\u0026rdquo; module sends a CAN signal using the can module by defining a function send_can_signal that takes a CAN frame as input, separates the frame into arbitration ID and data parts, and sends the CAN signal using the can.interface.Bus class.\nimport can def send_can_signal(frame): msg = separate_can_frame(frame) bus = can.interface.Bus(channel=\u0026#39;can0\u0026#39;, bustype=\u0026#39;socketcan\u0026#39;) try: bus.send(msg) print(\u0026#34;CAN signal sent successfully:\u0026#34;) print(\u0026#34;CAN ID:\u0026#34;, hex(msg.arbitration_id)) print(\u0026#34;Data:\u0026#34;, msg.data) except can.CanError: print(\u0026#34;Failed to send CAN signal\u0026#34;) finally: bus.shutdown() def separate_can_frame(frame): # split the frame into arbitration ID and data parts arb_id, data = frame.split(\u0026#34;#\u0026#34;) arb_id = int(arb_id, 16) data = bytes.fromhex(data) message = can.Message(arbitration_id=arb_id, data=data) return message def main(): frame = \u0026#34;021#FFFFFFFF10000000\u0026#34; send_can_signal(frame) if __name__ == \u0026#34;__main__\u0026#34;: main() # Steering wheel CAN messages # After making the FeedCAN, the next step involved defining the relevant CAN frames for the Steering controls and mapping them accordingly. To simplify the convention, I decided to map the VSS path and CAN frame message to the Object name (QPushButton).\nself.switches = { \u0026#34;VolumeUp\u0026#34;: [\u0026#34;Vehicle.Cabin.SteeringWheel.Switches.VolumeUp\u0026#34;,\u0026#34;021#FFFFFFFF40000000\u0026#34;], \u0026#34;VolumeDown\u0026#34;: [\u0026#34;Vehicle.Cabin.SteeringWheel.Switches.VolumeDown\u0026#34;,\u0026#34;021#FFFFFFFF10000000\u0026#34;], \u0026#34;VolumeMute\u0026#34;: [\u0026#34;Vehicle.Cabin.SteeringWheel.Switches.VolumeMute\u0026#34;,\u0026#34;021#FFFFFFFF01000000\u0026#34;], ... } Then depending on whether the user wishes to send the Kuksa signal or CAN messages, we can easily switch between the two.\ndef controls_clicked(self, button): button_clicked = button.objectName() # send CAN message feed_can.send_can_signal(self.Steering.switches[button_clicked][1]) # send kuksa signal self.feed_kuksa.send_values\\ (self.Steering.switches[button_clicked][0], str(true)) # Test script for USB CAN adapters # I also created a test script for the USB CAN adapters which allows us to send messages over the interface, however, the downside is that the adapter does not show up as a CAN interface on the machine. Possible solutions, if we decide to go ahead with the adapters for demo purposes, we could create a small Python script that routes all the incoming messages to the can0 interface.\nTest script # Sender (Host machine):\nfrom can import Message from can.interfaces.seeedstudio import SeeedBus import threading import time class CanSend(threading.Thread): def __init__(self, channel): super(CanSend, self).__init__() self.bus = SeeedBus(bustype=\u0026#39;seeedstudio\u0026#39;, channel=channel, bitrate=1000000) self.stop_requested = threading.Event() def run(self): while not self.stop_requested.is_set(): button_actions = [ { \u0026#34;button\u0026#34;: \u0026#34;previous\u0026#34;, \u0026#34;data\u0026#34;: 0xFFFFFFFF80000000 }, { \u0026#34;button\u0026#34;: \u0026#34;volup\u0026#34;, \u0026#34;data\u0026#34;: 0xFFFFFFFF40000000 }, # We can add more buttons here ] for button_action in button_actions: self.send_button_action(button_action) def stop(self): self.stop_requested.set() def send_button_action(self, button_action): arbitration_id = 0x021 data = button_action[\u0026#34;data\u0026#34;] message = Message(arbitration_id=arbitration_id, data=[data \u0026amp; 0xff, (data \u0026gt;\u0026gt; 8) \u0026amp; 0xff, (data \u0026gt;\u0026gt; 16) \u0026amp; 0xff, (data \u0026gt;\u0026gt; 24) \u0026amp; 0xff], is_extended_id=False) self.bus.send(message) sender = CanSend(\u0026#39;/dev/ttyUSB0\u0026#39;) sender.start() Receiver (RPi4):\nimport can def receive_can_messages(): # Create a new \u0026#39;SeeedBus\u0026#39; instance with \u0026#39;usb0\u0026#39; channel bus = can.interface.Bus(channel=\u0026#39;/dev/ttyUSB0\u0026#39;, bustype=\u0026#39;seeedstudio\u0026#39;) # Loop to continuously receive messages while True: # Receive a message message = bus.recv() # If a message is received, print its details if message is not None: print(f\u0026#39;Received message: {message}\u0026#39;) if __name__ == \u0026#39;__main__\u0026#39;: receive_can_messages() # What Next? # Initial work on using kuksa-client version 0.4.0 Subscribe to VSS signals for registering changes made on target. If necessary, I could implement a service to route the incoming messages on the can0 interface. (after discussion with mentors) ","date":"19 August 2023","externalUrl":null,"permalink":"/articles/week-12/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Created CAN interface using cannelloni Implemented the FeedCAN module.","title":"Week 12 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Tested the USB CAN adapters with hlcand on Raspberry Pi OS and PC. Minor UI changes changed the default font to ttf-Dejavu. What I plan to do next # Testing USB CAN Adapters # Resources used, # hlcand USB to CAN Analyzer Adapter can-utils Raspberry Pi 4 (Raspberry Pi OS) PC (Ubuntu 22.04) This week I tried using hlcand to set up the can0 interface between the Pi and my laptop but only got as far as setting up the interface. There seemed to be no activity on the bus thereafter. Desired set up: Laptop (Transceiver) \u0026lt;-\u0026gt; can_A \u0026lt;=\u0026gt; can_A \u0026lt;-\u0026gt; Pi (RPiOS) (Receiver)\nSteps To Recreate: # 1. Start hlcand: (on both the laptop and the Pi)\n$ sudo ./hlcand -F -s 500000 /dev/ttyUSB0 [6] starting on TTY device /dev/ttyUSB0 [5] attached TTY /dev/ttyUSB0 to netdevice 2. Then to verify can0: $ ip link show can0 4: can0: \u0026lt;NOARP\u0026gt; mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10 link/can 3. Set up can0:\n$ sudo ip link set can0 up type can bitrate 500000 $ ip link show can0 4: can0: \u0026lt;NOARP,UP,LOWER_UP\u0026gt; mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10 link/can 4. Send messages over can0:\n$ cangen can0 -v -L 8 can0 4D3#8B.C6.E1.24.A7.B4.16.59 can0 6C9#42.09.DD.51.F3.14.1B.60 ... At this point, if I use \u0026ldquo;candump can0\u0026rdquo; or \u0026ldquo;can_viewer.py -c can0 -i socketcan\u0026rdquo; on the same machine, I can see traffic but nothing if I do it on the other end\u0026hellip; i.e. the indicators are also non-responsive on the adapters.\nI tried changing the CAN speed and the baud rate but that didn\u0026rsquo;t help.\nAt this point, I started rolling back several commits to find a usable state for the application which I found to be at commit #770776d repo.\n# Rolling Back # Following the same setup as before, i.e. Laptop (Transceiver) \u0026lt;-\u0026gt; can_A \u0026lt;=\u0026gt; can_A \u0026lt;-\u0026gt; Pi (RPiOS) (Receiver), I found it to be partially functional at this point.\nSteps to Recreate # 1. Start canusb: (on both the laptop and the Pi)\n$ sudo ./canusb -p -s 500000 -d /dev/ttyUSB0 -t -F [7] Running in foreground process \u0026gt;\u0026gt;\u0026gt; aa 55 12 03 01 00 00 00 00 00 00 00 00 00 01 00 00 00 00 17 [7] Serial adapter to vcan handler running... \u0026lt;\u0026lt;\u0026lt; 2. Then to verify slcan0: $ ip link show slcan0 4: slcan0: \u0026lt;NOARP,UP,LOWER_UP\u0026gt; mtu 72 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/can 3. Send messages over slcan0:\n$ cangen slcan0 -v slcan0 3A9#9E.29.37.55.18.35 slcan0 7AB#08.60 slcan0 305#CC.4C.1C.36.6C.1A.FD.68 slcan0 094#62.7C.7D.2B.4B.8F slcan0 331#2E.FD.07.28.E4.7C.B2.2F ... Console o/p (PC)\n$ sudo ./canusb -p -s 500000 -d /dev/ttyUSB0 -t -F [7] Running in foreground process \u0026gt;\u0026gt;\u0026gt; aa 55 12 03 01 00 00 00 00 00 00 00 00 00 01 00 00 00 00 17 [7] Serial adapter to vcan handler running... \u0026lt;\u0026lt;\u0026lt; dlc = 6, data = 9e2937551835 \u0026gt;\u0026gt;\u0026gt; aa c6 a9 03 9e 29 37 55 18 35 55 dlc = 2, data = 0860 \u0026gt;\u0026gt;\u0026gt; aa c2 ab 07 08 60 55 dlc = 8, data = cc4c1c366c1afd68 \u0026gt;\u0026gt;\u0026gt; aa c8 05 03 cc 4c 1c 36 6c 1a fd 68 55 dlc = 6, data = 627c7d2b4b8f \u0026gt;\u0026gt;\u0026gt; aa c6 94 00 62 7c 7d 2b 4b 8f 55 dlc = 8, data = 2efd0728e47cb22f \u0026gt;\u0026gt;\u0026gt; aa c8 31 03 2e fd 07 28 e4 7c b2 2f 55 Console o/p (RPi)\n$ sudo ./canusb -p -s 500000 -d /dev/ttyUSB0 -t -F [7] Running in foreground process \u0026gt;\u0026gt;\u0026gt; aa 55 12 03 01 00 00 00 00 00 00 00 00 00 01 00 00 00 00 17 [7] Serial adapter to vcan handler running... \u0026lt;\u0026lt;\u0026lt; aa c6 a9 03 9e 29 37 55 18 35 55 3740.212130 Frame ID: 3a9, Data: 9e2937551835 [7] Not sending message which has been received. \u0026lt;\u0026lt;\u0026lt; aa c2 ab 07 08 60 55 3740.407688 Frame ID: 7ab, Data: 0860 [7] Not sending message which has been received. \u0026lt;\u0026lt;\u0026lt; aa c8 05 03 cc 4c 1c 36 6c 1a fd 68 55 3740.614939 Frame ID: 305, Data: cc4c1c366c1afd68 cansend - send CAN-frames via CAN_RAW sockets. Usage: cansend \u0026lt;device\u0026gt; \u0026lt;can_frame\u0026gt;. \u0026lt;can_frame\u0026gt;: \u0026lt;can_id\u0026gt;#{data} for \u0026#39;classic\u0026#39; CAN 2.0 data frames \u0026lt;can_id\u0026gt;#R{len} for \u0026#39;classic\u0026#39; CAN 2.0 data frames \u0026lt;can_id\u0026gt;##\u0026lt;flags\u0026gt;{data} for CAN FD frames \u0026lt;can_id\u0026gt;: 3 (SFF) or 8 (EFF) hex chars {data}: 0..8 (0..64 CAN FD) ASCII hex-values (optionally separated by \u0026#39;.\u0026#39;) {len}: an optional 0..8 value as RTR frames can contain a valid dlc field \u0026lt;flags\u0026gt;: a single ASCII Hex value (0 .. F) which defines canfd_frame.flags Examples: 5A1#11.2233.44556677.88 / 123#DEADBEEF / 5AA# / 123##1 / 213##311223344 / 1F334455#1122334455667788 / 123#R / 00000123#R3 [3] failed to send data via can \u0026lt;\u0026lt;\u0026lt; aa c6 94 00 62 7c 7d 2b 4b 8f 55 3740.812400 Frame ID: 94, Data: While some frames are not successfully sent across the BUS, possibly due to the data length, at least there seems to be some activity on the bus, verified by the indicators for can_h and can_l LED\u0026rsquo;s on the adapters.\n-\u0026gt; Note: After connecting the adapter, It should be visible as\n$ lsusb Bus 003 Device 004: ID 1a86:7523 QinHeng Electronics CH340 serial converter ... If there are any issues using /dev/ttyUSB0, try removing the brltty package.\n# UI changes # This week I also made minor adjustments to the font by switching from the ttf-Open-Sans-font to the ttf-Dejavu font.\nI also increased the sizes of buttons and sliders on the IC Page to make them more touch-friendly and for the icons and text to be more legible.\n# What Next? # Implement the module responsible for sending CAN frames for steering wheel controls. Revisit the Kuksa_Instance module to support Kuksa-client 0.4.0. ","date":"13 August 2023","externalUrl":null,"permalink":"/articles/week-11/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Tested the USB CAN adapters with hlcand on Raspberry Pi OS and PC.","title":"Week 11 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Resolved the assets licenses and removed unused assets (icons). Fixed the window resizing issue. Increased the navigation button sizes. Added toggle button to switch between kuksa to CAN signals for Steering wheel controls What I plan to do next # Assets # This week I resolved licenses for the various assets used in the project,\nfan.svg: fan.svg by Alpár-Etele Méder IC.svg: IC.svg by Fasil under Creative Creative Commons(Attribution 3.0 unported) Temps: TempUP.svg \u0026amp; TempDown.svg by www.wishforge.games Cruise.svg: Vectors and icons by Esri in MIT License via SVG Repo Voice.svg: Vectors and icons by Carbon Design in Apache License via SVG Repo feather icons: # Window Resizing # I resolved the window resizing issues, by using custom handles for the QMainWindow in the UI_Handler module. I implemented the resize logic by subclassing QWidget and overriding the mouse events and the resizeEvent method. I also needed to create some custom widgets that act as grips for resizing the window from different edges or corners.\n# Navigation buttons # I added a new Menu Page to the Control Panel for easier navigation to the various controls and also increased the sizes of the Navigation buttons at the bottom to increase the responsive hit area when used on a touch display. I also switched the Navigation buttons to a Pressed event from the previously used Click event.\n# Toggle Kuksa to CAN # I also added a toggle to switch between Kuksa signals and CAN bus signals, It will soon be mapped to its relevant function.\n# What Next? # Build an image with agl-demo-preload \u0026amp; agl-demo-cluster-support. Implement the module responsible for sending CAN frames for steering wheel controls. Test on the target machine using CAN bus adaptors. ","date":"6 August 2023","externalUrl":null,"permalink":"/articles/week-10/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Resolved the assets licenses and removed unused assets (icons).","title":"Week 10 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Refined the navigation bar Improved Acceleration function Dummy triggers for Steering Wheel controls What I plan to do next # Navigation Bar # This week I switched the navigation bar from a vertical layout to a horizontal layout to make navigation more intuitive and accessible. I am currently working on revising the animation of the button sizes.\n# Acceleration Function # I also revisited the acceleration function to include a shift up and shift down operation to change the gear ratios as the car accelerates, this helps sell the acceleration as more authentic. This will also help in facilitating the script mode for the IC application.\n# Steering Wheel Trigger # This week, using the python-can library, I also added dummy triggers for the Steering Wheel controls. For now, they emit random CAN signals, and can also switch to kuksa-client. I still need to map the toggle to a button on the GUI.\nFor testing this on actual hardware, my mentors have arranged for a USB to CAN adapter, which I hope to receive between the 9th and 12th of August (Week 11).\n# What Next? # Resolve the asset licenses. Fix window resizing issues. Add toggle for switching between kuksa to CAN signals for Steering wheel controls. ","date":"30 July 2023","externalUrl":null,"permalink":"/articles/week-9/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Refined the navigation bar Improved Acceleration function Dummy triggers for Steering Wheel controls What I plan to do next # Navigation Bar # This week I switched the navigation bar from a vertical layout to a horizontal layout to make navigation more intuitive and accessible.","title":"Week 9 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Uploaded the repo to Gerrit as a patch set, link. Deprecated Navigation Page after discussion with mentors. Refactored QThread instance for feeding values to the kuksa server. Added option in settings to hide pages. Reviewed documentation for Python-can to enable Steering wheel controls. What I plan to do next # Pushing To Gerrit # I was able to push all of my progress to Gerrit this week despite a few challenges, every time I would try to clone the agl-demo-control-panel repo, I would get the following message:\nCloning into \u0026#39;agl-demo-control-panel\u0026#39;... suchinton2001@gerrit.automotivelinux.org: Permission denied (publickey). fatal: Could not read from remote repository. Initially, I thought this was due to the permissions not being set properly for the public and private key files, but as it turns out OpenSSH 8.8 disabled RSA signatures using the SHA-1 hash algorithm. so I ended up creating a new key set using ed25519.\nssh-keygen -t ed25519 and added the public key to Gerrit and all was well. Alternatively, you can also configure the client to accept RSA by adding this ssh config option in ~/.ssh/config:\nPubkeyAcceptedKeyTypes +ssh-rsa # Deprecated Navigation Page # After discussing my progress with my mentors, we decided to deprecate the Navigation Page as it could result in more complicated and longer build times for AGL.\nIf necessary, in the future we may consider different ways of implementing the Navigation Inputs without the use of QtWebEngine, but for now, this page will be disabled by default.\n# Refactored QThread Class FeedKuksa # This class is now a separate module that enables feeding values to the kuksa-client by executing on a separate thread and keeping the GUI responsive. This will be further enhanced in the next week to provide an override function for different applications.\nimport time from PyQt5.QtCore import QThread from . import Kuksa_Instance as kuksa_instance class FeedKuksa(QThread): def __init__(self, parent=None): QThread.__init__(self,parent) self.stop_flag = False self.set_instance() def run(self): print(\u0026#34;Starting thread\u0026#34;) self.set_instance() while not self.stop_flag: self.send_values() def stop(self): self.stop_flag = True print(\u0026#34;Stopping thread\u0026#34;) def set_instance(self): self.kuksa = kuksa_instance.KuksaClientSingleton.get_instance() self.client = self.kuksa.get_client() def send_values(self, Path=None, Value=None, Attribute=None): if self.client is not None: if self.client.checkConnection() is True: if Attribute is not None: self.client.setValue(Path, Value, Attribute) else: self.client.setValue(Path, Value) else: print(\u0026#34;Could not connect to Kuksa\u0026#34;) self.set_instance() else: print(\u0026#34;Kuksa client is None, try reconnecting\u0026#34;) time.sleep(2) self.set_instance() # Visibility Settings # This week I also added a visibility setting for the various pages of the AGL_Demo_Control_Panel which allows specific pages and their corresponding navigation buttons to be visible as per the user preference.\n# CAN Bus Signals for Steering Wheel Inputs # This week I also reviewed the documentation and some projects that utilize the python-can library to enable communications using the Controller Area Network (CAN) protocol. I still have a lot to understand about the same since I\u0026rsquo;ve never worked with CAN before, however, I hope to have a working implementation by next week with the guidance of my mentors and assistance from the community.\n# What Next? # Refining the navigation bar, preferably adopting a horizontal layout. Submission of the initial implementation of the Steering wheel inputs using CAN bus and adding a toggle to switch to kuksa-client. ","date":"19 July 2023","externalUrl":null,"permalink":"/articles/week-8/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Uploaded the repo to Gerrit as a patch set, link.","title":"Week 8 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Finalized Steering Wheel Layout Tested AGL_Control_Panel against AGL image on RPi 4 Added Installation script for Ubuntu/ Debian What I plan to do next # Finalized Steering Wheel Layout # This week I was able to finalize the layout and VSS paths to be used for the Steering Wheel Page, this shall remain subject to further improvements and revisions.\n# AGL_Demo_Control_Panel Against AGL Image on RPi 4 # This week I also tested the AGL_Demo_Control_Panel against the IC application by running the agl-cluster-demo-platform-flutter image on a Raspberry Pi 4 B model.\nReady-made Images # While I did not use this particular image for testing purposes, I found this method more convenient in case I need a prebuilt image in the future.\nwget -r -np -nH --cut-dirs=7 https://download.automotivelinux.org/\\ AGL/snapshots/master/latest/raspberrypi4/deploy/images/raspberrypi4-64/ Building for RPi 4 # For building the agl-cluster-demo-platform-flutter image for the Raspberry Pi 4 I followed the following steps after setting up my build environment.\nsource meta-agl/scripts/aglsetup.sh -f \\ -m raspberrypi4 -b build-flutter-cluster agl-demo agl-devel source agl-init-build-env bitbake agl-cluster-demo-platform-flutter Note: Copying the build on my local machine, I perform this step only because I built the image on a remote server\nscp -r rs5:AGL/master/build-flutter-cluster/tmp/deploy/\\ images/raspberrypi4-64/ $HOME/AGL_Images/IC_rasp/ Flashing Image to SD Card # While the documentation provides instructions on how to flash the AGL image onto an SD card, I was unable to get it to boot using the provided steps. It is possible that it was a human error on my part, however, I found it much simpler to use the Raspberry Pi to flash the image for now.\nConnecting to the Pi using Ethernet # Since the IC Flutter demo app does not provide a GUI method to find the IP address of the Pi, and also does not connect to the WiFi by default, I went on to enable communication using a LAN cable.\nTo enable the Ethernet port to find the Pi on my network, I followed the following steps in the Gnome Settings Panel, similar settings should be available in other network configuration tools.\nSettings -\u0026gt; Network -\u0026gt; Wired -\u0026gt; IPv4 IPv4 Method -\u0026gt; Shared to other computers # Find IP addr of the ethernet ip address show eno1 ping \u0026lt;ip-address-for-eno1\u0026gt; # Resolve all available IP addresses on network, # recommend turning off WiFi arp -a ssh root@\u0026lt;ip-address-raspberrypi\u0026gt; After successfully ssh-ing into the session, we kill the existing kuksa service (since it runs on localhost) and restart kuksa-val-server on special IP address 0.0.0.0.\npkill kuksa kuksa-val-server --address 0.0.0.0 --insecure # optional flag \u0026#34;--log-level VERBOSE\u0026#34; # Added Installation Script for Ubuntu # To cut a long tale short, we can no longer do pip install x. The command does not work with Ubuntu 23.04 due to a deliberate policy change to avoid conflicts between the Python package manager (pip) and Ubuntu\u0026rsquo;s underlying APT. pip can now only be used in a virtual environment created with venv or by using pipx, Python local installer.\nTo overcome this we can run the install_ubuntu.sh script to resolve the dependencies on Ubuntu. The script is yet to be tested on other versions of Ubuntu and only serves to make installation easier later on, it is still recommended to manage these dependencies manually on Ubuntu.\n#!/bin/bash sudo apt-get update sudo apt-get install -y python3-pyqt5 sudo apt-get install -y python3-pyqt5.qtwebengine echo \u0026#39;PATH=\u0026#34;$HOME/.local/bin/:$PATH\u0026#34;\u0026#39; \u0026gt;\u0026gt;~/.bashrc source ~/.bashrc if ! command -v pipx \u0026amp;\u0026gt; /dev/null; then echo \u0026#34;pipx not found. Installing pipx...\u0026#34; sudo apt-get install -y pipx fi pipx install kuksa-client pipx install folium --include-deps echo \u0026#34;Installation complete!\u0026#34; # What Next? # Push repo to Gerrit. Fix address selection for the navigation page. Make Visibility of Controls optional and provide specific configuration for each page. # References: # AGL Docs: AGL Software. AGL Docs: Building for RPi AGL Docs: IC App ","date":"13 July 2023","externalUrl":null,"permalink":"/articles/week-7/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Finalized Steering Wheel Layout Tested AGL_Control_Panel against AGL image on RPi 4 Added Installation script for Ubuntu/ Debian What I plan to do next # Finalized Steering Wheel Layout # This week I was able to finalize the layout and VSS paths to be used for the Steering Wheel Page, this shall remain subject to further improvements and revisions.","title":"Week 7 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Specified Steering wheel Controls Improved Settings page and error handling Default settings Improved Navigation Page Updated README and Troubleshooting steps What I plan to do next # Steering Wheel Controls # This week I added the various signals for the Steering Wheel Controls, namely\nVolume Up: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.VolumeUp\u0026rdquo; Volume Down: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.VolumeDown\u0026rdquo; Volume Mute: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.VolumeMute\u0026rdquo; Next Track: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.Next\u0026rdquo; Previous Track: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.Previous\u0026rdquo; Info: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.Info\u0026rdquo; Cruise Enable: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.CruiseEnable\u0026rdquo; Voice: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.Voice\u0026rdquo; Phone Call: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.PhoneCall\u0026rdquo; Phone Hangup: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.PhoneHangup\u0026rdquo; Horn: \u0026ldquo;Vehicle.Cabin.SteeringWheel.Switches.Horn\u0026rdquo; The layout of these controls will be further improved by making use of custom icons and buttons to mimic the layout of a steering wheel more accurately.\n# Settings Page and Error handling # I also revised the styling of the QLineEdit and QPushbuttons for the settings page to make it look cleaner and make the text more legible. This also includes placeholder text for the input fields.\n# Navigation Page # The navigation page received some major changes this week including,\nDrop down suggestion for address being entered Addition of current location as From Address UI # README \u0026amp; Troubleshooting # The README file was updated to provide steps to install and troubleshoot the AGL Demo Control Panel.\nOne minor problem I encountered while using QtWebEngine during testing on systems other than Ubuntu 22.04 LTS, namely Fedora 38 and openSUSE was that the navigation map would not render at all or stay black even after the address was selected.\nThis behavior can be rectified by following the steps by following the steps given below:\nUninstall the requirements pip uninstall -r requirements.txt Uninstall PyQtWebEngine-Qt5 pip uninstall PyQtWebEngine-Qt5 Remove sandboxing for QtWebEngine export QTWEBENGINE_CHROMIUM_FLAGS=\u0026#34;--no-sandbox\u0026#34; # What I plan to do next # Tweak the visuals to better reflect the states of focus/ check and click events Add custom icons/ images to replicate the steering wheel layout Test the AGL Demo Control Panel alongside AGL images on the target machine, Raspberry Pi 4 B # References: # https://www.reddit.com/r/Fedora/comments/qtyf3x/fedora_35_pyqtwebengine_blank_page/ https://git.automotivelinux.org/AGL/meta-agl-demo/tree/recipes-connectivity/vss/vss-agl/agl_vss_overlay.vspec ","date":"6 July 2023","externalUrl":null,"permalink":"/articles/week-6/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Specified Steering wheel Controls Improved Settings page and error handling Default settings Improved Navigation Page Updated README and Troubleshooting steps What I plan to do next # Steering Wheel Controls # This week I added the various signals for the Steering Wheel Controls, namely","title":"Week 6 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Refactored the IC Acceleration function IC page script (Toggle) Initialized Steering wheel Signals Controls (Not yet functional) Navigation Page (Revised Style sheet and improved operations What I plan to do next # IC Acceleration Button # This week I updated the Acceleration button to operate on a Pressed and Released event instead of the previously used Clicked event, this allows us to implement both Acceleration and Deceleration proportionally for the vehicle\u0026rsquo;s Speed and the Engine RPM.\nTriggers for this operation can be done by the following inputs:\nTouch \u0026amp; Hold (On a touch-friendly device) Click and hold Space bar (Can be mapped to a different key as well) # Script Mode # I also started work on the Script mode which feeds relevant values to the demo applications when a user is not interacting with the AGL_Demo_Control_Panel.\nNext week, I will extensively work on this to present exciting sequences not just for the demo apps but also for the control panel itself.\n# Steering Wheel Controls # This week also saw the inclusion of dummy inputs for the Steering Wheel Controls, i.e.:\nVolume Up Volume Down Next Track Prev Track Stop/ Play Accept Call/ Decline Call These Buttons are yet to be assigned any actions and are highly subject to change after a discussion with my mentors but it serves to showcase the various operations the control panel can provide.\n# Navigation Page # The Navigation Page was revisited to improve its usability and operations, It can now provide recommendations for Source and Destination addresses for navigation, live as they are being typed.\n# What Next? # Make Kuksa Subscription Scripts to view the changes being made. Since not all demo applications subscribe to their corresponding VSS signals. Introduce some better error handling for when the server is not connected or found on the specified IP address. Improve GitHub README and documentation # References: # https://github.com/eclipse/kuksa.val/tree/master/kuksa-val-server https://github.com/hritik-chouhan/HVAC_dashboard Stackoverflow: qss-border-radius-problem https://github.com/aakash-s45/ic ","date":"1 July 2023","externalUrl":null,"permalink":"/articles/week-5/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Refactored the IC Acceleration function IC page script (Toggle) Initialized Steering wheel Signals Controls (Not yet functional) Navigation Page (Revised Style sheet and improved operations What I plan to do next # IC Acceleration Button # This week I updated the Acceleration button to operate on a Pressed and Released event instead of the previously used Clicked event, this allows us to implement both Acceleration and Deceleration proportionally for the vehicle\u0026rsquo;s Speed and the Engine RPM.","title":"Week 5 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Added HVAC signals, limited to 4 Toggle for Secure and Insecure Mode Added animations for navigation and improved window handles New theme for UI Reading from the config file What I plan to do next # HVAC signals # This week I started adding signal inputs for the HVAC page, currently only 4 VIS signals are supported as the demo apps have not been patched to support other signals and mostly unresponsive on the Qt5 \u0026amp; Flutter images of AGL.\nThe signals that were added this week are:\nLeft Temp: \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Left.Temperature\u0026rdquo; Left Fan Speed: \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Left.FanSpeed\u0026rdquo; Right Temp: \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Right.Temperature\u0026rdquo; Right Fan Speed: \u0026ldquo;Vehicle.Cabin.HVAC.Station.Row1.Right.FanSpeed\u0026rdquo; More signals can be added after further discussion with my mentors.\n# Animations \u0026amp; Window handles # # Config # Configurations will now be handled by the config.py module and help in retaining past preferences and configurations by reading the config file.\nSecure \u0026amp; Insecure Mode # I have also added bindings for enabling and disabling the secure and insecure modes (SSL) of connection with Kuksa-val-server and tested both for verification as well.\n# New Theme # This week I also added a new theme to add more contrast to each element and make the text and icons more legible.\n# What Next? # Start working on Dashboard and Steering wheel Signals Revisit the optional Navigation widget Improve GitHub README and documentation ","date":"23 June 2023","externalUrl":null,"permalink":"/articles/week-4/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Added HVAC signals, limited to 4 Toggle for Secure and Insecure Mode Added animations for navigation and improved window handles New theme for UI Reading from the config file What I plan to do next # HVAC signals # This week I started adding signal inputs for the HVAC page, currently only 4 VIS signals are supported as the demo apps have not been patched to support other signals and mostly unresponsive on the Qt5 \u0026amp; Flutter images of AGL.","title":"Week 4 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Added Settings Window to main Application Completed Support for IC Application Signals Added custom handles for window Uploaded GitHub Readme.md Building AGL-demo-platform Image What I plan to do next # AGL-Demo-Control-Panel # Added Settings Window to main Application # The settings window provides various options to configure the kuksa-client. functionalities are:\nStart Connection Create Network Bridge Reconnect Refresh Input IP Address Input JWT Token Path for Authorization Display Connection Status IC Kuksa Signals # This week I improved the style sheet for the IC page to better integrate with the application. All visible elements in the IC application are now supported by the AGL-Demo-Control-Center, including the Indicator buttons, Gear selector, Speed, RPM, Coolant temp, and Fuel level. However some of them do not respond to the changes made to the VSS signal values, this may be due to usage of outdated VSS paths or that the application simply doesn\u0026rsquo;t subscribe to the signals.\nSignals being used on the IC Page are:\nVehicle Speed: \u0026ldquo;Vehicle.Speed\u0026rdquo; Engine RPM: \u0026ldquo;Vehicle.Powertrain.CombustionEngine.Speed\u0026rdquo; Left Indicator: \u0026ldquo;Vehicle.Body.Lights.DirectionIndicator.Left.IsSignaling\u0026rdquo; Right Indicator: \u0026ldquo;Vehicle.Body.Lights.DirectionIndicator.Right.IsSignaling\u0026rdquo; Hazard: \u0026ldquo;Vehicle.Body.Lights.Hazard.IsSignaling\u0026rdquo; Fuel Level: \u0026ldquo;Vehicle.Powertrain.FuelSystem.Level\u0026rdquo; Coolant Temp: \u0026ldquo;Vehicle.Powertrain.CombustionEngine.ECT\u0026rdquo; Selected Gear: \u0026ldquo;Vehicle.Powertrain.Transmission.SelectedGear\u0026rdquo; Custom Handles for Window # This week I also added custom handles for resizing the application since we do not use native window titles for the Application. This helps in resizing the window. I also added better animations for the window controls.\nHVAC Controls # Initial support for the HVAC signals was introduced, and the HVAC Dashboard Application was used as a reference for the same.\nBug Fixes # Kuksa_Instance was updated to better handle client instances when reconnecting to the server. settings module now better reflects the connection status. Fixed the crash problem when the server is not found. # Demo # # GitHub Readme # The GitHub README.md was updated to showcase the application\u0026rsquo;s features and also provide instructions to install on the system and configure it.\n→ It can be found on the GitHub repo\n# Building AGL-demo-platform # I also built the AGL-demo-platform from the master branch using the documentation, and am in the process of building the Flutter IVI dashboard demo applications. However, building that image gives me a single error for flutter-gallery_git package during the build process. I will work on that in the coming week.\n# What Next? # Start work on HVAC controls Enable secure communication with kuksa (WS) Save Configurations Improve UI \u0026amp; UX Test Application on hardware using LAN cable # References: # docs.automotivelinux.org https://github.com/eclipse/kuksa.val/tree/master/kuksa-val-server https://github.com/hritik-chouhan/HVAC_dashboard https://github.com/hritik-chouhan/DashBoard-app https://github.com/aakash-s45/ic ","date":"16 June 2023","externalUrl":null,"permalink":"/articles/week-3/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Added Settings Window to main Application Completed Support for IC Application Signals Added custom handles for window Uploaded GitHub Readme.","title":"Week 3 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Implement Settings Window Initial support for Kuksa Signals Initializing the GitHub Repository What I plan to do next # Settings Window # This week I implemented the settings window to start/ configure an instance of kuksa-client to be used across the whole application. Features of this module are as follows:\nConfigure Kuksa-client Custom IP address JWT token path Toggle for Insecure mode Start/ Reconnect Kuksa-client Display Connection Status How Does it Work? # We first created a KuksaSingleton module using the Singleton Design Pattern. The benefits of using the Singleton design pattern are:\nInitialization: An object created by the Singleton method is initialized only when it is requested for the first time. Access to the object: We get global access to the instance of the object. Count of instances: In singleton, method classes can’t have more than one instance This allows us to maintain a single instance of the kuksa-client object, and have access to it globally.\nimport kuksa_client as kuksa class KuksaClientSingleton: __instance = None @staticmethod def get_instance(): if KuksaClientSingleton.__instance is None: KuksaClientSingleton() return KuksaClientSingleton.__instance def __init__(self): if KuksaClientSingleton.__instance is not None: raise Exception(\u0026#34;This class is a singleton!\u0026#34;) else: self.default_Config = { \u0026#34;ip\u0026#34;: \u0026#39;10.10.10.203\u0026#39;, \u0026#34;port\u0026#34;: \u0026#34;8090\u0026#34;, \u0026#39;protocol\u0026#39;: \u0026#39;ws\u0026#39;, \u0026#39;insecure\u0026#39;: True, } self.token = \u0026#34;/home/suchinton/.local/lib/\\ python3.10/site-\\ packages/kuksa_certificates/jwt/\\ super-admin.json.token\u0026#34; try: self.client = kuksa.KuksaClientThread\\ (self.default_Config) self.client.authorize(self.token) self.client.start() except Exception as e: print(e) KuksaClientSingleton.__instance = self def get_client(self): return self.client, self.default_Config, self.token def reconnect_client(self, new_Config, new_Token): self.client.stop() print(self.client.checkConnection()) self.client = kuksa.KuksaClientThread(new_Config) self.client.authorize(new_Token) self.client.start() def __del__(self): self.client.stop() This implementation allows us to write custom functions such as reconnect_client which helps restart the client with new configurations.\nNote: This module will be modified to read and write to a config file which will store the default values and the previous entries.\nAccessing the Kuksa-Client Object # As visible in the above code segment, the client object, its default_Config and the default token path can be retrieved using the get_client method in other modules of this application.\nAll we need to do to get access to the client instance is add the necessary module as such:\n. . . import sys current_dir = os.path.dirname(os.path.abspath(__file__)) # ======================================== sys.path.append(os.path.dirname(current_dir)) import extras.Kuksa_Instance as kuksa_instance . . . and to create the client object, the following syntax is used:\nself.kuksa = kuksa_instance.KuksaClientSingleton.get_instance() self.client, self.config, self.token = self.kuksa.get_client() Settings Window # The impedimented settings menu was made keeping certain requirements in mind, such as:\nThe client\u0026rsquo;s first instance must be started only via the settings The user should be able to restart the client The settings menu must allow the user to modify the default config It must reflect the status of the connection with Kuksa Note: The StyleSheet is yet to be updated for the Settings Window\n# Kuksa Signals for IC Application # I also added initial support for the IC application by specifying its VSS paths subscribed by it, this allows us to control the visible widget values and states using dials, buttons and input fields.\nThe implementation in the Demo application had some flaws that I was able to overcome this week by optimizing the slider for a smoother experience. This was done using the following Qt modules:\nQTimer object to update the values at a fixed interval instead of updating it every time the slider value changes. This reduces the number of requests sent to the server and makes the application more responsive. QThread object to run the timer in a separate thread so that it doesn’t block the main thread and cause the application to freeze. As a consequence, the app is more responsive, and also the values fed to kuksa-val-server using this method are continuously updated at defined intervals. Which can help us implement dedicated scripts for the AGL demo apps in the future.\nThe signal paths specified for the application comply with the recently released VSS 3.1.1. being used by KUKSA.val 0.3.1.\nNote: During this week\u0026rsquo;s GSoC meeting, my mentors mentioned that since AGL does not, for the time being, use any navigation APIs, We have decided to make the Navigation Widget (mentioned in last week\u0026rsquo;s report) an optional module.\n# GitHub Repository # This week I also initialized the GitHub repository for this project, hosting it under the Apache V2 License after a discussion regarding the same with my mentors.\nThe repository can be accessed using the provided link.\n→ https://github.com/suchinton/AGL_Demo_Control_Panel\n# What Next? # Next week I expect to have complete support for IC Add initial support for HVAC Finalize the UI/UX with mentors Build AGL master branch on remote server # References: # https://www.w3.org/auto/wg/wiki/Vehicle_Signal_Specification_(VSS)/Vehicle_Data_Spec https://www.geeksforgeeks.org/singleton-method-python-design-patterns/ https://github.com/eclipse/kuksa.val/blob/d9dc9f808268be91abd13f8751337cece470c96c/kuksa-client/docs/examples/threaded.md https://github.com/eclipse/kuksa.val/releases https://dias-kuksa-doc.readthedocs.io/en/latest/contents/invehicle.html https://www.apache.org/licenses/LICENSE-2.0 ","date":"9 June 2023","externalUrl":null,"permalink":"/articles/week-2/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Implement Settings Window Initial support for Kuksa Signals Initializing the GitHub Repository What I plan to do next # Settings Window # This week I implemented the settings window to start/ configure an instance of kuksa-client to be used across the whole application.","title":"Week 2 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What I did this week Communication with Kuksa.val Skeleton code for GUI using PyQt5 Navigation widget for IC What I plan to do next # Communication With Kuksa.val # Continuing with the progress made last week regarding communication with Kuksa-val-server using a bridged network, I tried to enable IP routing to make the traffic at 10.10.10.204 also accessible at localhost 127.0.0.1, but that did not work.\nTherefore, we run the kuksa-val-server on IP address 0.0.0.0, which is a special IP address known as the “default route” or “unspecified address”. It is used to indicate that traffic should be sent to all interfaces on a machine, regardless of their individual IP addresses.\nThis allows us to sidestep the hassle of setting a dedicated IP address to communicate with Kuksa. Based on these developments, I then modified the Kuksa-client config in my demo application, AGL-Kuksa.val-Visualiser for testing its functionality, The changes made in main.py were:\n. . . config = { \u0026#34;ip\u0026#34;: \u0026#39;10.10.10.203\u0026#39;, \u0026#34;port\u0026#34;: \u0026#34;8090\u0026#34;, \u0026#39;protocol\u0026#39;: \u0026#39;ws\u0026#39;, \u0026#39;insecure\u0026#39;: True, } . . . Running AGL Image : # We then run the QEMU instance the same as before (this time without a VNC viewer).\nsudo qemu-system-x86_64 -device virtio-net-pci,\\ netdev=net0, mac=52:54:00:12:35:02 -netdev \\ bridge,br=br0,id=net0 -drive \\ file=\\ agl-cluster-demo-platform-flutter-qemux86-64.ext4 \\ ,if=virtio,format=raw -usb -usbdevice tablet \\ -device virtio-rng-pci -snapshot -vga virtio \\ -soundhw hda -machine q35 -cpu kvm64 \\ -cpu qemu64,+ssse3,+sse4.1,+sse4.2,+popcnt \\ -enable-kvm -m 2048 -serial mon:vc -serial \\ mon:stdio -serial null -kernel bzImage -append \\ \u0026#39;root=/dev/vda rw console=tty0 mem=2048M \\ ip=dhcpoprofile.timer=1 console=ttyS0,115200n8 \\ verbose fstab=no\u0026#39; Running Kuksa-val-server in QEMU: # kuksa-val-server --address 0.0.0.0 --insecure \\ --log-level VERBOSE Host Machine Command For Kuksa-client: # To verify and establish a connection with Kuksa-val-server running inside the QEMU instance, I made the kuksa-client listen on the VM\u0026rsquo;s public IP address\n# IP is the QEMU instance IP addr kuksa-client --ip 10.10.10.203 --insecure Next, we authorize the client using a JWT access token, usually found at $HOME/.local.local/lib/python3.10/site-packages/kuksa_certificates/jwt/. Upon successfully connecting to the server,\nhere is a look at how the AGL-Kuksa.val-Visualiser application interacts with the IC demo application.\n# Navigation Input For IC Demo App # This is a work-in-progress widget to be added to the Instrument cluster tab of our GUI application, and seeks to provide the functionality to,\nset current location (from) set destination location (to) provide suggestions for address start navigation It makes use of Folium, which is a Python wrapper for leaflet.js which is a javascript library for plotting interactive maps. It enables both the binding of data to a map for choropleth visualizations as well as passing rich vector/raster/HTML visualizations as markers on the map.\nThe program has several methods such as search_address fetch_address_suggestions show_suggestions show_location update_map and more. These methods are used for fetching suggestions from OpenStreetMap, displaying suggestions, displaying the location on the map, updating the map, and creating HTML code for the map.\nThe implementation of this feature can be improved in the coming weeks for setting the marker/ address more accurately.\n# Application Preview # Finally, I got to start working on the skeletal code of the main application using Qt5. This is still a fairly bare-bones preview of how the interface would look and is highly subject to change in future revisions.\nAll new widgets created for the AGL demo apps will be added as separate modules to increase the customization and maintainability of the whole application.\n# What Next? # Here are some of my targets for next week,\nImprove implementation of Kuksa-client add support for signals subscribed by the IC Application improve the navigation widget finalize the design for the main application with my mentors # References: # https://github.com/eclipse/kuksa.val/blob/master/kuksa-client/docs/examples/threaded.md https://www.howtogeek.com https://python-visualization.github.io/folium/ https://www.openstreetmap.org/help ","date":"3 June 2023","externalUrl":null,"permalink":"/articles/week-1/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What I did this week Communication with Kuksa.","title":"Week 1 Progress Report","type":"articles"},{"content":" # Topics To Be Covered In This Post # What is the Community bonding period? What I did the past month Challenges faced Community interactions What I plan to do next What is GSoC \u0026amp; What Have I Been Up To During The CBP? # Google Summer of Code (GSoC) is a global program that offers students an opportunity to contribute to open-source projects. The program is sponsored by Google and has been running since 2005. The program aims to bring together students and open-source organizations to work on real-world projects. The program has three phases: the community bonding period, the coding period, and the final evaluation period.\nThe community bonding period is the three weeks between GSoC student acceptance and the start of the coding date (May 4th - May 28th). During this period I engaged with my GSoC mentors, Jan-Simon Möller ,Walt Miner, Scott Murray, Marius Vlad, and the rest of the AGL community. I used this period to get familiar with the various tools used in AGL and set up my work environment for the coding period. This also allowed me to better understand the requirements of my project.\nI also participated in the AGL Weekly Dev Meet events to better understand the work done at AGL and its various technical groups.\nSetting Up The Build Environment # On our first weekly GSoC meetings, Jan-Simon Möller was kind enough to set us up with the remote servers we may need to build the AGL images as building on local hardware is a time-consuming process.\nDuring my first attempt at building the AGL Flutter Instrument Cluster demo image, I encountered an issue where there wasn\u0026rsquo;t enough storage available to build new images on the server. However, this should soon be resolved after a cleanup job. So, till then I\u0026rsquo;ll continue building on my local machine.\nBuilding AGL Locally # On May 11th, I faced an AGL Build failure on Pop!_OS 22.04 LTS to which I found the solution at Yocto Docs.\nThe error was due to the oss4-dev package installed on my system, which resulted in QEMU build failures due to the package installing its custom /usr/include/linux/soundcard.h on the Debian systems.\nThis was resolved by resolving the packages.\nsudo apt-get build-dep qemu sudo apt-get remove oss4-dev Working With Kuksa-val-server, Kuksa-client and AGL Images # So in order the test my proposed implementation, I initially tried running the Docker build of the Kuksa-val server on my machine to manipulate values on the IC flutter application using my Demo application AGL-Kuksa.val-Visualiser, while it was successfully setting the required values for Vehicle.Speed, the IC application would require a hot reload every time to update the values.\nTo overcome this, I and a doubt-clearing session with Scott Murray, which led me to use the AGL Flutter Instrument Cluster demo image, by using port forwarding and establishing a connection between the host and the QEMU machine. This proved to be a failure since my host machine was able to ping the QEMU instance but not the other way around.\nThen during the weekly GSoC meeting, Marius Vlad cleared my doubts regarding this issue. He recommended I set up the communication interface using a bridge network and redirected me to the TAP network guide for testing out my implementation.\nI modified the available script for my convenience and added comments to better understand the various steps.\nSetting Up A Network Bridge # Note: script only works on the wireless interface\nTo create the bridge network br0 we run the setup_tap_wireless_int.sh script with elevated privileges. The script helps connect wireless devices to a network by creating a bridge between the wireless interface wlp4s0 and the network interface. It also sets up a DHCP and DNS server for the bridge interface and creates rules to allow traffic to flow between the wireless and network interfaces.\n#!/bin/bash # Find the wireless interface WIRELESS=$(iwconfig 2\u0026gt;/dev/null | awk \u0026#39;/IEEE 802.11/ {print $1; exit}\u0026#39;) BRIDGE=br0 NETWORK=10.10.10.0 NETMASK=255.255.255.0 GATEWAY=10.10.10.1 DHCPRANGE=10.10.10.100,10.10.10.254 # Create the bridge interface ip link add $BRIDGE type bridge ip link set dev $BRIDGE up # Assign an IP address to the bridge interface ip addr add dev $BRIDGE $GATEWAY/$NETMASK # Enable IP forwarding sysctl -w net.ipv4.ip_forward=1 \u0026gt; /dev/null 2\u0026gt;\u0026amp;1 # Flush existing iptables rules and set default policies to ACCEPT iptables --flush iptables -t nat -F iptables -X iptables -Z iptables -P OUTPUT ACCEPT iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT # Allow DHCP and DNS traffic on the bridge interface iptables -A INPUT -i $BRIDGE -p tcp -m tcp --dport 67 -j ACCEPT iptables -A INPUT -i $BRIDGE -p udp -m udp --dport 67 -j ACCEPT iptables -A INPUT -i $BRIDGE -p tcp -m tcp --dport 53 -j ACCEPT iptables -A INPUT -i $BRIDGE -p udp -m udp --dport 53 -j ACCEPT # Allow forwarding of packets between the bridge and the network iptables -A FORWARD -i $BRIDGE -o $BRIDGE -j ACCEPT iptables -A FORWARD -s $NETWORK/$NETMASK -i $BRIDGE -j ACCEPT iptables -A FORWARD -d $NETWORK/$NETMASK -o $BRIDGE -m state --state RELATED,ESTABLISHED -j ACCEPT # Accept packets from the bridge interface with source and destination within the network # to prevent masquerading of bridged frames/packets iptables -t nat -A POSTROUTING -s $NETWORK/$NETMASK -d $NETWORK/$NETMASK -j ACCEPT # Perform network address translation (NAT) for packets from the network iptables -t nat -A POSTROUTING -s $NETWORK/$NETMASK -j MASQUERADE # Configure dnsmasq as the DHCP and DNS server for the bridge interface dns_cmd=( dnsmasq --strict-order --except-interface=lo --interface=$BRIDGE --listen-address=$GATEWAY --bind-interfaces --dhcp-range=$DHCPRANGE --conf-file=\u0026#34;\u0026#34; --pid-file=/var/run/qemu-dnsmasq-$BRIDGE.pid --dhcp-leasefile=/var/run/qemu-dnsmasq-$BRIDGE.leases --dhcp-no-override ) # Execute the dnsmasq command echo ${dns_cmd[@]} | bash # Allow traffic from the bridge interface to the wireless interface iptables -A FORWARD -i $BRIDGE -o $WIRELESS -j ACCEPT # Perform masquerading for outgoing packets on the wireless interface iptables -t nat -A POSTROUTING -o $WIRELESS -j MASQUERADE # Allow known traffic from the wireless interface to return to the bridge interface iptables -A FORWARD -i $WIRELESS -o $BRIDGE -m state --state RELATED,ESTABLISHED -j ACCEPT Starting The QEMU VM # For utilizing the bridge br0 created using the script, the VM needs to be started with elevated privileges, and the specified arguments.\nsudo qemu-system-x86_64 -device virtio-net-pci,\\ netdev=net0,mac=52:54:00:12:35:02 -netdev bridge \\ ,br=br0,id=net0 -drive file=agl-cluster-demo-platform-flutter-qemux86-64.ext4, \\ if=virtio,format=raw -usb -usbdevice tablet \\ -device virtio-rng-pci -snapshot -vga virtio -vnc :0 \\ -soundhw hda -machine q35 -cpu kvm64 \\ -cpu qemu64,+ssse3,+sse4.1,+sse4.2,+popcnt -enable-kvm \\ -m 2048 -serial mon:vc -serial mon:stdio -serial null -kernel bzImage \\ -append \u0026#39;root=/dev/vda rw console=tty0 mem=2048M ip=dhcp oprofile.timer=1 console=ttyS0,115200n8 verbose fstab=no\u0026#39; We enter root as the username and get access to the AGL command line. The IP address of the VM is verified using the ip address show command.\nroot@qemux86-64:~# ip address show 1: lo: \u0026lt;LOOPBACK,UP,LOWER_UP\u0026gt; mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: \u0026lt;BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP\u0026gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:12:35:02 brd ff:ff:ff:ff:ff:ff inet 10.10.10.203/24 metric 1024 brd 10.10.10.255 scope global dynamic eth0 valid_lft 3490sec preferred_lft 3490sec inet 10.10.10.204/24 brd 10.10.10.255 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe12:3502/64 scope link valid_lft forever preferred_lft forever 3: sit0@NONE: \u0026lt;NOARP\u0026gt; mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 4: can0: \u0026lt;NOARP,UP,LOWER_UP\u0026gt; mtu 72 qdisc noqueue state UNKNOWN group default qlen 1000 link/can Starting Kuksa-val-server In the QEMU Instance # By default Kuksa, and all the applications using it listen to the localhost ip 127.0.0.1 of the QEMU instance. Therefore, to enable communication with the host OS, we need to run the server on the ip 10.10.10.204 in --insecure mode.\nkuksa-val-server --address 10.10.10.204 --log-level VERBOSE --insecure Connecting To Kuksa-val-server # On the Host machine, we use the Kuksa-client in cli mode to test the connection with the given arguments. Kuksa-client Python SDK is a library that allows us to interact with either kuksa-val-server or kuksa_databroker.\nkuksa-client --ip 10.10.10.204 --insecure Host Machine:\nWelcome to Kuksa Client version 0.3.1 `-:+o/shhhs+:` ./oo/+o/``.-:ohhs- `/o+- /o/ `.. :yho` +o/ /o/ oho ohy` :o+ /o/`+hh. sh+ +o: /oo+o+` /hy +o: /o+/oo- +hs .oo` oho `oo- .hh: :oo. oho -+: -hh/ .+o+-`oho `:shy- ./o/ohy//+oyhho- `-/+oo+/:. Default tokens directory: /home/suchinton/.local/lib/python3.10/site-packages/kuksa_certificates/jwt connect to ws://10.10.10.204:8090 Websocket connected. Test Client\u0026gt; authorize /home/suchinton/.local/lib/python3.10/site-packages/kuksa_certificates/jwt/super-admin.json.token { \u0026#34;TTL\u0026#34;: 1767225599, \u0026#34;action\u0026#34;: \u0026#34;authorize\u0026#34;, \u0026#34;requestId\u0026#34;: \u0026#34;26a3c251-7418-43df-bcc2-d4956726462e\u0026#34;, \u0026#34;ts\u0026#34;: \u0026#34;2023-05-27T18:22:54.1685211774Z\u0026#34; } Test Client\u0026gt; setValue Vehicle.Speed 12 { \u0026#34;action\u0026#34;: \u0026#34;set\u0026#34;, \u0026#34;requestId\u0026#34;: \u0026#34;675a0cf6-fd12-47f3-8dd4-36ddf4b951bd\u0026#34;, \u0026#34;ts\u0026#34;: \u0026#34;2023-05-27T18:23:31.1685211811Z\u0026#34; } QEMU instance of AGL:\nroot@qemux86-64:~# kuksa-val-server --address 10.10.10.204 --log-level VERBOSE --insecure kuksa.val server Commit from Read configs from /etc/kuksa-val/config.ini Update vss path to /usr/share/kuksa-val/vss_release_3.1.1.json Update cert-path to /etc/kuksa-val Log START VERBOSE: Try reading JWT pub key from /etc/kuksa-val/jwt.key.pub VERBOSE: SubscribeThread: Started Subscription Thread! VERBOSE: VssDatabase::VssDatabase : VSS tree initialized using JSON file = /usr/share/kuksa-val/vss_release_3.1.1.json VERBOSE: Receive action: authorize VERBOSE: VssCommandProcessor::processQuery: authorize query with token = eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJrdWtzYS52YWwiLCJpc3MiOiJFY2xpcHNlIEtVS1NBIERldiIsImFkbWluIjp0cnVlLCJtb2RpZnlUcmVlIjp0cnVlLCJpYXQiOjE1MTYyMzkwMjIsImV4cCI6MTc2NzIyNTU5OSwia3Vrc2EtdnNzIjp7IioiOiJydyJ9fQ.p2cnFGH16QoQ14l6ljPVKggFXZKmD-vrw8G6Vs6DvAokjsUG8FHh-F53cMsE-GDjyZH_1_CrlDCnbGlqjsFbgAylqA7IAJWp9_N6dL5p8DHZTwlZ4IV8L1CtCALs7XVqvcQKHCCzB63Y8PgVDCAqpQSRb79JPVD4pZwkBKpOknfEY5y9wfbswZiRKdgz7o61_oFnd-yywpse-23HD6v0htThVF1SuGL1PuvGJ8p334nt9bpkZO3gaTh1xVD_uJMwHzbuBCF33_f-I5QMZO6bVooXqGfe1zvl3nDrPEjq1aPulvtP8RgREYEqE6b2hB8jouTiC_WpE3qrdMw9sfWGFbm04qC-2Zjoa1yYSXoxmYd0SnliSYHAad9aXoEmFENezQV-of7sc-NX1-2nAXRAEhaqh0IRuJwB4_sG7SvQmnanwkz-sBYxKqkoFpOsZ6hblgPDOPYY2NAsZlYkjvAL2mpiInrsmY_GzGsfwPeAx31iozImX75rao8rm-XucAmCIkRlpBz6MYKCjQgyRz3UtZCJ2DYF4lKqTjphEAgclbYZ7KiCuTn9HualwtEmVzHHFneHMKl7KnRQk-9wjgiyQ5nlsVpCCblg6JKr9of4utuPO3cBvbjhB4_ueQ40cpWVOICcOLS7_w0i3pCq1ZKDEMrYDJfz87r2sU9kw1zeFQk with request id 26a3c251-7418-43df-bcc2-d4956726462e VERBOSE: Receive action: getMetaData VERBOSE: VssDatabase::getMetaData: VSS specific path =$[\u0026#39;Vehicle\u0026#39;] VERBOSE: Receive action: set VERBOSE: Set request with id 675a0cf6-fd12-47f3-8dd4-36ddf4b951bd for path: Vehicle.Speed with attribute: value VERBOSE: SubscriptionHandler::publishForVSSPath: set value 12.0 for path Vehicle.Speed Yay!\nSo, we\u0026rsquo;re able to connect to the server and send the necessary signals from the host. But this is only a working solution as none of the AGL demo apps listen on this specific ip 10.10.10.204 for kuksa updates.\nWhat Next? # During the Weekly GSoC and Dev meetings of AGL, Scott Murray pointed out that soon AGL will be moving to Kuksa-databroker (written in RUST) from the currently used Kuksa-val-sever. This should not affect my implementation as Kuksa-client works with both ( using Web-sockets \u0026amp; and gRPC). This will give us the window to update our implementation and come to a working solution by the time the coding period starts.\nI will also be updating my working repository on GitHub soon, and start work on coding the GUI elements of the Application.\nAll in all, the Community bonding period proved to be extremely educational and very interactive, not just with the AGL community but also with my fellow GSoC contributors. I can\u0026rsquo;t wait to get codding and look forward to overcoming the challenges that come my way.\nResources I Found Useful # https://docs.automotivelinux.org/en/master/ https://docs.yoctoproject.org/3.2.3/index.html https://github.com/aakash-s45/ic https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c https://github.com/eclipse/kuksa.val https://github.com/eclipse/kuksa.val/tree/master/kuksa-val-server https://github.com/eclipse/kuksa.val/tree/master/kuksa-client ","date":"26 May 2023","externalUrl":null,"permalink":"/articles/community-bonding-period/","section":"Blog Posts","summary":"# Topics To Be Covered In This Post # What is the Community bonding period?","title":"GSoC Community Bonding Period","type":"articles"},{"content":" What is FOSSEE? # FOSSEE is a project developed at IIT Bombay that promotes the use of FLOSS tools in academia and research. The project is funded by the National Mission on Education through ICT, Ministry of Education, Government of India. FOSSEE supports various FLOSS tools such as Scilab, Python, eSim, OpenFOAM, DWSIM, R, OpenModelica and more.\nMy work # Flatpak_Test_App (FOSSEE_Installer_Test): A proof of concept application, implemented using Qt5 and Flatpak Sandboxing. It provides features to:\nInstall python3 packages (Using the pip) in the user space Extract binaries and libraries from pre-compiled packages Compile packages from source and install them in the user space → View Project\neSim-Tool-Manager: It works to resolve various eSim dependencies, such as KiCad, Ngspice, Verilator, Makerchip, GHDL, and OpenModelica by installing them as modules based on the user\u0026rsquo;s preferences/ use cases. My work focused on adding general Linux support to the tool and writing install scripts for the various modules.\n→ View Project\n→ View Report\n→ View Certificate\n","date":"1 May 2023","externalUrl":null,"permalink":"/portfolio/fossee/","section":"Portfolio","summary":"What is FOSSEE?","title":"Semester-long Intern at FOSSEE, IIT Bombay (February - May 2023)","type":"portfolio"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","externalUrl":null,"permalink":"/stack/","section":"Stack","summary":"","title":"Stack","type":"stack"}]