Akınsoft and Akın Robotics — Control Software Lead / Lead Computer Engineer

From 2016 to 2019, I worked at Akınsoft and Akın Robotics as Control Software Lead / Lead Computer Engineer. This was the first long professional period in which my software-engineering and mechatronics backgrounds continuously met inside the same product.

In a humanoid robotic system, correct output on a screen is not enough. Software state can become physical motion, spoken interaction, sensor interpretation or communication traffic. I therefore treated robotic software not as a collection of independent desktop applications, but as a system in which perception, decision, control, communication and human interaction share the same timeline.

This public account uses known product and software names together with the general engineering scope. Internal protocol formats, hardware addressing, private message structures and distinguishing implementation details are intentionally excluded.

AROS / AR-CONTROL: Robot Control Software

A major part of my work centered on AROS / AR-CONTROL. The control layer did more than forward commands to devices. State from multiple robotic subsystems had to be observed, commands had to execute in a valid sequence, and requests from the user or higher-level behavior logic had to be reconciled with the current physical state of the robot.

Failure has a different meaning in this environment than in an ordinary desktop application. An invalid transition can become physical behavior. A delayed command can disrupt a motion sequence. A brief communication failure is not only a connection error in the UI; it can affect the control chain.

State management, recovery, continuity of communication and the physical consequences of commands therefore had to be considered together.

I developed across C, C++, C#, Java and Python on Windows, Linux and embedded environments. Language choice followed the requirements of the layer. Hardware-near and timing-sensitive work did not have the same constraints as operator-facing software.

AR-CORE: Autonomy and Higher-Level Behavior

There is a separate problem between driving individual devices and producing meaningful autonomous behavior. While working on AR-CORE, I saw directly that autonomy is not simply an "AI function." State, timing, sensor information and control output have to be coordinated.

Starting an action is only one part of behavior management. The system must also define when it ends, which event can interrupt it, how a failed sub-step propagates upward and how competing requests are prioritized.

This became the basis of my work on behavior modeling. Rather than expressing every robot scenario only as hard-coded procedural logic, I worked on higher-level representations that could be adapted to different behaviors.

A command being technically complete did not always mean the behavior was semantically complete. A motion might have ended while the behavior still needed sensor confirmation before proceeding. Physical systems made state-machine and event-driven design constraints concrete.

Tree- and Circuit-Based Visual Programming

Encoding every behavior directly in source code required every scenario author to understand the same programming details. I worked on visual-programming approaches inspired by tree and circuit structures to move part of that definition to a higher level.

The problem was not merely drawing connected blocks. A visually defined structure still had to execute deterministically, invalid connections had to be prevented, parameters had to remain type-consistent and the resulting behavior had to cross safely into the robot-control layer.

This work introduced a design problem that later appeared in enterprise systems as well: when a platform gives users more freedom, it must reduce the invalid state space through stronger validation and clearer contracts.

Visual programming also strengthened the idea of separating domain behavior from the runtime engine. Scenario definitions could change while the execution rules and safety constraints remained owned by the underlying system.

AR-GUI and Operator Interfaces

I worked on AR-GUI and related graphical interfaces used to observe and control the robot. A robot-control interface differs from a conventional data-entry screen because the user expects the value shown on screen to correspond to the actual physical state.

Telemetry, status, errors and control commands therefore had to be designed together. Showing stale state, or presenting a command as applied when it had not reached the target, was not acceptable.

I did not treat the GUI as a presentation layer isolated from the rest of the system. Communication, state synchronization and physical behavior were part of interface engineering.

Readability was also a reliability issue rather than only a visual concern. Operators had to distinguish critical errors from informational events and understand active control state without ambiguity.

ADA H4: Interface and Simulation Work

For ADA H4 I worked on graphical-interface and simulation software. Simulation was useful for more than demonstration. It provided a way to evaluate control and interface behavior before every scenario had to be exercised on physical hardware.

The important gap between simulation and the robot is timing. A state transition that appears instantaneous in software may involve motor motion, communication delay and sensor feedback on the physical platform. Making that difference visible during development reduced surprises when the same behavior moved to the real system.

Simulation also made uncommon failure conditions easier to reproduce. Scenarios that were expensive or inconvenient to repeat on physical hardware could be exercised in software while interface and recovery behavior were developed.

Speech Recognition and Speech Synthesis

Voice interaction was an important part of the robot's user interface. I worked with HMM-based speech recognition, speech synthesis and the connection between recognized commands and robot behavior.

The speech-recognition work of that period was based on HMM-style recognition, feature processing, decision logic and integration with robot behavior; transformer models used in later years were not part of that work.

For a robot, transcription accuracy alone is not enough. Accepting a command at the wrong time, interpreting noise as a command or failing to apply contextual constraints can create physical behavior. Speech recognition therefore had to be treated as one of the control system's inputs, not simply as a text-producing utility.

The same was true for TTS. Generating audio was only one step; timing, robot state and the interaction sequence also mattered.

These projects became part of the technical foundation for my later speech-processing work, but I keep the historical technology in its original context rather than projecting current models backward.

Image Processing and Perception

My computer-vision work involved processing camera data, extracting useful scene or target information and making that result available to higher-level behavior.

A vision algorithm with good standalone accuracy is not necessarily useful if acquisition, preprocessing and inference make the result too old by the time the robot acts on it. Capture, processing latency, freshness of the result and behavior timing had to be evaluated together.

That led me to view vision and robot control as a shared pipeline with a common latency and state budget rather than two unrelated products.

A delayed result can be numerically correct and still represent an obsolete physical situation. This became an early practical form of the data-freshness concerns I later used in real-time AI systems.

Communication and Telemetry

Communication and telemetry were continuous infrastructure concerns across the robot. Delivering a control command was only half of the problem; the real state of the robot also had to return through the system.

I treated telemetry as more than a debugging window. It was one of the main ways to understand what state the system believed it was in, when a command was applied and where behavior diverged from expectation.

Different subsystems did not produce data at the same rate and did not fail in the same way. A slow component should not unnecessarily stall the whole control path, stale data should not be interpreted as current state, and communication loss had to be handled safely from the perspective of the physical system.

Concurrency and Performance

Robotic systems are inherently concurrent. Sensor data arrives while user commands are processed; speech recognition can impose a separate compute load; telemetry continues while the control layer manages physical motion.

Using threads is not a solution by itself. The system still has to decide which work runs at what rate, how shared state is protected, how the UI thread is separated from background processing and how a heavy perception operation is prevented from delaying control response.

This period changed the way I thought about performance. Latency is meaningful only in context. One hundred milliseconds in a visual status panel and one hundred milliseconds in a control path do not have the same system impact.

Lower CPU consumption is not automatically better either. If it is achieved by adding latency or using stale sensor data, physical behavior can deteriorate. The meaningful metric is the end-to-end behavior of the robotic task.

Programming Standards and Maintainability

Long-lived robotic software required more than a working first implementation. I worked with programming standards, object-oriented design, shared data models and module boundaries.

If control, autonomy, GUI, speech and vision layers become tightly coupled, the cost of every change rises quickly. Separating responsibilities, avoiding duplicated behavior and keeping internal details inside the owning module were practical engineering requirements.

Hardware revisions also tested software boundaries. If device-specific assumptions leaked into upper layers, a small electronic change could require broad software changes. Clear interface and device-adapter boundaries directly affected maintenance cost.

Responsibility for the Control-Software Domain

Over time, my role expanded from implementing individual components to following the broader technical integrity of the control-software domain. A change had to work not only inside its own module but also with the rest of the robot.

That responsibility involved code review, failure analysis, integration between modules and observing the physical outcome of software changes. A problem seen on the robot could originate in control logic, communication, perception or the physical platform itself. Identifying the correct layer became as important as writing the fix.

As technical responsibility increases, "my code works" stops being a useful boundary. Product behavior is the combined result of multiple modules, and system-level problems do not stop at ownership lines.

Professional Impact of This Period

The most instructive part of my years at Akınsoft and Akın Robotics was being able to follow one user command all the way from a microphone or interface through behavior modeling, control, communication and finally physical motion.

Several habits became established there: measure real-time behavior end to end, separate perception from decision logic, do not diagnose a physical-system failure from a software symptom alone, and keep the operator interface synchronized with actual system state. Those habits remained visible in my later work on speech processing, AI and high-volume backend systems.

Akınsoft and Akın Robotics

Related Technical Notes

The systems background behind this robotics work is connected to my notes on Mechatronic Systems, Microprocessors and Microcontrollers, MFCC Speech Feature Extraction and the later Whisper Architecture.

Continuity with Later Speech Systems

The HMM-based ASR/TTS and robot-behavior work from this period became one historical root of my later speech systems. Capacity Engineering for Real-Time Speech Recognition and Developing a VAD Library show the later production-oriented stage around queueing, segmentation and resource budgets.