It’s impossible to ignore, the, headlines. Every week, a new AI model seems to be released that can write code, fix bugs, and even build entire applications from a single prompt. We see impressive demos from Google, OpenAI and others, and it’s natural to ask the question on every developer’s mind: “Will an AI take my job?”

Programming vs. Engineering

Let’s be clear: the anxiety around AI is not unfounded. The act of programming—translating a well-defined requirement into code—is becoming increasingly automated. We see this with tools like GitHub Copilot becoming a standard part of the developer workflow, and companies like Cognition Labs with their AI agent Devin are pushing the boundaries of what’s possible. For tasks with clear inputs and outputs, like building a standard CRUD API or a simple web form, AI is incredibly effective because it excels at pattern matching on a massive scale.

This is a good thing. It frees us from rote work. But it’s crucial to distinguish this from the broader discipline of engineering. Engineering isn’t just writing code. It’s the messy, human process of architecting systems, making trade-offs, diagnosing emergent behavior, and maintaining critical systems over time. It’s about asking the right questions—a process that can take months—before a single line of code is written. What are the concurrency trade-offs for this database design? How do we scale this backend for a 100x increase in traffic? Should we scale now, or are we overprovisioning? An AI can’t answer these questions because the answers depend on business context, future goals, and deep systems knowledge.

This is where the future lies: not in being a better coder than an AI, but in being a better engineer who uses AI to offload tedious work. This distinction is vastly more apparent in the world of embedded systems.

War Stories

An AI can write a Python script to parse a file because it has seen a million examples. But can it debug a system where a single flipped bit in memory leads to catastrophic failure? This is where an embedded engineer’s real value lies. Here are a few examples from the real world.

Toyota’s Unintended Acceleration

Source

For years, Toyota faced reports of its cars accelerating without driver input. The initial blame was placed on floor mats. The real culprit, however, was a ghost in the machine. Expert testimony in court cases revealed critical flaws in the engine control unit’s firmware. The issues weren’t simple bugs; they were complex system failures like stack overflow, where memory management fails and causes unpredictable behavior. Critical tasks could be disabled by other tasks, and the code was riddled with thousands of global variables, creating a “spaghetti code” nightmare. An AI could not have debugged this. It required engineers with a deep understanding of real-time operating systems, memory management, and safety-critical coding standards (like MISRA C) to painstakingly trace the complex interactions that could lead to the throttle control system failing in an unsafe state.

Bricking Nest

Source

In 2016, a faulty firmware update rendered thousands of Nest smart thermostats unresponsive, effectively “bricking” them in the middle of winter. The problem wasn’t a server outage; it was a deep-seated embedded bug. The issue was reportedly a flaw in the device’s sleep/wake algorithm. When the device woke for routine tasks, the bug sometimes prevented it from returning to a proper low-power state, causing the battery to drain completely. Once drained, the device couldn’t function or even recharge itself. This is a classic embedded problem. An AI might write a sleep algorithm, but debugging it requires measuring micro-amps of current with an oscilloscope, understanding the power state transitions of every component on the board, and correlating that physical data with the software’s execution. It’s a perfect blend of hardware and software detective work.

Ariane 5

Source

One of the most famous software failures in history was the explosion of the Ariane 5 rocket just 40 seconds into its maiden flight in 1996. The cause was a single, catastrophic software error detailed in the official inquiry board report. Engineers had reused code from the slower Ariane 4 rocket that converted a 64-bit floating-point number representing the rocket’s horizontal velocity into a 16-bit signed integer. On the faster Ariane 5, the velocity value was much larger than the Ariane 4’s, and the number became too big for the 16-bit integer to hold. This caused an integer overflow, which the system interpreted as a flight path error. The rocket’s software did exactly what it was told to do with the bad data: it swiveled the nozzles to “correct” the non-existent problem, causing the rocket to veer off course and self-destruct. An AI, without the full system context, might see the data conversion code as correct in isolation. It took human engineers to understand the new physical constraints of the Ariane 5 and realize that the reused code was no longer valid.

Systems Endingeering

The war stories above highlight the true nature of embedded work: it is fundamentally systems engineering. An embedded engineer’s “IDE” isn’t just a text editor; it’s a collection of tools and documents that bridge the digital and physical worlds. To solve a problem, you must look far beyond the code itself.

• The Schematic: You have to read hardware blueprints to understand which processor pin connects to which LED, sensor, or motor driver. Is a pull-up resistor missing? Is the I2C bus shared? The answer isn’t in the code; it’s on the schematic.
• The Datasheet: A 1,000-page microcontroller datasheet is your bible. It contains the “API documentation” for the hardware. You need to understand the precise sequence of register writes to configure a peripheral, the timing constraints for a memory interface, or the exact current draw in different low-power modes.
• The Oscilloscope & Logic Analyzer: Your debugger isn’t just GDB. It’s a physical probe that lets you see electrical signals in real-time. Is a signal noisy? Is there a voltage drop when a motor turns on? Is the timing of an SPI signal meeting the spec? These are questions code cannot answer.
• The Laws of Physics: You can’t escape physics. Code that works perfectly on a dev board might fail in a hot engine bay due to thermal issues. A long wire might act as an antenna, picking up noise that corrupts your sensor data. Power consumption, heat dissipation, and signal integrity are your constant companions.

An AI can’t hold an oscilloscope probe, read a thermal camera, or understand the nuance of a datasheet that contradicts a schematic. The job of an embedded engineer is to synthesize information from all these disparate, messy, real-world sources. That is not programming; that is true systems engineering.

The future isn’t about competing with AI; it’s about leveraging it. We should welcome AI as a powerful assistant, and incredible tools already exist to handle the tedious parts of our job:

• Large Language Models: General-purpose LLMs like Gemini, ChatGPT, and Claude are fantastic for deep research and getting a second opinion on architectural decisions. With their vision capabilities, they can even analyze a screenshot from your oscilloscope or logic analyzer and help decode a complex timing diagram.
• Document-Grounded AI: Tools like NotebookLM or ChatPDF are game-changers for our line of work. You can upload a 1,000-page datasheet and start asking specific questions, like “What is the exact sequence to enable the ADC?” or “Summarize all low-power modes.” It turns a day of document searching into a 5-minute conversation.
• Hardware-Aware AI: Emerging tools like Flux Copilot are being built specifically for hardware design. They can help analyze schematics, suggest components, and even help debug PCB layouts, augmenting the physical side of our engineering work.
• RTOS-Aware Analysis: Specialized tools like Percepio Tracealyzer use sophisticated visualization and algorithmic analysis to find complex bugs in RTOS-based systems. They can automatically spot issues like priority inversion and task deadlocks that are nearly impossible to find with traditional debuggers.

This frees us up to focus on the work that truly matters: the complex, multi-disciplinary engineering that AI can’t touch. It allows us to spend more time with an oscilloscope, more time architecting a fault-tolerant system, and more time understanding the deep physics of the problem we’re trying to solve. In an age where routine programming can be automated, the systems-level detective work of an embedded engineer is not only secure, it’s more valuable than ever.

The workday begins. Laptop on, a glass of hot water for the perpetually sore throat (thanks, Bangalore weather), and a round of good mornings to the other early birds. I settle in to check my work.

And there it is: the overnight test failed with some interesting logs. I’ve spent a week chasing this exact bug, and this could be the break I need. The water is getting cold, forgotten as I dive in, making notes, checking hypotheses. I’m getting close. A new idea starts to form, and I have a good feeling about this one.

I’m deep in the zone when a tap on the shoulder breaks the spell. “Coffee?” I politely decline, eager to get back. But before I can, another voice calls from across the desk about a different bug, sparking a discussion. I try to pull my focus back, but just like that, it’s gone. The thread of thought is lost, the promising idea evaporated.

The True Cost of ‘Yes’: Why I Believe Boundaries Are Non-Negotiable

At every company I’ve worked for, no matter what my role, I knew that if I left, my position would be backfilled. The machine is designed to keep running. But at home, to my wife, my son, my parents, and my friends, I am irreplaceable. There is no backfill for that role, and I wouldn’t want there to be. The memories I have of eating messy mangoes on the balcony with my wife, or telling my son terrible dad jokes—those are the things that stick. I can’t remember the details of the few weekends I worked in my entire career, but I can remember the taste of the mangoes. That’s the real currency.

Many a time, we think of multitasking as a superpower, but I’ve learned it’s not. Every time I’m pulled from a complex problem, I pay a tax. It’s not just the five minutes of the interruption. It’s the hour I lose reloading that complex problem, and the creative reflections lost forever in the switch. When that happens frequently enough, I end up paying more in taxes than I earn in actual progress. This isn’t just about lost productivity on a feature; it’s about what that lost time truly represents, and ultimately, one of those dimensions pays the price.

This isn’t a manifesto against hard, passionate work, though. I’ve had those nights: it’s 10 PM, the team chatroom is silent, and I’m fueled by coffee and the thrill of the chase. Those nights are memorable, but the key difference is that I chose to be there, driven by my own passion, not by poor planning.

The Fear of ‘No’: The Real Reasons We Struggle to Set Boundaries

So if the cost is so high, why do we so willingly give up our focus? Let’s be honest, saying “no” feels confrontational. We’re often wired to be agreeable, and the fear of social friction or being seen as unhelpful can easily outweigh the need to protect our time. This is compounded by the very real pressures of career and job security. It’s easy to worry, “If I say no, will it affect my performance review? Will I be passed over for a promotion?” So we say yes to everything, hoping that sheer volume of work will keep us safe.

We often treat our energy like a credit card with no limit, telling ourselves, “I’ll just push through this crunch period, and then I’ll rest.” But “later” is a moving target. Another project always comes up, and we rack up a “burnout debt” that can’t be paid off with a single long weekend. Sometimes this debt also comes from within: we make a mistake, misjudge a timeline, and our first instinct is guilt. Instead of being transparent, we try to overcompensate, throwing our evenings and weekends at the problem because we’re afraid to own our mistake and ask for help.

Breaking this cycle requires a different kind of inspiration. When I look for it, I think of Satya Nadella. He has often said that his perspective on life and leadership was fundamentally reshaped by his experience raising his son, who had cerebral palsy. He learned a deep sense of empathy at home that became the foundation for transforming Microsoft’s culture. In his own words:

“It has shaped my personal passion for and philosophy of connecting new ideas to empathy for others. And it is why I am deeply committed to pushing the bounds on what love and compassion combined with human ingenuity and passion to have impact can accomplish with my colleagues at Microsoft.”

This shows that he didn’t succeed in spite of his family commitments; he succeeded because of the efforts he spent with his family. He is living proof that bringing your whole self to your job is what creates great leadership.

How I Built the Confidence to Set Boundaries

For me, the confidence to set boundaries didn’t come from a place of arrogance (hopefully), but from a place of security.

Adopting the “Two Hats” Philosophy

I have a “Work Hat” and a “Home Hat,” and I try to treat both as equally important. By investing in my life outside of work—nurturing my relationships, pursuing hobbies—I’ve built an identity that is separate from my job title. I read voraciously, I’m a pianist, I’m an avid gamer. These have become my “re-create-ional” anchor. It reminds me that a bad day at work is just that—a bad day at work. It’s not a reflection of my entire worth. I’ve found that a strong family and a strong sense of self don’t distract from a strong career; they are its foundation.

Building My Career Confidence

A huge part of being confident at work is knowing that people have my back. Knowing my wife, family, and friends (my emotional anchor) will support me emotionally if I ever need to leave a toxic environment is incredibly empowering. It’s my psychological safety net, and it allows me to say, “This isn’t right,” without the paralyzing fear of being alone. It gives me the courage to stand up for myself, a gift for which I’m incredibly grateful.

Building My Financial Confidence

This is the most practical pillar of confidence. I realized the fear of losing a job is often, at its core, a fear of not being able to pay my bills. Hence, financial literacy was one of the most powerful tools that we (my Wife and I) learned. Our goal wasn’t to become wealthy (but hey, who’s complaining if we get there), but to create options for ourselves. Having an emergency fund, living below our means, and understanding our finances means that we are not operating from a place of desperation. I can make career decisions based on our well-being and long-term goals, not on short-term financial panic. This financial cushion is what turns the terrifying prospect of saying “no” into a calculated, and often wise, business decision.

Practical Steps That Have Worked For Me

OK, that’s a lot of philosophy! So, what do I do tactically on a day-to-day basis?

Reclaiming My Calendar

• Block and defend my focus time. I block “Focus Time” on my public calendar and I treat it like any other important meeting.
• “Do Not Schedule” blocks. I block out time for lunch, personal appointments and time outside work with “DNS” blocks. This helps prevent my entire day from being consumed by meetings and respects my time outside of work.

Reclaiming My Meetings

• Push back on ad-hoc meetings. I try to use polite replies like, “Could we handle this over chat so I can give it my full attention after my current task?” or “Happy to connect. Could you share a quick agenda so I can prepare?” You’ll be surprised at how many issues can be resolved over a couple of chats rather than spending 30 minutes in a meeting.
• Go asynchronous. For many recurring meetings, A shared document or a chat thread is more efficient for everyone. A lot of credit to my team for pushing me on this equally.
• Effective 1-on-1s. 1-1s are important to get a sense of the person. But they can easily digress into chit-chat. I try to create a shared agenda doc, ask the other person to add to it beforehand, discuss what’s needed, and end the meeting promptly.

Reclaiming My Time

• Dedicating time with family. Everyone (including your family) has a busy life. Aligning everyone takes effort, but it’s effort that’s well worth to do every day to keep nurturing that connection.
• Being conscious of social breaks at work. Socializing at work is important, but many times a quick chat is turning into a major time sink that will derail my whole day.
• Commit to a strict end-of-day time. This has been a game-changer. It forces me to be more efficient. The goal is to fit my work into the container I’ve set, not to let it expand indefinitely.

Reclaiming My Reputation

• Remind myself that a “no” is a “yes” to my existing commitments. I’ve come to see saying “no” as an act of responsibility. It allows me to protect the quality of my current work. I’ve also learned that my reputation is built on reliability. Delivering consistently on my promises, even if I take on less, has been far better for my career than over-promising and under-delivering.

Setting boundaries isn’t about building walls or avoiding work, but rather about building a sustainable career. It’s about recognizing that my best work comes from a place of focus, not from a state of constant distraction. It’s about having the confidence to protect my time and energy so I can bring my best self to my team, and just as importantly, to my family.

This isn’t an overnight change. It’s a practice. If any of this resonates with you, I hope you’ll try one small thing tomorrow. Block consistent time with family every day. Say a polite “I can’t step away right now” to one request. It’s a small step, but neither Rome nor our lives are built in a day.

The internet has forever changed the way we interact with the world, and has deeply embedded itself into our lives. More and more devices are now connected and getting “smarter”! While the term “smarter” is debatable: I would like my TV to simply play what I command via the remote rather than tell me a million times “I can’t understand what you said” (thank you Alexa!).

As this revolution happens, a silent, albiet very powerful upgrade has been happening within our cars. And I don’t just mean that automobiles are getting connected and you can control them via your mobile, but how the various devices within a car talk to each other.

Evolution of the Electronic Control Unit (ECU)

An ECU is a small computer in your car that is responsible for controlling a specific feature (say brakes, traction control, steering, etc…). Over the years, the number of ECUs in the car have exploded from a few 10s of ECUs to more than 100s of ECUs in each car. No longer are these crucial components mechanically controlled. The original car used to have a brake pedal connected to the brake piston via brake fluid and transmits the pressure on the brake pedal to the brake pads to bring the car to a stop.

Mechanical braking - Image credit

Now, no more; when you press the brake pedal, a sensor ECU now collects the pressure on the pedal, encodes it into a message and sends it to another ECU that controls the brakes. The recieving ECU processes the incoming message, and then actuates not just the brakes, but the powertrain too to bring the car to a stop!

Audi e-tron’s electronic braking - Image credit

Explosion of ECUs

Thanks to the speed at which features are being added into automobiles, pretty much every function is turning into an electronic component.

The following image shows the different major electronic systems in the car. And this is still a very bird’s eye view and misses showing many of the sub-systems that exists.

ECUs in a car - Image credit

Thanks to this, the average number of ECUs in the car has been growing exponentially. A lot more due to the disruption by non traditional OEMs such as Telsa, Rivian, etc…

Average ECUs in a car - Image credit

And with this, the market has also been expanding rapidly.

ECU market - Image credit

Evolution of automotive networks

Given how the automotive ECU’s have exploded, the need for good and robust networking solutions have also increased! When it comes to automotive networks, there are two major segments:

• Control plane (powertrain, chassis, errors, etc…)
• Media plane (entertainment, infortainment, etc…)

This division is historical and has started merging into a single entity lately. But for the sake of a good story (who doesn’t like a good story, that too about networks /s), let’s understand the evolution here.

Control plane

The control plane is primarily focused on getting sensor data to actuators.

Sensor - Controller - Actuator - Image credit

Sensors are ECUs / components that sense different information, say the pressure on the brake / acceleration pedals; the fuel level of the car; a radar signal to measure the distance of the car in front; a crash sensor to inform if an accident is occuring, etc…

Actuators on the other hand are components that perform actions. A brake actuator that actually brings the car to a stop, an airbag actuator that deploys the airbag on certain condtions, a speed actuator that controls the speed of the car depending on the cruise-control or the driver’s acceleration input.

Between these two components is the controller ECU. This is the one that would recieve inputs from different sensors, understand the inputs and take decisions. For instance, an airbag controller would look at inputs from the crash sensor, but also from occupancy sensors (sensors that tell if a passenger is present or not). It would then check to see from other sensors to confirm a crash (say from a radar or from an inertial measurement unit) and then send an actuation message to airbag actuators where passengers are present to deploy the airbag. This of course is gross simplification since it would take many articles to talk just about the airbag flow.

For obvious reasons, this plane needs to be secure and safe. Secure meaning that it should not allow unauthorized access and safe meaning that an error (either in the ecu, or the network) should be immediately highlighted, there should be redundancies and the car should reach a safe state that minimizes the loss of life. This is covered in detail under ISO26262 and Automotive Cybersecurity. Topics for another day.

Media plane

The media plane is primarily focused on getting entertainment information to the passengers. Essentially getting netflix, youtube to our spoiled asses as we drive, allowing us to make calls in and out, etc… As more and more of the car gets autonomous, the main differentiating factor is the in cabin experience and getting the media plane right goes a long way in securing good customer experience.

As opposed to the control plane, the networks in the media plane is focused on bandwidth and latency. Safety and security are still important, but not to the same level as the control plane.

Automotive Networks

Now that we’ve detailed out the two planes, let’s look at the various different automotive network protocols that exist in cars today.

Automotive Networks - Image credit

Automotive Networks in car - Image credit

Now an obvious question would be, why the hell do we’ve so many networks and not just one! If only the world of engineering always agreed. Each of these networks evolved for a specialized use-case and they continue to be used either because they are already in production, and it’s difficult to change; or they solve a use-case so specific that a generic network cannot solve

The most popular networks are

• Controller Area Network (CAN): Developed by Bosch in 1983, it is still the most commonly used automotive network in the car for all things related to the control plane.
• Local Interconnect Network (LIN): Developed by a group of OEMs (BMW, Volkswagen Group, Audi, Volvo Cars, Mercedes-Benz) in 2002, LIN became the low cost, simpler alternative to CAN focusing on last mile connectivity again for control plane.
• Media Oriented System Transport (MOST): Developed by SMSC (today owned by Microchip) with the primary aim to address the media plane with bandwidth going from 25mpbs to 150mbps today. This is currently the defacto network in every car for entertainment data.
• Ethernet: Surprisingly Ethernet is yet to enter mainstream automotive networks in a big way. While most cars on road today have a small sprinkling of Ethernet and it’s growing exponentially, there is a big historical reason why it took so long for Ethernet to penetrate the Automotive market.

In the next edition of this series, we’ll talk about how the automotive network architecture has evolved and the networks themselves in more detail.

The below is the workflow yml that will build and deploy a maven war file to Elastic Beanstalk. If you’ve questions on how to use this, and why certain things are being used, fire away in the comments.

GitHub action for Java (using maven)

name: <name>
on:
  push:
    branches:
      - <branch>
  workflow_dispatch:
concurrency: <name>
jobs:
  <name>:
    name: <name>
    timeout-minutes: <time to wait before timeout>
    runs-on: ubuntu-latest
    env:
      CORRETTO_URL: https://corretto.aws/downloads/latest/amazon-corretto-8-x64-linux-jdk.tar.gz
    steps:
      - name: Checkout the code
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Cache jdk binary
        uses: actions/cache@v2
        with:
          path: ${{ runner.temp }}/jdk
          key: ${{ runner.os }}-jdk-8
          restore-keys: ${{ runner.os }}-jdk
      - name: retrieve latest corretto 8 jdk
        run: |
          test -d ${{ runner.temp }}/jdk || mkdir ${{ runner.temp }}/jdk
          test -f ${{ runner.temp }}/jdk/corretto.tar.gz || ( wget -qP ${{ runner.temp }}/jdk $ {{ env.CORRETTO_URL }} )
      - name: Set up JDK 8 from file
        uses: actions/setup-java@v2
        with:
          distribution: 'jdkfile'
          jdkFile: ${{ runner.temp }}/jdk/corretto.tar.gz
          java-version: '8'
          architecture: x64
          cache: "maven"
      - name: Enable caching
        uses: actions/cache@v2
        with:
          path: ~/.m2/repository
          key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
          restore-keys: |
            ${{ runner.os }}-m2
      - name: Create the installer after running the tests
        run: mvn clean install
      - name: Get the current time
        id: time
        uses: nanzm/get-time-action@v1.1
        with:
          timeZone: 8
          format: 'YYYY-MM-DD-HH-mm-ss'
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      - name: Upload the war file to AWS
        env:
          TIME: "${{ steps.time.outputs.time }}"
        run: |
          cp ./<project>/target/<filename>.war ./<project>/target/$TIME.war
          aws s3 cp ./<project>/target/$TIME.war s3://<s3 bucket name>/
          aws elasticbeanstalk create-application-version --application-name <app name> --version-label $TIME --source-bundle S3Bucket="<s3 bucket name>",S3Key="$TIME.war" --auto-create-application
          aws elasticbeanstalk update-environment --environment-name <env name> --version-label $TIME

AWS S3 and Cloudfront are fantastic infrastructure to deploy your production website (either static, say a simple HTML/CSS, or generated via a static site generator via Gatsby, Hugo, Jekyll, etc…); or a dynamic front-end (say using React, Angular, etc…). This post will cover on how to deploy an angular / react / vue code to S3 and Cloudfront.

This post assumes that you already have a working JS project (either Angular / React / Vue / etc…), and that you’ve setup AWS S3 bucket with a website endpoint

The post also assumes that you’ve your code hosted on Github.

CI/CD alternatives

There are many CI/CD platforms today, including Jenkins, GitHub Actions, Circle CI, Atlassian Bamboo, etc… Given that most of us end up using Github to host the code, and that GitHub provides free minutes to run the pipelines, it’s just a very convinient option without any significant downsides.

How does Github Actions work

Github actions can be triggered by many actions

• Manually
• On a periodic interval via a cronjob
• On pushing a new commit to a branch
• On creating / updating / deleting a pull request

Depending on the configuration, GitHub would simply create a new container (using very similar concepts to Docker) and do the job that you specify. The job could be anything. You could create a GitHub action to print “Hello World!”. Which is a nice way to test out things and get yourself comfortable with the idea.

Structure of the GitHub workflow file

A GitHub workflow file is basically a YAML file and follows the YAML syntax. This page provides an excellent reference for how the GitHub syntax is structured. If you are interested to learn the basics, please go through this before proceeding.

GitHub action to deploy Javascript code

To create a new GitHub workflow, you create a .github folder in the root of your project and then a workflows folder. Within this folder, you can add a <name>.yml to define your workflow / pipeline. Below is the code that you can directly use, and then we’ll break it down.

Note the below config uses yarn but you can replace it with npm if that’s your package manager.

name: <name>
on:
  push:
    branches: 
      - master
concurrency: <name>
jobs:
  <name>:
    name: <name>
    timeout-minutes: <time in minutes after which the job should timeout>
    runs-on: ubuntu-latest
    env:
      NODE_VERSION: '<Node version number>'
      S3_BUCKET: <s3 bucket ID>
      CDN_DISTRIBUTION_ID: <cloudfront ID>
      AWS_REGION: <aws region>
    steps:
      - name: Checkout the code
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Install node
        uses: actions/setup-node@v2
        with:
          node-version: ${{ env.NODE_VERSION }}
      - name: Get yarn cache directory path
        id: yarn-cache-dir-path
        run: echo "::set-output name=dir::$(yarn cache dir)"
      - name: Cache the dependencies
        uses: actions/cache@v2
        id: yarn-cache
        with:
          path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-
      - name: yarn install
        run: yarn --prefer-offline
      - name: build
        run: <your yarn command to build your site>
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: {{ env.AWS_REGION }}
      - name: deploy
        run: |
          aws s3 rm s3://${{ env.S3_BUCKET }}/ --recursive
          aws s3 cp ./target/www s3://${{ env.S3_BUCKET }} --cache-control 'public, max-age=31104000' --recursive
          aws configure set preview.cloudfront true
          aws cloudfront create-invalidation --distribution-id ${{ env.CDN_DISTRIBUTION_ID }} --paths "/*"

Let’s break the above down

Triggers

This page contains detailed information. In summary, the most conventional triggers used are as follows:

on:
  push:
    branches: 
      - master # Matches any push on the master branch
      - *asd* # Matches any branch that has asd in the name like basd, basdf, etc...
  pull_request:
    types:
      - opened # When a new PR is opened
      - reopened # When a PR is re-opened
      - synchronize # When a PR is updated

The above are your conventional triggers. So if you want to build and deploy anytime you push / merge to a branch (say the main / master). This is what we do in our original example. If you want to build each time a pull request is updated, so you get to test the bleeding edge work, then you can trigger it on pull_request -> types -> opened, synchronized.

Choosing the Runner

In the above example, we use ubuntu-latest. This could be the default choice for most people, but look at other options.

Naming the Job

A job has a name

jobs:
  <name>:
    name: <name>

Pretty straightforward. Everyone has a name (except if you are Arya Stark)! It’s just cruel to be nameless!

Defining environment variables

It’s a good idea to always defining common variables in once place, so you can easily use them in multiple places. Same as DRY

    env:
      NODE_VERSION: '<Node version number>'
      S3_BUCKET: <s3 bucket ID>
      CDN_DISTRIBUTION_ID: <cloudfront ID>
      AWS_REGION: <aws region>

In this case, let’s also define what these variables are.

• NODE_VERSION: This is straight forward. Simply put the node version that you’ve locally used to build the project. Also ensure to keep this aligned with your local version, so you don’t get surprises when you deploy
• S3_BUCKET: This is the name of the S3 bucket. Typically you want a name that is unique. In my case it would be dev.mohankarthik.xxx and since I own mohankarthik.dev, the naming convention becomes unique for me.
• CDN_DISTRIBUTION_ID: This is the ID of the cloudfront entry. You can skip cloudfront, but it’s pretty spectacular and I’d suggest enabling it even for hobby projects.
• AWS_REGION: The Region where your AWS account is hosted. us-east-1, etc…

Steps

This is where the money is. Now let’s dive in.

Each step has an name and either uses or run. uses essentially uses an existing module directly with no work from us. How cool is that. We get small open-source tasks to run and get us what we want. You can see the list of all existing actions here.

Checkout the code

      - name: Checkout the code
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

This piece of code basically checks your code out into the machine that’s building the code. fetch-depth being set to 0 basically means that it will do a shallow pull, only the current commit and not the entire history.

Installing node

      - name: Install node
        uses: actions/setup-node@v2
        with:
          node-version: ${{ env.NODE_VERSION }}

This installs the node version that you’ve specified in the env. For other frameworks / languages, change to the approrpriate setup. There are many existing actions to help setup other languages.

Caching

This is a really cool feature of GitHub (and many other CI/CD tools too). GitHub Actions will save all the dependencies (the infamous node_modules folder) into memory, and then the next time you run your workflow, it’ll restore the local version before trying to get it from the internet. Which will speed up the whole build significantly.

      - name: Get yarn cache directory path
        id: yarn-cache-dir-path
        run: echo "::set-output name=dir::$(yarn cache dir)"

The above part gets the directory where the cache will get stored and sets it as the yarn cache directory

      - name: Cache the dependencies
        uses: actions/cache@v2
        id: yarn-cache
        with:
          path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-

This is the part that actually caches all the dependencies after the first install. You can update this to your language of choice by changing the cache directory to where your framework / language will store the dependencies. .pub-cache for flutter, .m2 for maven, etc…

Install dependencies

This part is simple

      - name: yarn install
        run: yarn --prefer-offline

Call a console command to install all dependencies by calling yarn or npm install. You can do similar for other languages like pip install -r requirements.txt, etc…

This part will also automatically fetch from the cache specified ahead instead of fetching from internet if the cache already has data.

Build

      - name: build
        run: <your yarn command to build your site>

Simple as it is. Call the command line that you want to build the project. And can be customized for the language / framework of choice

Deploying to AWS

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: {{ env.AWS_REGION }}

Before we get to this section, we’ll need to setup an IAM account on AWS dedicated for this GitHub workflow. It’s generally a good idea to not use the same IAM account for multiple purposes, so create one just for this. Copy the Key ID and Access Key to GitHub Settings -> Secrets (the url would be something like https://github.com/<organization>/<repository>/settings/secrets/actions). This will then be accessible to the workflow in run time using the above script.

      - name: deploy
        run: |
          aws s3 rm s3://${{ env.S3_BUCKET }}/ --recursive
          aws s3 cp ./target/www s3://${{ env.S3_BUCKET }} --cache-control 'public, max-age=31104000' --recursive
          aws configure set preview.cloudfront true
          aws cloudfront create-invalidation --distribution-id ${{ env.CDN_DISTRIBUTION_ID }} --paths "/*"

This is the code that actually pushes the built distributable onto AWS.

• In this case the first line deletes the existing content on S3 so it’s a clean slate.
• Then the second line copies the entire website content to the S3 bucket. While doing so, it adds headers onto each object so that the browser fetching these information will cache it efficiently.
• The 3rd & 4th line invalidates the cloudfront cache, so the next time a browser requests for the data, it’ll get the latest objects that we just push.

Wrapping up

That’s pretty much it. Now all you need is to add this file into your repository and commit it in and watch the magic happen!

Since our planet first matured, the mountains have grown tall and proud. Even today the mountains continuously evolve with some growing a few centimeters each year due to the continued tectonic pressure. Too high did the mountains climb, so high that their peaks were covered with snow, and crowned white. And while they looked at each other and marveled at their splendid crowns, little did they know that they had just birthed their arch enemies.

As the sun shone it’s light and warmth on these tall mastiffs, the snow melted down and from there came the water streams. The mountains cared little for the tiny rivulets, as they did nothing more than to add to their proud beauty. As these streams, Brookes and rivulets met, they slowly gave rise to formidable rivers that thundered down these mountains. Even then the mountains cared little for they were confident in their tenacity and their strength. Who among this earth could ever change those majestic mountains, those that were made of earth and stone, those that could host entire forests on their slopes and those that could tower over even the clouds and look down upon the rest of the earth.

And yet the mountains failed to account that their off-springs would be just as tenacious and persevering as they themselves. The rivers were the great equalizers, and they wanted to chart a course through these tall peaks and level the field. And yet they knew that their objective wasn’t easy. They knew that the gallant and daunting mountains were not easy subjects who would bend to their wills. And so they persevered. At each turn, the rivers would try chipping away at the smallest bit of the mountain. They would fail a million times before they succeeded. And yet they knew that they only had to keep trying until they succeeded.

And thus began the longest battle that our planet has known. Mountains, who grew ever so slowly and aimed to persevere, and rivers that slowly tried to chip away at the mountains and level them. Who will win this battle is no longer relevant, as we unfortunately wouldn’t be here to witness the end. But there is much to learn from these two titans.

The mountains achieve their purpose through being gentle, patient and unmoving. They see the rivers chipping at them, and it would be easy for them to look at their losses and assume that eventually the rivers would beat them down, and yet they don’t lose hope. They stand tall, proud and steady. They persevere.

The rivers are aggressive, dynamic and yet they too are patient. They see their failures a million times each day as they try and try and fail at chipping away even the tiniest block off a mountain. It would be so easy for them to look at these failures and think that they would never achieve their goals, and yet they don’t give up. They dart this way and that, trying different things each time. They persevere.

In life too, at every step, in every venture that we take, we face uncertainties, we face hardships and we face losses. It is terribly natural for us to look at these losses and assume that we’ll never succeed. And yet, we see instances all around us, both among nature and people, of success that comes through perseverance. I’m of the belief that along with empathy and rationality, perseverance forms the holy trinity of mental traits that leads to a healthy life. It gives us the strength to fight through hardships and it evens us out during our successes. It keeps us going when there is nothing left to go on. And it’s the stuff that stories are made of.

This then is our quest. To find things that help us persevere. For me, it’s looking at stars as they chart a billion year life cycle across the cosmos, rivers sculpting their way through mountains, predators prowling all night to hunt their prey, mammals migrating thousands of kilometers to evade harsh weather, humans going to extraordinary lengths to protect each other and nature. Find things that inspire you to persevere and hold onto it. For it shall be the light in the darkest of the days and will make this journey of life a breeze to live on.

Some key points to take away from here.

1. You can have a common set of tests (such as trainable parameters, shape validation, etc…) written that can be re-used across all your ML code. Think of it as your common regression suite.
2. Look at Udacity’s Deep Learning code, most of the projects already have unit test stubs written so that the student can test against it, while developing their code. This is a great idea to continue during your own development as well.
3. And since most of ML is written in python anyway, it’s an even greater idea to pair Chase Roberts’s idea with python unit testing frameworks. Here are some fantastic articles to get you started.

Introduction

Path planning is an interesting problem. In essence, it’s the process of finding a safe, comfortable and efficient (in that order) path through a set of dynamic maneuverable objects to reach our goal. Now let’s break it down.

Traditionally, say if we wanted to find a route between a source and a destination, and we wanted to find the fastest / shortest path, there are tons of algorithms to do this: Dijkstra’s, Breadth First Search, [A](https://en.wikipedia.org/wiki/A_search_algorithm), etc…. But in a road scene, whether it be a highway or urban roads, one of the most important difference is that the scene is not static. So our plan needs to be a dynamic one too.

What complicates the scenario even further is, while we can track the other objects with Sensor Fusion(dynamic such as other cars, pedestrians, bikes, etc…., and static such as trees, curbs, lamp posts), the dynamic object’s behaviour can dynamically change; i.e: they can be maneuvered. So a simple extrapolation based on the current tracked information, say from a Kalman Filter, would be insufficient for the task, as the car could suddenly change lane, or the pedestrian could suddenly stop midway during a road cross to message someone (those idiots!! :P).

Behaviour prediction of Maneuverable Objects

So the first step is to predict the behaviour of all dynamic objects on the scene, and then based on this, predict a trajectory for each of the them. This is a pretty difficult task, since each of the object on the scene have a lot of choices in them. The method to solve them is to use something that is known as multiple-model algorithms for maneuvering target tracking. These methods allow us to evaluate multiple different models (such as: continue straight, turn left, turn right, slow down, speed up, and combinations of these) simultaneously for each of the object, and then based on the current observation (do we see him speed up, or turn, etc…) the algorithm would assign a probability to each of the model for each of the object. Once the probability reaches a certain threshold, we could assume that behaviour for that object and generate a predicted trajectory for that object based on that behaviour.

In my current implementation of the path planner (shown at the end of this article), this step is not implemented, as an extensive behaviour prediction was not necessary for the case of a simple highway driving. But for urban driving scenes, this almost becomes mandatory. Think of a intersection ;).

Behaviour Planning

Now that we’ve the predicted trajectories of each of the objects around us, the next step is to plan our behaviour. Do we in turn, speed up, slow down, change lanes, etc… This comes down to two things (and I’m going to be specific to highway scenario).

1. Estimating a score for each lane, to determine the best lane for us to be in (efficiency)
2. Evaluating the feasibility of moving to that lane in the immediate future (safety & comfort)

So the three factors that we mentioned in the problem statement are covered here in the two points.

Ranking Lanes

The method I took to rank lanes are using the following 3 factors

1. The lesser the number of lanes we need to change, the better. Because the lesser we change lanes, the more comfortable the drive is for the passengers (takes care of comfort)

1. The distance of the car ahead of us in that lane. The more the distance, the better the score

1. The velocity of the car ahead of us in that lane. The greater the velocity, the faster we can travel in that lane, before being forced to change lane again.

Note:

1. If a particular lane does not have any car ahead of us, then it would get the full score of the corresponding weights for velocity & distance scores.
2. We could augment this with other factors such as number of cars ahead of us in that lane, slowest car ahead of us in the lane (not just the closest car), include the behaviour prediction we talked about in section 1, etc…

Feasibility Checks

Now that we’ve ranked the lanes, we now need to check if transition to that lane is feasible or not! This is done with the following flow.

1. Loop across the lanes in the order from best to worst lane.
2. If the currently looped lane is our current lane, then nothing to do, everything is great, keep moving, break the loop.
3. If not, then check if the new lane would be jerk & collision feasible. The sections below explain how this is done.
4. If they are feasible, then increment a vote count, just so that we don’t take instantaneous decisions. We want to take decisions after pondering them over several timesteps. So once this vote count reaches a threshold, we can take up the decision.
5. Once the votes are there, then we output the desired d: the destination lane and the desired s/time: the velocity.
6. The s/time parameter is essentially based on the car ahead of us and if there is no car, then it aims for the maximum velocity without breaking the speed limit.

Jerk & Collision Feasible checks

There are many different ways this can be done. The way I chose to do here is the following

Experimentally, I identified that at the speed limit of 50mph, a single lane change is always jerk feasible. This is automatically taken care by the trajectory generation described below. But a double lane change has chances that it would jerk too much (this depends on the road curvature). If the road is curving in one way, and we try to jump 2 lanes in the other direction, then there is a chance that we would violate the jerk limit. So for jerk checks, I just check that the current speed should be less than a threshold if we are doing more than a single lane change.

Collision feasibility is more interesting. Essentially, we want to ensure that there is a good 2 or more car length gap between our car and the other cars in the destination lane and all the intermediate lanes (in case of more than a single lane change). We should also consider in the velocity of the other cars while coming up with this window, i.e: a fast car behind us means we need more window behind us, a slow car ahead of us means we need more window ahead of us.

Trajectory Generation

This is by far the most critical and the most difficult step to implement in this entire project. The solution I implemented is inspired from John Chen: the idea of converting all coordinates to local car’s co-ordinate system to make things easier.

In this, I heavily depend on ttk:spline for most of the trajectory generation.

The Udacity simulator gives us the previous path after removing all used up points. This is a great starting point for the algorithm which essentially is:

1. Create a spline of the nearest surrounding waypoints in the car’s reference frame. The waypoints must be converted to the car’s reference and should be aimed for the ‘s/time’ and ‘d’ output from the behaviour planner. Let’s call it the waypointSpline. This essentially gives us the ideal path we want to be in.
2. Create another spline with the previous path as the starting points (you could use a subset of the previous path too for more agile response). And add points from the waypointSpline into this. This spline is now the LaneTracker. This now clubs the path that we currently are with the ideal path, making a smooth trajectory from start to finish.
3. Create another spline (see what I meant when I said heavily depend), to smoothen the velocity changes from the current velocity (can include all previous path velocities) to the destination velocity (s/time). Let’s call this VelocityTracker. This ensures that we can follow our ideal trajectory without violating jerk / speed constraints.
4. Now we can generate the trajectory in the local car’s reference, by estimating the x using VelocityTracker for each time instant. Then use this x as input to the LaneTracker to generate the y. Convert these points back to the world coordinates and feed them back to the simulator, and voila you are done.

Emergency Braking

During testing the system, once two other cars in front of ours collided and came to a stand still. The fact that I was using the entire previous path as input to the LaneTracker & VelocityTracker spline, meant that the car was too slow to react to this resulting in collision. So I implemented a emergency braking solution, that would ignore the previous path and hard set the trajectory to the maximum braking capable (controlled by jerk) by the car. Fortunately / Unfortunately I never got to test this on the sim, as another accident did not

Results

The resulting video is the following

Future Work

There is still a lot of things that can be done to improve this

1. Add in behaviour prediction for each dynamic object using multiple-model algorithms that will allow the system to react much better & faster to the dynamic changes.
2. Improve the lane scoring using other parameters and see improvements.
3. Improve the emergency braking system and test it more (might need simulator upgrades)
4. Incorporate Q learning and RL to weave through the traffic (also need simulator upgrades to pass images via telemetry)

Acknowledgements

Great thanks to the community. Some of these ideas are inspired from discussions on the forums / slack / etc… The stalwarts in the community such as John Chen, Vivek Yadav have been a continuous inspiration to all of us. Also definitely thanks to the Udacity instructors David Silver and the team from Mercedes.

• Perform a Histogram of Oriented Gradients (HOG) feature extraction on a labeled training set of images and train a classifier Linear SVM classifier
• Optionally, you can also apply a color transform and append binned color features, as well as histograms of color, to your HOG feature vector.
• Note: for those first two steps don’t forget to normalize your features and randomize a selection for training and testing.
• Implement a sliding-window technique and use your trained classifier to search for vehicles in images.
• Run your pipeline on a video stream (start with the test_video.mp4 and later implement on full project_video.mp4) and create a heat map of recurring detections frame by frame to reject outliers and follow detected vehicles.
• Estimate a bounding box for vehicles detected.

This article will cover the first two steps.

Visualizing the data

The first step always is to see what we’ve got. And here is the data from Udacity. Some examples of cars and non-cars that we’ve are

Some things to note here are that each image is a 64x64. And there are about 8k images of each type. Which considering that the background class is pretty much everything other than car, I guess is a pretty small image set.

Image Features

The course suggests to use a combination of multiple image features. Once again we are doing this detection using traditional CV techniques as opposed to using modern CNN architectures like YOLO / SSD.

So we’ve the following image features along with the following parameters for each image features

• Spatial binning (features directly extracted from the image pixels): Color space of the image (commonly used for other features too); Size of the image to be binned
• Color histogram: Number of histogram bins
• Histogram of oriented gradients (HOG): Channel used, Orientations, Pixels per Cells, Cells per block

Choosing the parameters

In terms of choosing the parameters, we’ve two major rationales. One is speed, we don’t want to wait for ages for the classification to happen, and in the best case, we want it to be real time. The other is accuracy. So the parameter decisions is a trade-off between these two attributes.

Visualizing the parameters

Once again the shortcut is to visualize the parameters to get an intuition of how they work.

We can see that for the RGB color space, all the 3 channels give us a very different spectrum across the histogram. So this looks good.

Here, the Y channel gives a good difference, but the Cb and the Cr channels look almost similar. So does not look like a good choice.

Here, we see a decent difference in S and V channel, but not much in the H channel. So maybe in terms of color histogram, RGB and the S & V channel of HSV are looking good.

Great! Now let’s visualize the HOG parameters.

The combinations used here are

1. Orientations = 8, Pixel per cell = (8,8), cells per block = 2
2. Orientations = 9, Pixel per cell = (8,8), cells per block = 2
3. Orientations = 8, Pixel per cell = (16,16), cells per block = 2
4. Orientations = 9, Pixel per cell = (16,16), cells per block = 2
5. Orientations = 8, Pixel per cell = (8,8), cells per block = 1
6. Orientations = 9, Pixel per cell = (8,8), cells per block = 1
7. Orientations = 8, Pixel per cell = (16,16), cells per block = 1
8. Orientations = 9, Pixel per cell = (16,16), cells per block = 1

The first option looks great! Nice clear markings for the car image, and a clear difference between the car and non-car image

Now let’s look at the color spaces within HOG

We get almost the same result as we got in the color histogram, which is a great reaffirmation for the data. The YCbCr gives a differential performance only for the Y channel. Whereas all 3 channels in RGB gives us a difference. The Hue in HSV is almost similar, but the S and V show a nice difference.

Training the Classifier

Before we train, we need to ensure that all the features are normalized. WE can use the StandardScaler in sklearn to get this to work easily.

Let’s actually train the SVM and check SVM’s accuracy to see if it corresponds to the data that we’ve got till. In the following experiment, I fixed the hog orientations to 8, hog pixel per cell to be 8 and cells per block to be 2. I’ve also fixed the spatial binning size to be 16x16 and the color histogram bins to be 16. The only variations are the color space.

• Y channel of YCbCr (no spatial binning or color hist): 93.53%
• RGB (all 3)(no spatial binning or color hist): 96.07%
• SV channel of HSV(no spatial binning or color hist): 95.97%
• SV channel of HSV (with spatial binning or color hist): 98.51%
• HSV (all 3)(with spatial binning or color hist): 98.86%
• RGB (all 3)(with spatial binning or color hist): 97.73%

Awesome. So we’ve got our winners. It’s HSV, where the H channel is optional (trading off speed to accuracy). So that covers the feature extraction part of the Vehicle Detection.

As alternatives, you can also look at a standard CNN as a feature extractor.