Centaurus
A personal AI assistant and robot, developed for voice with software prototypes and Nvidia hardware.
I’m Akash, a Mechatronics Engineering student at Unimelb. I bring software, electronics and physical systems together to build intelligent products.
Physical prototypes. Software products.
The work, the constraints and the solution.
A personal AI assistant and robot, developed for voice with software prototypes and Nvidia hardware.
A machine learning prototype that turns weather, soil and humidity data into irrigation recommendations, with text and voice output.
A student connection platform for exploring activities, groups and the first step toward meeting people.
An AI application with Solo, Compare and Council/Upshot workflows, built around model interactions and the systems that support them.
A speech-to-English software experiment connecting Nemotron 3.5 ASR, NLLB-200 translation and macOS speech output.
Four iterations of a handheld behavioural support concept using cooling, vibration and light. Paused when the design fell short.
A local face recognition demo connecting enrollment, multi-face scanning and check-in records through OpenCV, FastAPI and SQLite.
A three-person mechatronics build: six compartments, scheduled alerts and load-cell estimates. I own the display and control system.
An ESP32 audio experiment evolving from microSD recording toward buffered streaming and host side WAV handling.
Python-based research into stock-price behaviour during the first 30–60 minutes after market opening.
A Python object detection tool for Apple Silicon Macs, with image, video and webcam workflows, CPU/MPS benchmarking and graceful fallbacks.
A voice. A response. Closer to the edge.
A personal AI assistant and robot, developed for voice with software prototypes and Nvidia hardware.
Build the subsystems. Understand their limits. Then bring them together.
From field data to a clearer decision.
A machine learning prototype that turns weather, soil and humidity data into irrigation recommendations, with text and voice output.
A model’s output becomes more useful when someone can understand it.
Making room for real connection.
A student connection platform for exploring activities, groups and the first step toward meeting people.
Finding your people starts with knowing where to join in.
One question. More perspectives.
An AI application with Solo, Compare and Council/Upshot workflows, built around model interactions and the systems that support them.
The wait before a model responds can begin long before the model is called.
From speech to English. On a Mac.
A speech-to-English software experiment connecting Nemotron 3.5 ASR, NLLB-200 translation and macOS speech output.
Rethinking the habit. Through hardware.
Four iterations of a handheld behavioural support concept using cooling, vibration and light. Paused when the design fell short.
A prototype can teach you when to stop and what a redesign must solve.
From a face in the frame to a local check-in.
A local face recognition demo connecting enrollment, multi-face scanning and check-in records through OpenCV, FastAPI and SQLite.
Recognition is one step. Enrollment, unknown faces and repeat scans need a clear workflow too.
A little more clarity. Every day.
A three-person mechatronics build: six compartments, scheduled alerts and load-cell estimates. I own the display and control system.
A change in mass can suggest removal. It cannot tell you a dose was taken.
From sound to a saved signal.
An ESP32 audio experiment evolving from microSD recording toward buffered streaming and host side WAV handling.
Move the audio early. Keep the embedded device focused on acquisition.
A market hypothesis. A data workflow.
Python-based research into stock-price behaviour during the first 30–60 minutes after market opening.
Treat a strategy as a question to test, not a result to promise.
Local vision. Measured on the machine that runs it.
A Python object detection tool for Apple Silicon Macs, with image, video and webcam workflows, CPU/MPS benchmarking and graceful fallbacks.
Measure the device choice, and make the fallback part of the design.
My first workbench was my father’s hardware shop in Sri Lanka. Tinkering, soldering and repairing things gave me a practical way into engineering: take something apart, understand it, then see what you can make it do.
I moved to Melbourne to study Mechatronics Engineering at the University of Melbourne. From the beginning, I’ve been interested in connecting software with sensors, electronics, actuators and the physical world.
I use AI throughout research, coding, debugging and documentation. The work still comes back to testing: does the signal make sense, does the part fit, does the interaction actually work?
I’ve worked to help fund components and experiments. Building within a personal budget has made me resourceful and more willing to change direction when the evidence calls for it.
Bachelor of Science · Mechatronics Engineering Systems
University of Melbourne · 2024–present
Calibration Laboratory Technician
Calibration, verification and testing of measurement instruments. I investigate out-of-tolerance results and instrument faults, carry out repairs within my assigned responsibilities, and maintain calibration records, certificates and measurement traceability.
After a senior technician left, I took on greater responsibility, learning quickly while becoming more dependable in a practical technical environment.
Melbourne Space Program
Local computer vision on NVIDIA Jetson Xavier NX for humanoid robotic arm movement and water glass pickup. Vision to action integration across perception, arm control and embedded hardware/software systems.
Aerospace and Rocket Engineering Society
Data preprocessing, feature engineering and lightweight machine learning approaches for flight telemetry on constrained hardware.
Melbourne University Racing
Temperature sensor selection and calibration, sensor interfacing and electronics validation for an electric Formula SAE vehicle.
Sensor integration, embedded audio, analog measurements and firmware logic. Grounded in projects where software has to work with a physical input.
ESP32 · C/C++ · Linux · sensors & actuators
See the pill-box firmware work →Interfaces, API integration and the supporting request, account and payment flows. AI-assisted development is part of my research, coding and debugging process.
React · TypeScript · Node.js · SQL · Supabase
Explore Model Council →Calibration and traceability in the lab, data preprocessing and model experiments in projects. Both start with understanding the input before trusting the output.
Python · pandas · NumPy · scikit-learn · MATLAB
Explore Farmer’s Intuition →Organising, listening and bringing people together have been part of my work too.
Zonal Head
Across four years of involvement in Interact, I worked with student leaders on community activities and club coordination. As Zonal Head, I supported the administration and coordination of more than 30 clubs across three districts, helping club leaders communicate and keep shared initiatives moving. The experience shaped how I work with people: listening to different perspectives, coordinating across teams and following through on responsibilities.
Melbourne Peer Mentor Program - Unimelb
Over two years in the University of Melbourne’s Peer Mentor Program, I supported first-year students as they settled into university life, stepping into a Senior Peer Mentor role in my second year. It reflects something I enjoy beyond building: helping people find their footing, make connections and grow in confidence.
Events Director
Professional events, workshops and networking, with responsibility for logistics and stakeholder communication.
B2B Associate Intern
I supported university-club outreach and launch preparation, contributed to campaigns across three social platforms, and collaborated with growth, product and operations teams.
Away from the bench, I enjoy chess, poker, long-distance athletics and making videos. Chess has been a lesson in persistence: improving through competition eventually led me to become captain.
WHAT’S NEXTMy next step is practical engineering work across robotics, electronics and software. Longer term, I’m interested in robotics research, building useful products and sharing what I learn.
Robotics, an early idea, or something
that doesn’t fit neatly in a box.
Let’s build something worth making.
A personal AI assistant and robot, developed for voice with software prototypes and Nvidia hardware.
Ongoing development
Node.js · Jetson Orin Nano 8 GB · Linux · IMX219 · Model APIs
“Build the subsystems. Understand their limits. Then bring them together.”
Voice Input
Cloud transcription/Local Openclaw Harness
AV output
1 of 3
Video walkthrough to be added.
I want to build a small robot that can eventually listen, respond, see and move. Centaurus is my way of learning what has to work between a human input and an intelligent physical response.
I work across the assistant interface and hardware integration: browser audio input, the local Node.js server, transcript and reply display, typed messages, Linux setup and Jetson peripherals.
I developed two strands separately. The interaction prototype uses cloud AI services for speech-to-text and model responses. Alongside it, I experiment with local language models on my Jetson and Mac, investigating memory limits, latency and model suitability.
The software prototype accepts browser microphone input and typed messages, with transcripts and replies displayed in the interface. The hardware work uses a Jetson Orin Nano Developer Kit with 8 GB memory, approximately 500 GB NVMe storage, an IMX219 camera and a MAX9814 microphone module. Audio-input experiments run alongside the camera integration.
The camera was initially unavailable. I worked through connection and configuration problems until it appeared as a detected video device. That exposed the next layer of issues: colour cast, noise and exposure behaviour. Device detection was progress, not the end of image quality work.
A voice-and-text interaction prototype and separate hardware integration. The camera reached device detection; image quality remains under investigation. A completed mobile robot and a fully offline voice pipeline have not yet been established.
Continue local speech-recognition and inference experiments, investigate camera quality, and bring physical inputs closer to the assistant. Movement and a fully integrated robot remain future capabilities.
Four iterations of a handheld behavioural support concept using cooling, vibration and light. Paused when the design fell short.
April–October 2025
Embedded electronics · Peltier cooling · Haptic feedback · Battery-powered design
“A prototype can teach you when to stop and what a redesign must solve.”
NOK began with my dislike of smoking and a desire to help smokers move away from the habit. I explored whether a non-chemical handheld interaction, using cooling, vibration and light, could offer an alternative sensory experience to the physical habit associated with smoking and vaping.
I developed the concept, carried out initial user research and worked through four hardware iterations during 2025. My focus was connecting the intended experience with electronics that could fit into a useful handheld form.
I explored Peltier cooling, a vibration motor, LEDs, lithium-battery power and microcontroller control. Each iteration was a chance to revisit the relationship between the feedback, its power needs and the available space.
Four hardware iterations were developed between April and October 2025. Component exploration included a 3.7 V LiPo battery and ESP 32 WROOM-S3E microcontroller.
The hardware did not meet the technical specifications and form-factor requirements I had set. Rather than carrying an insufficient design forward, I paused development. The gap between the intended experience and the physical implementation is the central lesson of this project.
A paused prototype project with four iterations behind it. NOK is a behavioural support concept, not a validated smoking-cessation product. Manufacturing, sales and a filed patent are not established outcomes.
Before restarting, identify the components and test results for each iteration, revisit the specifications and establish whether the feedback can fit within the intended handheld form.
An AI application with Solo, Compare and Council/Upshot workflows, built around model interactions and the systems that support them.
Development project
React · TypeScript · Supabase · Stripe · Model APIs
“The wait before a model responds can begin long before the model is called.”
I wanted a way to use an individual AI model, compare different responses and bring multiple perspectives into a review and synthesis workflow. Model Council brings those modes into one application.
My work spans the interface and conversation flows, model provider integrations, authentication and onboarding, credits and usage accounting, billing safeguards and request lifecycle management.
The application is organised around Solo, Compare and Council/Upshot. I treat the supporting systems account state, usage, payments, cancellation and recovery as part of the user experience, because they determine whether a conversation feels dependable.
The recorded stack includes React, TypeScript, Supabase, Stripe and model APIs, with OpenRouter used in development discussions. Development has covered responsive layouts, onboarding, provider integration and accounting alongside the model workflows.
A slowdown appeared around billing. I investigated database operations and accounting work occurring before model dispatch, rather than assuming the model was responsible. It turned the investigation toward the full request path, including work a user never sees.
Ready to release with a few fixes.
Verify the integrated request and payment flows and clearly document what is available in a release. Image, audio and video support remain possible future extensions.
Private repository · GitHub access required.
A student connection platform for exploring activities, groups and the first step toward meeting people.
Social networking platform
React · TypeScript · Tailwind CSS · Vite · React Router · Context API
“Finding your people starts with knowing where to join in.”
Moving into student life can mean being surrounded by people without knowing how to meet them. Joynex began as a way for students to discover activities, create or join groups and find a reason to connect.
My software work uses React and TypeScript to explore the product experience. This is a shared venture; a detailed division of features is not yet documented.
Start with the path from finding an activity to being part of a group. Product work has explored search, group creation, dates and times, capacity, joining and leaving, member lists and a “My Groups” view.
The recorded frontend stack is React, TypeScript, Tailwind CSS, Vite, React Router and Context API. Early prototypes used localStorage and mocked data. Owner editing, university-email verification and management of joined groups have also been developed.
The product question is how to turn interest into participation. Group ownership, capacity and membership state all need to stay understandable. Later exploration of local-business offers and group redemption widened that question beyond the first meetup.
A student platform, that reached 26 weekly active users at its peak.
Distinguish implemented features from experiments and document before presenting a release.
Private repository · GitHub access required.
An ESP32 audio experiment evolving from microSD recording toward buffered streaming and host side WAV handling.
Embedded audio experiments
ESP32 · MAX9814 · Python · WAV · RAM buffering
“Move the audio early. Keep the embedded device focused on acquisition.”
Microphone input
ESP32 buffers
Host WAV workflow
1 of 3
I get a lot of thoughts and ideas throughout the day, and if I don’t capture them immediately, I tend to forget them. I wanted to build compact hardware that lets me record those thoughts through speech and pass them to a laptop or Jetson for processing. The engineering focus is the path between audio acquisition, buffering, transport and a usable recording.
I am exploring the embedded sampling path and host side audio workflow: MAX9814 analogue microphone input, ESP32 sampling, storage choices, small RAM buffers and a Python receiver/WAV workflow.
The design started with local microSD WAV recording, then moved toward continuous sampling and immediate transmission to the host. That shifts more of the handling away from the embedded device and reduces its reliance on local storage.
The explored hardware route pairs a MAX9814 analogue microphone with an ESP32. Host-side work includes a Python receiver and WAV handling. I also purchased a USB-C lapel microphone to explore another input route; it is separate from the ESP32 acquisition path.
Reliable streaming requires acquisition, buffer use and host handling to stay coordinated. The move away from local storage changes where interruptions and data loss must be investigated. End-to-end streaming reliability still needs a demonstration.
An embedded-audio development project with an evolving acquisition and transport approach. Reliable continuous streaming is not yet established by a published demonstration.
Demonstrate and document a complete recording path, including the transport and recording settings. Transcription, summaries and follow-up tasks are later possibilities, not current claimed capabilities.
A three-person mechatronics build: six compartments, scheduled alerts and load-cell estimates. I own the display and control system.
University mechatronics project
ESP32 · 1 kg load cell · HX711 · NAU7802 · Display · Servo control · Firmware
“A change in mass can suggest removal. It cannot tell you a dose was taken.”
My father’s regular medication routine made this a problem I could relate to. Our three-person team is developing a six-compartment pill box to support scheduling, reminders and a clearer view of remaining stock.
I am responsible for display programming, firmware and management logic, converting load-cell measurements into useful estimates, scheduling, alarms, compartment opening logic and pill count updates. My teammates are responsible for the electrical circuits and hardware.
Combine scheduled reminders with a display, audible and visual alerts, compartment actuation and mass change estimates. The intended logic includes stock tracking and flags for missed doses or unexpected removal. These functions are development work, not established reliability claims.
The current design uses one 1 kg load cell with an amplifier/ADC, an ESP32/microcontroller based approach, a display, buttons, alerts and servo related compartment control.
A load cell provides a measurement that must be interpreted. Converting a mass change into a useful estimate requires care about calibration and the limits of the signal. Removal is not ingestion, so the system must not treat one as proof of the other.
A team system in development, with responsibilities divided between my firmware/display work and my teammates’ electrical and hardware work. The reminder, actuation and estimation functions still require integration and validation.
Integrate the firmware with the team’s hardware, test the scheduling and compartment logic, and document how mass changes become quantity estimates and where those estimates can fail.
A machine learning prototype that turns weather, soil and humidity data into irrigation recommendations, with text and voice output.
Machine learning prototype
Python · Machine learning · Gemini · ElevenLabs
“A model’s output becomes more useful when someone can understand it.”
I explored how agricultural data could support irrigation decisions, with a recommendation a user could read or hear rather than a model output on its own.
My work covered data processing and model development, alongside Gemini and ElevenLabs integrations for text and voice output.
Build a workflow from weather, soil and humidity inputs through a model to an understandable irrigation recommendation. The interface to the result is part of the prototype, not an afterthought.
The development dataset contains 780 records. The prototype connects the data-processing and model workflow to text and voice output through Gemini and ElevenLabs.
A recommendation developed on a limited dataset must be kept separate from evidence that it works in a real field. The next validation question is how the workflow behaves beyond its development data.
A machine learning prototype that demonstrates the path from agricultural data to a user-facing recommendation. Field deployment, water savings and performance beyond the development data have not been established.
Evaluate the workflow beyond the development data and document its limitations before considering field use.
Python-based research into stock-price behaviour during the first 30–60 minutes after market opening.
June–November 2025
Python · Yahoo Finance · Data analysis
“Treat a strategy as a question to test, not a result to promise.”
I wanted to investigate stock-price behaviour in the first 30–60 minutes after market opening and explore whether patterns could support a testable strategy idea.
I worked on data collection and analysis in Python, using Yahoo Finance data for exploratory strategy testing.
Frame the opening window as a research question, collect relevant market data and use analysis to explore the idea. The portfolio value is the research process and data workflow.
The project ran from June to November 2025 and used Python and Yahoo Finance data for collection, analysis and exploratory testing.
Exploratory patterns need to be distinguished from repeatable results. A strategy idea cannot be evaluated responsibly from an appealing example alone; the limits of the data and test method matter.
A trading strategy that worked best in the first 5-10 minutes through rapid, large quantity trades with minimal transaction costs. Ultimately discontinued due to low market volume. No verified profitability results.
Document the dataset, assumptions and evaluation method before making stronger claims about the strategy.
A speech-to-English software experiment connecting Nemotron 3.5 ASR, NLLB-200 translation and macOS speech output.
Speech and translation experiment
Nemotron 3.5 ASR · NLLB-200 · macOS
Speech recognition
English translation
Spoken output
1 of 3
Explore a local workflow for turning speech in another language into English text and spoken output.
My software experiment brings speech recognition, translation and speech output into a single interaction.
The workflow presented in the film has three stages: Nemotron 3.5 for speech recognition, NLLB-200 for translation and macOS speech output.
The supplied project film shows a software interface with transcription, English translation and an audio-output player. It presents the workflow as running on a Mac.
Speech recognition, translation and spoken output are separate stages. Displaying the transcript and translation makes the intermediate results available for inspection.
The film presents a Spanish-to-English example with a transcript, translation and generated audio. This is a separate software experiment from the Centaurus robot and the embedded voice recorder.
Document the model setup, supported inputs and repeatable test cases alongside the recorded example.
A local face recognition demo connecting enrollment, multi-face scanning and check-in records through OpenCV, FastAPI and SQLite.
Computer vision project
Python · OpenCV · YuNet · SFace · FastAPI · SQLite
“Recognition is one step. Enrollment, unknown faces and repeat scans need a clear workflow too.”
This project explores a local check-in workflow: enroll a person, scan a webcam frame or uploaded image, and turn a recognised match into a record without sending the recognition request to a cloud service.
My project brings the browser interface, recognition API and local database together. The recognition engine integrates pretrained YuNet and SFace models through OpenCV; the model wrappers are adapted from the OpenCV Zoo examples.
Separate enrollment from recognition. YuNet detects faces, SFace aligns them and extracts embeddings, and cosine similarity compares those embeddings with the local registry. Matches below the configured threshold remain unidentified.
The FastAPI application supports enrolling people with one or more face images, scanning every detected face in a frame and listing recent check-ins. SQLite stores embeddings and records rather than raw enrollment images. The check-in endpoint includes a duplicate suppression window, and the interface supports both webcam and uploaded image input.
A frame can contain several people, including faces outside the registry. Enrollment rejects images with multiple faces so an embedding is not assigned to the wrong person. Recognition keeps unknown faces separate, while duplicate suppression prevents repeated scans from creating a check-in on every frame.
Built for a friend who wanted a privacy focused face check-in system. The final system performs enrollment, recognition and check-in locally, keeping biometric processing off the cloud.
Evaluate the complete workflow with consented test images, document false matches and missed matches under different conditions, and review enrollment and retention controls before use beyond a local demonstration.
A Python object detection tool for Apple Silicon Macs, with image, video and webcam workflows, CPU/MPS benchmarking and graceful fallbacks.
Computer vision project
Python · Ultralytics YOLO · PyTorch MPS · OpenCV · Typer · Rich
“Measure the device choice, and make the fallback part of the design.”
Running object detection locally involves more than loading a model. Inputs, device selection, output files and failure handling all affect whether the tool is useful. This project brings those pieces into a command line workflow for an Apple Silicon Mac.
My project integrates pretrained Ultralytics YOLO models with OpenCV input/output and a Typer/Rich command line interface. It includes device checks, prediction settings, benchmark commands and recovery paths rather than training a new detection model.
Use the same detection layer for images, video and webcam frames. Check whether PyTorch MPS is usable, allow an explicit CPU selection, and provide a benchmark command so the device choice can be measured on the target machine.
The tool implements image, video, webcam and benchmark commands, class filters, confidence settings and fast/balanced/accurate presets. It can save annotated images and video. Model loading tries a fallback sequence, and an MPS inference failure triggers a retry on CPU. A separate script provides optional CoreML export.
A supported backend is not automatically the fastest or the most reliable. The benchmark warms up the model and synchronises MPS before timing, while the inference path catches an MPS failure and retries on CPU. Model availability has its own fallback path.
The system successfully performs object detection on both static images and a live webcam feed. CPU versus MPS benchmarking was conducted using a synthetic sample frame, while the webcam demonstration confirms real-time camera inference.
Measure complete camera-to-display latency on representative inputs, document repeatable settings and evaluate detection quality alongside speed. Validate any exported CoreML model separately from the Python runtime.