Hi, meetManjunath.

During my Master thesis at Aurea Imaging and the University of Twente, I worked on extending the TreeScout platform for apple size estimation and geo-localization. TreeScout is a tractor-mounted system with stereo cameras, IMU and RTK-GNSS, used to collect orchard data for tree-specific precision farming. My goal was to use this existing system in a new way: to estimate the size of apples and connect each apple to the correct tree. I found this very interesting because it was not only a computer vision problem. It was a complete system problem.

I had to plan the work around the apple season, where the timing of data collection was important. I designed the field trials at Randwijk, selected trees with different fruit density and vigor, and collected ground-truth measurements along with sensor data. After the first trial, I saw that some tagged apples were not visible or could not be detected, and so I changed the approach to tree-level data collection.

I then worked on developing a pipeline to detect, segment, track, size and localize apples in the orchard. I worked on the different parts in parallel to identify missing data early and complete data collection on time. After that, I conducted multiple trials using different methods along the pipeline. This project helped me learn how to translate field constraints into system choices and build a practical baseline for precision farming.

During my undergraduate research, I worked in a team for a project that started out as simply building a robotic arm. While working on it, I discovered that the same idea could be made modular, so that the same parts could be reused to create different articulated industrial robot architectures instead of one fixed arm. I found this very interesting because it made the project more useful and also economical.

After this discovery, I worked on designing modular units using off-the-shelf materials. I created physical prototypes and iterated the design to improve the positioning accuracy of the arm. My work involved integrating the mechanical design, hardware and software together. This included the modular links, adapters, servo motors, motor controller and the software interface.

I also worked on creating a Windows application that connected the physical arm with RoboAnalyzer, a 3D model-based software used to teach and learn robotics concepts. The system was patented and is now being moved towards commercialization, with the aim of being sold to universities as a robotics learning platform.

At CuriousU I met a lot of people from different countries and backgrounds. The course was very practical. We were free to write our own problem statement and design the solution as a story, built from the moments where a person meets the robot and what it does in response. As a team of five we voted, and chose to work on a fire-safety robot.

I worked on the physical prototype and on the harder question behind it, which was how the robot should behave around people in no state to read instructions. What it shows, how it moves, and how it makes its intent obvious in the couple of seconds someone will actually give it.

It was my first proper encounter with human-robot interaction, and with the idea that a robot which is technically correct but unreadable to a panicking person has simply failed. That perspective has stuck with me on everything I have built since.

Anyone who has queried an unfamiliar database knows the problem: you know the question, you just do not know the joins. Large language models can close that gap, and I wanted to know how much of their accuracy comes down to how you phrase the request.

I benchmarked two models, LLaMA-3-SQLCoder-8B and LLaMA-2-7B-chat-hf, on Yale's Spider 1.0 benchmark, putting the same questions to each three ways: as a bare question, as an instruction-led prompt, and as a structured template. Marking it was its own problem, since two queries that look nothing alike can both be right, so I scored exact matches against the reference query and also checked whether actually running the query returned the same rows. I tracked response time alongside accuracy, because a model that is right but slow is no use to someone waiting on a dashboard.

Phrasing helped, but it did not rescue the weaker model. Moving from a bare question to a structured template lifted SQLCoder from 63.3% to 66.9% of queries correct, and chat-hf from 51.3% to 55.5%. That is about three and a half points from prompt design alone on both models, while the twelve-point gap between the two models never closed. Prompt engineering is worth doing, and it is not a substitute for picking the right model.

SAE BAJA gives student teams a rulebook and a year, and asks them to design, build and race an off-road buggy. I joined the team of 25 students at my university.

I started by learning the basics of how a vehicle is put together, and then chose the vehicle dynamics team, because suspension was what interested me. I was eager to learn how to design the geometry and calibrate the system for an ATV. Most of it was self taught, with guidance from my seniors and professors. I learned SolidWorks, and ran the analysis in Lotus Shark to iterate on the design, making assumptions where I had to and working in parallel with the other departments, since every one of them depended on the others.

The bigger thing I took away was not suspension. It was building a whole vehicle alongside 25 other people: agreeing where my subsystem ended and someone else's began, hitting deadlines other people were waiting on, and the decision making itself, where compromises had to be weighed against competing reasons and then stood behind once made. It is the closest thing to real engineering delivery I had done at that point.

Deep learning solves lane detection well, which is exactly why I wanted to try it without any. I took footage shot from a car on a Dutch motorway and rebuilt lane detection using only classical image processing.

Finding edges turned out to be the easy part. Canny returns the lane markings, and also every vehicle, building, pole, signboard, median and road border in the frame. Worse, many of those are near-vertical lines running parallel to the road, which is precisely what a lane looks like to an algorithm. The project became an exercise in throwing information away without losing the two lines I actually wanted.

I worked it into a pipeline where each stage removes a class of false positive: blur away texture, close broken markings with dilation and restore their scale with erosion, cut the frame down to a trapezoid covering only the road ahead, then pull line segments out with the Hough transform and filter them by angle before extending them into lane markers.

The pipeline:

1. Convert frames to greyscale to work on intensity rather than colour.
2. Apply a Gaussian filter to reduce noise.
3. Run Canny edge detection.
4. Dilate to fill gaps and merge nearby edges.
5. Erode to bring the dilated image back to size.
6. Detect shapes to find polygons in the image.
7. Apply a trapezoidal mask to focus on the region of interest.
8. Re-run Canny inside the masked region.
9. Apply the Hough transform to find line segments.
10. Filter vertical lines by threshold and extend the rest into lane markers.

A good reminder that much of computer vision is deciding what to ignore.

I joined the project management team at Larsen & Toubro on an underground stretch of the Chennai Metro, where a tunnel boring machine chews out the alignment a few metres at a time and everything else on site exists to keep it moving.

My work was coordination. Sequencing the day, allocating the workforce, and keeping logistics a step ahead of the machine. A TBM does not wait: if segments, grout or crew are not staged by the time it needs them, the drive stops, and that time never comes back. So the planning was less about drawing a schedule and more about reconciling the schedule with what the ground actually gave us that morning.

I ended up as the site coordinator, and in practice the face of the company on the ground: the point where the crews underground, the planning office and anyone visiting the site all met. It taught me how to hold a plan and a reality in mind at once, and how much of delivery is simply being the person who answers.

Janatics makes pneumatics at scale: over 3,000 basic models and 32,500 variants, shipped to 42 countries from a plant in Coimbatore. I spent three weeks there watching how a company that size actually turns an order into a product.

I rotated through application design, R&D, pilot batch and production, following the chain end to end. A customer requirement becomes a drawing, the drawing becomes a validated assembly, and the assembly only ships once it has been tested. Seeing the handover points between those departments was the useful part: that is where time is won or lost.

I was fascinated by the products and demos they had built at the facility: a PLC programmed piano, a bus door system where I got to experiment with the sensors used for safety, and the didactic kits, on which I also ran a few quality tests.

I finished with two suggestions for cutting production time: batch-picking common components against order history rather than packing each unit individually, and fitting self-sealing valves or a status light so tubes could be disconnected without splash-back. Both came out of watching the same small delays repeat.