Forem: Sumit Shingole (BTech CSE 2025-29)

Case Study on use of AI in Tesla Autopilot

Sumit Shingole (BTech CSE 2025-29) — Sat, 04 Oct 2025 19:38:38 +0000

1. Problem

Driving requires constant attention — watching for other cars, pedestrians, traffic lights, and unexpected hazards. Human error causes most car accidents. Tesla wanted to reduce accidents by building an AI system that could assist or even drive the car.

2. How Tesla Autopilot Works

Step 1 – Sensors & Cameras

Tesla cars are equipped with multiple cameras, radar, ultrasonic sensors.
These act like the car’s eyes and ears.

Step 2 – Data Collection

The sensors capture information: lane markings, vehicles, pedestrians, traffic lights, speed signs, etc.

Step 3 – AI Processing (Neural Networks)

The car’s onboard computer uses deep learning (neural networks) to understand the environment.
Example: It learns to recognize a stop sign even if it’s partly covered by a tree.

Step 4 – Decision Making

The AI predicts what will happen next (e.g., another car changing lanes).
Then it decides: slow down, accelerate, steer, or stop.

Step 5 – Continuous Learning

Each Tesla sends driving data back to Tesla’s servers.
AI improves over time using millions of real-world driving examples.

3. Simple Diagram

Sensors & Cameras → Data Collection → Neural Network AI → Driving Decisions

4. Real Impact

Reduces accidents caused by distracted or tired drivers.
Helps with lane keeping, parking, and adaptive cruise control.
A step toward fully self-driving cars in the future.

In simple terms: Tesla Autopilot is like giving the car a brain and eyes so it can drive itself safely, just like a human driver but powered by AI.

Digital Ethics: The Dark Reality of Deepfakes

Sumit Shingole (BTech CSE 2025-29) — Sat, 04 Oct 2025 19:14:30 +0000

In the digital era, technology has blurred the line between what is real and what is fabricated. One of the most alarming developments in this landscape is deepfake technology — the use of artificial intelligence to create hyper-realistic videos or audio clips that convincingly imitate real people. While this technology has creative and educational applications, its misuse poses a serious ethical threat to truth, privacy, and democracy. I firmly believe that deepfakes represent one of the most dangerous ethical challenges of our time, and we must act decisively to regulate and counter their misuse before they erode public trust entirely.

Deepfakes first appeared as a fascinating demonstration of AI’s power to synthesize human likeness. Initially, they were used in entertainment and satire — for example, digitally inserting actors into movie scenes or generating realistic visual effects without expensive filming. However, this innovation quickly took a darker turn. In recent years, deepfakes have been weaponized to create false political propaganda, non-consensual pornography, and financial scams. A report by Deeptrace in 2019 found that over 90% of all deepfakes online were pornographic and targeted women, highlighting severe gender-based exploitation. The technology that was meant to entertain has now become a tool of manipulation and harassment.

The ethical issue lies in consent, authenticity, and accountability. Deepfakes can be produced without a person’s permission, violating their privacy and dignity. For instance, deepfake videos of public figures making false statements have been circulated during elections, threatening the integrity of democratic discourse. In 2022, a deepfake video of Ukrainian President Volodymyr Zelenskyy urging troops to surrender circulated widely before being debunked — a dangerous example of how misinformation can spread faster than truth. Such incidents demonstrate that deepfakes undermine public trust in digital content and can even endanger national security.

Some argue that deepfakes are simply another form of free expression or digital art, suggesting that banning them entirely would stifle creativity. While artistic and educational uses should not be dismissed, the line between creativity and deception must be clear and enforceable. Freedom of expression does not grant the right to deceive, defame, or harm others.

To address this ethical dilemma, a multi-layered approach is essential. First, governments should introduce strict legislation requiring deepfake creators to label synthetic content clearly, similar to “AI-generated” watermarks. Second, social media and content-sharing platforms must develop AI-based detection systems capable of identifying and flagging manipulated content in real-time. Third, digital literacy education should be promoted among users to help them recognize and question suspicious content instead of sharing it blindly. Finally, the AI research community must establish ethical guidelines that prioritize transparency, consent, and accountability in the development of generative models.

In conclusion, deepfakes are not merely a technological issue; they are a profound ethical crisis that challenges our understanding of truth and identity in the digital world. If left unchecked, they could destroy the very foundation of trust upon which communication, journalism, and democracy rely. We must strike a balance between innovation and integrity — encouraging creative uses of AI while enforcing ethical boundaries that protect individuals and societies from deception. The future of digital ethics depends on our ability to tell the truth — and to ensure that technology does not make truth optional.

Smart Security Camera

Sumit Shingole (BTech CSE 2025-29) — Sat, 04 Oct 2025 18:48:07 +0000

1. Cloud Computing Architecture

How it works:

- Camera captures video and sends it to the cloud server.
- Cloud processes motion detection, face recognition, and storage.
- User accesses footage remotely via the internet. Diagram:

Camera → Internet → Cloud Server → User App

Pros:

Centralized data storage (accessible anywhere).
High computational power for AI features.
Easy updates and scaling.

Cons:

Requires constant internet connection.
High latency in video processing.
Privacy and data security risks.
Ongoing cloud storage costs.

2. Edge Computing Architecture

How it works:

Camera sends video to a nearby edge device (e.g., a home hub or local gateway).

Edge device processes motion detection, compresses data, and only sends alerts or summaries to the cloud.

Diagram:

Camera → Edge Device → (Optional) Cloud → User App

Pros:

Lower latency (faster alerts).
Reduced cloud bandwidth usage.
Better privacy (less raw data sent online).
Works partially even with limited internet.

Cons:

Edge device adds hardware cost.
Limited processing power compared to cloud.
Some dependence on internet for storage or remote access.

3. Local Computing Architecture

How it works:

All video processing and storage happen within the camera or on a local DVR/NVR.
No internet connection required for functioning. Diagram:

Camera → Local Storage / Local Monitor

Pros:

1.Very low latency.
2.Full privacy (no data leaves home network).
3.Works offline completely.
4.One-time setup cost, no subscription.

Cons:

Limited storage capacity.
No remote access (unless manually configured).
Hardware upgrades needed for better AI features.

Feature	Cloud	Edge	Local
Latency	High	Medium	Very Low
Internet Dependence	Full	Partial	None
Privacy	Low	Medium	High
Cost (Long-term)	High (subscription)	Medium	Low
AI Processing Power	High	Medium	Low–Medium
Scalability	Excellent	Good	Limited

🏁 Conclusion

For a smart security camera,

Cloud computing is best for heavy AI analytics and global access.
Edge computing offers a great balance of performance, privacy, and cost.
Local computing is ideal for privacy-focused or offline use cases.

Data Flow Diagram — Online Food Delivery System

Sumit Shingole (BTech CSE 2025-29) — Wed, 01 Oct 2025 08:20:22 +0000

I'll pick Online Food Delivery (nice balance of actors & flows). Below are a simple Level 0 (Context) and a more detailed Level 1 DFD. I’ll give a clear ASCII-style diagram for each plus a short explanation of processes, data stores, external entities, and major data flows so you can redraw it in draw.io / Lucidchart / Visio easily.

Level 0 — Context diagram

  +-----------+       (place order, view menu)       +-----------------------------+
  | Customer  | -----------------------------------> | Online Food Delivery System |
  +-----------+                                      +-----------------------------+
     ^  |                                             |  ^   ^    ^     ^     ^
     |  | (order status, confirmation, invoice)      |  |   |    |     |     |
     |  +<-------------------------------------------+  |   |    |     |     |
     |                                                 |   |    |     |     |
     |                                                 |   |    |     |     |
     |                                                 |   |    |     |     |
  +-----------+   (accept/reject order, menu data)     |   |    |     |     |
  |Restaurant | <---------------------------------------+   |    |     |     |
  +-----------+                                             |    |     |     |
     ^  | (delivery assignment, pickup confirmation)       |    |     |     |
     |  +<-------------------------------------------------+    |     |     |
     |                                                       |     |     |
  +----------------+   (payment auth / refund)               |     |     |
  | Payment Gateway | <---------------------------------------+     |     |
  +----------------+                                             |     |
     ^  | (delivery details, tracking)                          |     |
     |  +--------------------------------------------------------+     |
     |                                                                |
  +------------------+   (pickup/deliver info)                       |
  | Delivery Partner | <----------------------------------------------+
  +------------------+

Entities

Customer — places orders, views status.

Restaurant — receives orders, confirms, prepares food.

Delivery Partner — receives pickup/delivery tasks and updates status.

Payment Gateway — processes payments and returns success/failure.

System (single process at Level 0): Online Food Delivery System — receives inputs and returns outputs to the external entities.

Level 1 — Decomposed processes

Break the system into 4 main processes:


             +---------------------+
   Customer  | 1.0 Order & User    |<----- User signs up / logs in
   (UI/API) -> Management         |
             +----+---+---+-------+
                  |   |   |
   (menu req) --->|   |   |---> (store order) ---> D1 Orders DB
                  |   |   |
                  |   +------------> D2 User DB
                  |
                  | (order placed)
                  v
             +---------------------+
             | 2.0 Restaurant      |<--- Sends menu, receives order
             |    Management       |
             +----+---+---+-------+
                  |   |
   (accept) ------+   +---- (update menu) --> D3 Menu DB
                  |
                  v
             +---------------------+
             | 3.0 Delivery         |<--- Assigns delivery partner
             |    Assignment &      |
             |    Tracking          |
             +----+---+---+-------+
                  |   |
   (assign) ------+   +-----> D4 Delivery DB (status, location)
                  |
                  v
             +---------------------+
             | 4.0 Payment         |<--- Calls Payment Gateway
             |    Processing       |
             +----+---+---+-------+
                  |   |
   (auth req) ----+   +----> D5 Payments DB (txn records)
                  |
                  v
             (send confirmation to Customer)

Formal list of components
Processes

1.0 Order & User Management

Actions: user authentication, display menu, take order, validate inputs

Inputs: customer requests, menu data

Outputs: order to Restaurant process; order records to Orders DB; user data to User DB

2.0 Restaurant Management

Actions: send/receive menu changes, accept/reject orders, update preparation status

Inputs: order details

Outputs: order acceptance/rejection, preparation status to Delivery & Customer

3.0 Delivery Assignment & Tracking

Actions: find nearest available delivery partner, assign, track location, update delivery status

Inputs: ready-for-pickup notification from Restaurant, delivery partner availability

Outputs: assignment to delivery partner, live tracking to Customer, delivery updates to Orders DB

4.0 Payment Processing

Actions: compute total (taxes, fees), call Payment Gateway, capture/refund

Inputs: payment details from Customer

Outputs: payment confirmation to Customer & Orders DB, refund if needed

Data Stores

D1 Orders DB — order records, status history.

D2 User DB — profiles, addresses, preferences.

D3 Menu DB — menus, prices, availability.

D4 Delivery DB — delivery partner statuses, routes, tracking logs.

D5 Payments DB — transaction logs, receipts, refunds.

External Entities

Customer — frontend web/mobile app or API client.

Restaurant — restaurant management system / vendor portal.

Delivery Partner — mobile app for couriers (accept/complete jobs).

Payment Gateway — external payment processor.

Important data flows (examples)

Customer → 1.0: Place Order (items, address, payment method)

1.0 → 2.0: Order Details

2.0 → 1.0: Order Confirmation / ETA

2.0 → 3.0: Ready for Pickup (order id, pickup location)

3.0 → Delivery Partner: Dispatch (order id, pickup, dropoff, contact)

Delivery Partner → 3.0 → Customer: Live Location / Delivery Status

1.0 → 4.0 → Payment Gateway: Payment Authorization / Capture

Payment Gateway → 4.0: Auth Response (success/fail)

Quick notes (how to present / draw)

Use circles/rounded boxes for processes, open rectangles for data stores, and squares for external entities. Use labelled arrows for data flows.

Number processes (1.0, 2.0...) so it’s easy to reference.

For assignment in Level 1, show direct flows between processes (e.g., 2.0 → 3.0) and to/from data stores.

If required in an assignment, include security flows (e.g., encrypted payment data, tokenized card data) or error flows (payment failed → roll back → notify customer).

Mini Software Project using SDLC (Calculator App)

Sumit Shingole (BTech CSE 2025-29) — Wed, 01 Oct 2025 08:02:38 +0000

Requirement Analysis

Objective: Build a simple calculator that can perform basic arithmetic operations.

Functional Requirements:

User should be able to input two numbers.

App should support addition, subtraction, multiplication, and division.

Display result clearly.

Non-functional Requirements:

Simple, fast, and user-friendly interface.

Should handle invalid inputs (e.g., division by zero).

2. Design (with Wireframe/Sketch)
Wireframe (UI Design):

+---------------------------+
|      Simple Calculator    |
+---------------------------+
|   [   Input Box 1    ]    |
|   [   Input Box 2    ]    |
+---------------------------+
| [ + ] [ - ] [ × ] [ ÷ ]   |
+---------------------------+
|       Result: ____        |
+---------------------------+

Two input fields for numbers.

Four buttons for operations.

A result display area.

3. Development (Pseudocode)

Start
  Display "Enter two numbers"
  Read num1, num2
  Display menu: 1.Add 2.Subtract 3.Multiply 4.Divide
  Read choice
  If choice = 1 → result = num1 + num2
  If choice = 2 → result = num1 - num2
  If choice = 3 → result = num1 * num2
  If choice = 4 
       If num2 != 0 → result = num1 / num2
       Else → Print "Error: Division by zero"
  Display result
End

4. Testing Plan

| **Test Case ID** | **Description**               | **Input** | **Expected Output** | **Status** |
| ---------------- | ----------------------------- | --------- | ------------------- | ---------- |
| TC-01            | Addition                      | 5, 3, +   | 8                   | Pass       |
| TC-02            | Subtraction                   | 9, 4, -   | 5                   | Pass       |
| TC-03            | Multiplication                | 6, 7, ×   | 42                  | Pass       |
| TC-04            | Division                      | 8, 2, ÷   | 4                   | Pass       |
| TC-05            | Division by Zero              | 5, 0, ÷   | Error message shown | Pass       |
| TC-06            | Invalid Input (e.g., letters) | A, 3, +   | Error message shown | Pass       |

✅ Final Notes (for exam writing):

Keep answer short and structured.

Draw a simple calculator sketch.

Show pseudocode clearly.

Include at least 4–5 test cases.