Another of my roles was to be the sole contact for a project that would act as the mediatory between the project team and the CI team. Leading all of the integration of CI feature such as build tool configuration, Quality gating, automated software testing, sourcecode to requirement linking and Artifctory deployment of all of the files and reports generated during “master merge event”/tag release builds and CI runs. I was in this position for around 3-4 months, in this time I worked closely with higher project management as well as project developers to make sure that every feature they wanted was implemented, as well as configured as intended. Another important aspect was to improve the efficiency of certain runs, such as reducing scope of documentation to eliminate redundant or legacy code which added to build times.

For the majority of my time at Continental, I was working as a part of a DevOps/KanBan team that tackled issues in the CI system both tool-sided and project-sided. This work was based off KanBan tickets that were created by users (project maintenance), or senior CI management (tool maintenance). In this role I became familiar with cMake, gTest automation, QAC and requirement to sourcecode linkage, all being contained and managed through our in-house build-tool which enabled automation on a Jenkins server for each repository.Project issues would usually present themselves when a project had not been configured properly, or if they were trying to extract functionality that was out of the scope of the default CI Pipeline, where intimate knowledge of the build system was necessary. Tool maintenance issues were usually optimisations (e.g. moving static location to geo-based Artifactory servers) or feature development (e.g. option to have QAC run only on delta/changed sourcecode, not the whole codebase).

One of the projects I was assigned to do outside of CI was the Camera Perception Development Kit which entailed sourcing resources, collecting contacts for each aspect of the project, creating wiring harnesses and setting up an Nvidia Orin with the correct Linux OS and installing the proprietary CPDK software along with its dependencies. Goals: There were two main goals, one was to get an in-house setup that was a copy of one in a different location, the second was to document all steps of setup, and collate resources that were useful in either setting up the system or showed what work and testing had been performed on the setup at the other site.Skills gained/applied and opportunities created: This setup process, outside of sourcing hardware, took place over a month. In that time I improved my networking (social) skills, talking with people in locations outside of the UK (Tolouse) going to them with issues encountered during the setup, along with some initial resources on what was needed both hardware and software wise. Once I had placed orders for the necessary hardware, setting up the wiring harness for the automotive cameras to interface with the ethernet gateway was the next step, finding datasheets to identify which pins were necessary and where to wire them between the 2 connector types. An opportunity that arose once the kit had been completed was an investigation into an issue one team was facing with the same model of camera’s, identifying whether the camera firmware itself was the cause, or the in house software was doing some pre-processing, an investigation that I led for around 3 weeks, offering the team a solution by the end, which was to use a few parameters while flashing to unlock the firmware allowing full resolution(usually cropped) to be output.

At Continental I was also given the opportunity to choose my own projects if we could show added value, while in between main projects. One of these was a feature for the build tool, used to setup environments, install dependencies and compile projects. The build tool was used across the company on every project and allowed you to specifiy different variants to build as each project would either have multiple features, or require different platform compilations to run gTest/Documntations etc. This tool, while useful, was not the most intuitive, usually an integrator working on the project setup would create a batch script that would give the correct flags to build each of the key variants. This would need to be hard-coded as each project would follow different naming conventions. Scope: Create a feature for the build tool that would allow users to follow an intuitive CLI (command-line interface) to select the variant and parameters to be used as arguments for the build step.Key Points: To identify the information about the project you could read the build.yml file every repo was set up with (a pre-requisite for a project to work with the build tool), as you could read this as a dictionary it was simple to extract the needed information, one issue was to identify which version of the yaml was used, as there were different iterations and styles, so reading through the CI Developer documentation was need to identify each variation that was allowed.

Scope: This projects goal was to design a robotic base from scratch and run the model in simulation to demonstrate its functionality. Most ideologies from this project were based around the use of ROS.Action: I began this project by creating a URDF model, giving a base to work around. The URDF contained plugins that allowed sensors to be emulated. I could then work on creating a ROS package that handled beginning the simulation and started up the SLAM nodes. Result: Some problems that I had to overcome were the integration of realistic sensors into the simulation environment. There was plenty of documentation available which assisted in finding the issues and ensure that the correct functions were being added to the model to allow for realistic data communication between the “sensors” and “processor”.

Scope: The main goal of this project was to create a python script that could identify the shape and colour of objects shown to a webcam. Action: To begin this project, I first had to research different approaches for distinguishing shapes and colours. As the objects were of a pre-known set of colours, an option was to use a colour mask to identify a set of shapes of that colour, and then separate them out using contour generation. An additional option was to create a fixed morphology and use contouring to find every shape. I decided for go for the latter option as this opened up more options, and the code would not have to change if an additional colour was added to the set of objects. Result: Most issues arose when finding which functions were best suited for each functionality as there are a wide variety of prebuild modules for each application, researching each and finding the benefits/drawbacks of each methodology was key in finding a good fit.

Scope: The goal of this project was to design and develop a 2-wheeled system that could maintain an indefinite balance, as well as pick up a squash ball. Using LabView and a National Instruments single-board computer.Action: This was a team project with groups of 2, I was the team leader, it was my task to allocate areas of the project between our team and pick up any slack where time constraints needed to be met. I created the original CAD model that would house all the electronics and used a laser-cutter as well as additional workshop machines to build the base. Another responsibility of mine was to assist with the programming of the device. Result: Some issues arose while managing the balance while items were gripped, as there were limited sensors available. It was difficult to automatically find the centre of mass. An experimental idea became the solution to this, by compounding PIDs, using one to adjust of setpoint of the other.

Scope: The goal of this project was to create code that could communicate with my computer vision code, sending movement instructions to a robotic arm though the use of MoveIt Commander instructions. As the previous project could already identify shapes, the work would be converting locations in the image, to locations in a 3-dimensional space that the arm could understand.Action: The first step was to adapt the code from the computer vision to give pixel locations and size of object. Once these were gathered, a transform could be applied to convert the pixel locations in the image to the real-life locations that could then be given to the MoveIt commander code, facilitating the movement of the robotic arm.Result: Some issues surfaced when using movement commands originally, ensuring that the arm knows what the bounds of its operation are, including defining any fixtures within its reach. Ensuring all parameters are set correctly prevented collisions though poorly generated paths for the arm.