Robotics Engineering

At the beginning of 2017, my work at AKINSOFT and AKINROBOTICS brought robot control, autonomy, behavior modeling, speech technologies, computer vision, and telemetry into the same product-development environment. Across my 2016-2019 work, the robot's mechanical and electronic reality and the software's state, timing, and failure behavior had to be treated as one system rather than separate layers.

Robotics was already a production engineering subject for me during this period rather than only an academic topic. I had completed my B.Sc. in Computer Engineering at Kırıkkale University. While working at AKINSOFT I graduated from the Mechatronics program at Sakarya University and began the B.Sc. in Mechatronics Engineering at Afyon Kocatepe University. Algorithms, operating systems, networking, data structures, and software engineering therefore began to meet motors, sensors, mechanics, control, electronics, and physical-system behavior in the same professional problems.

My 2015 internship at Baykar was another important step in that transition. TMS570/lwIP embedded networking, avionics hardware-software debugging, telemetry, and MISRA C/static-analysis work directly prepared me for the real-time, observability, physical-feedback, and reliability problems I later encountered in robotics. I discuss the aviation side of that continuity separately in Avionics Systems and Unmanned Aerial Vehicles.

I approach robotics engineering not as one class of machines, but as a systems-engineering discipline in which perception, computation, decision, control, and physical action share the same timeline. Correct source code is not sufficient if a sensor measures incorrectly, a timestamp is stale, an actuator saturates, or an operator interface presents a state that no longer matches the physical robot.

Unit 1: Systems perspective of robotics engineering

The boundary between robots and automation

Not every automated machine is a robot, and not every robot is fully autonomous. Robotic systems generally interact with the physical environment through sensing and action, produce programmable behavior, and can vary that behavior according to at least some changes in state or environment.

Autonomy is not one binary attribute. The same robot may execute:

• some actions directly under operator command,
• some functions semi-autonomously,
• some tasks automatically.

The more useful engineering question is therefore not “is this robot autonomous?” but which decision is made at which layer, under which constraints, and with which fallback behavior?

Sense-decide-act loop

A robot can be described by the general loop:

environment -> sensors -> state estimation -> decision / planning -> control -> actuators -> environment

Each arrow is an engineering boundary. Converting a physical signal to a digital sensor value, timestamping it, filtering it, and delivering it to a higher layer are different problems. Likewise, a high-level request such as “extend the arm” cannot be translated directly into motor voltage, current, or PWM; kinematics, trajectory generation, and control lie between those levels.

Why robotics is multidisciplinary

Robotics may depend simultaneously on:

• mechanical design and strength,
• electrical and electronic systems,
• sensing and measurement,
• motors, drives, hydraulics, and pneumatics,
• control theory,
• signal processing,
• embedded systems,
• real-time software,
• computer vision,
• speech processing,
• artificial intelligence,
• networking and communications,
• human-machine interaction.

This is the direct connection between robotics and mechatronics. Mechatronics teaches concurrent design of the physical and computational subsystems; robotics extends that integration into perception, behavior, and purposeful motion.

Unit 2: Robot architecture and fundamental subsystems

Mechanical body and kinematic structure

The physical body carries loads, constrains joints, and defines the workspace. In manipulators, links and joints form a kinematic chain. In mobile robots, chassis geometry, wheels/tracks/legs, and mass distribution determine mobility.

Software cannot treat geometry as an implementation detail owned only by mechanical engineering. Joint limits, backlash, friction, transmission ratio, and inertia directly change control behavior.

Joints and degrees of freedom

Two fundamental joint types are:

• revolute joints,
• prismatic joints.

A revolute joint produces angular motion, while a prismatic joint produces linear displacement.

The degree of freedom of a robotic mechanism describes the number of independent motion variables. A free rigid body in three-dimensional space has six degrees of freedom:

• x, y, z translations,
• roll, pitch, yaw rotations.

The number of robot joints and the effective degrees of freedom in task space do not always have the same meaning. Constraints, closed kinematic chains, and singular configurations change the usable motion space.

End effectors

The end effector is the part of a manipulator that performs the task directly on the environment. It may be:

• a two- or three-finger gripper,
• a vacuum gripper,
• an electromagnet,
• a welding tool,
• a paint tool,
• a screwdriver,
• a measurement probe.

Selection is not merely a question of whether the tool can hold an object. Surface, mass, fragility, permitted gripping force, positional tolerance, and cycle time must be considered together.

Robot classes

Common mechanical and application classes include:

• Cartesian robots,
• cylindrical robots,
• spherical/polar robots,
• SCARA mechanisms,
• articulated arms,
• parallel robots,
• wheeled or tracked mobile robots,
• legged robots,
• humanoid robots.

These classifications do not identify one universally superior architecture. Every geometry establishes a different trade-off among workspace, rigidity, speed, payload, control complexity, and cost.

Unit 3: Actuators, drives, and power systems

Electric motors

Robotic motion is frequently generated with electric motors. DC, BLDC, stepper, and servo systems serve different requirements.

Maximum speed alone is not a meaningful selection criterion. Relevant quantities include:

• continuous and peak torque,
• speed range,
• torque-speed curve,
• rotor inertia,
• efficiency,
• supply voltage,
• drive requirements,
• thermal limits,
• feedback resolution.

A motor capable of high no-load speed does not imply that the robot joint can safely operate at that speed. Gearbox behavior, load inertia, mechanical strength, and controller bandwidth impose additional constraints.

Servo systems

A servo is not merely a small model motor. In the general control sense, a servo system tracks a commanded quantity through feedback.

A position servo may form the loop:

target position -> controller -> motor drive -> motor/joint -> position sensor -> feedback

During my AKINSOFT robotics work I repeatedly saw that physical motion is not equivalent to issuing a command. “Command sent” and “joint reached the target” are different states. Higher-level behavior can advance safely only when feedback and timing semantics are reliable.

Transmissions

Motor rotation may be transformed through gearboxes, belts, chains, screws, harmonic drives, or other mechanisms in order to:

• reduce speed,
• increase torque,
• change direction,
• convert rotation to translation.

Higher reduction can reduce motor-side torque demand, but backlash, friction, compliance, and efficiency losses can degrade positioning and control.

Hydraulic and pneumatic actuation

Hydraulics can be appropriate for high-force systems, while pneumatics are common for fast and relatively simple linear tasks. Their control behavior differs from electric actuation: pressure, valve dynamics, compressibility, leakage, and flow characteristics become part of the model.

The fact that electric motors, hydraulics, pneumatics, electronics, and mechanics were studied together in my Sakarya University mechatronics education became much more concrete in robotics: the abstract software command “move” maps to very different physical dynamics depending on the actuator.

Power budget

Energy is a bounded resource, particularly in mobile robots. The power budget includes more than motors:

• processors or GPUs,
• sensors,
• cameras,
• communication units,
• drives,
• audio systems,
• auxiliary electronics.

Motor current transients can pull down supply voltage and destabilize processors or sensors. A seemingly random software reset or communication error can therefore originate from power integrity rather than code.

Unit 4: Sensors, measurement, and robot perception

Internal and external sensing

Sensors can be viewed functionally as two broad groups.

Proprioceptive sensing measures the robot's own state:

• joint position,
• velocity,
• motor current,
• temperature,
• battery state,
• orientation.

Exteroceptive sensing measures the external environment:

• cameras,
• lidar,
• ultrasonic sensors,
• force/torque sensors,
• proximity sensors,
• microphones,
• light sensors.

The distinction is functional rather than absolute. A camera may support both environmental perception and localization/calibration.

Measurement is not reality

Every sensor should be interpreted together with questions such as:

• What is its resolution?
• What is its accuracy?
• Does it have bias?
• What does its noise look like?
• What is the sampling rate?
• What is the latency?
• Where does it saturate?
• When should the value be marked invalid?

Treating a measured number as physical truth without these semantics is one of the most dangerous abstraction errors in robot software.

Encoders

Rotary and linear encoders measure position and support velocity estimation. Incremental encoders report relative motion, while absolute encoders can preserve a coded position reference across power cycles.

Velocity estimated by finite difference may amplify measurement noise:

v[k] ≈ (x[k] - x[k-1]) / Δt

Filtering therefore trades noise reduction against delay. A smoother plot is not necessarily a better control signal if it describes an older physical state.

IMUs and orientation

IMUs combine sensors such as accelerometers and gyroscopes for motion estimation. Gyroscope integration drifts over time; accelerometers observe both linear acceleration and gravity; magnetometers can be distorted by the environment.

Sensor fusion is therefore common. Depending on the problem, state estimation may use complementary filters, Kalman-family filters, or other methods.

Cameras and computer vision

A camera provides a dense signal, but raw pixels are not semantic state. A simplified vision pipeline is:

camera -> frame capture -> preprocessing -> feature/object extraction -> tracking -> decision layer

At AKINSOFT and AKINROBOTICS, vision work made it clear that single-frame algorithmic accuracy was insufficient. A result could be numerically correct yet operationally useless if latency and data age no longer matched the robot's current physical state.

Audio perception

Microphones can provide command input and environmental information. In a robot, an ASR result is not merely text; it can be a control input capable of triggering physical action. Confidence, context, false acceptance, and cancellation behavior therefore matter.

Unit 5: Coordinate frames and kinematics

Position and orientation

Robotics requires both “where?” and “in which orientation?”. The state of an end effector is commonly represented by position and orientation together.

Position can be represented as:

p = [x y z]^T

Orientation may use rotation matrices, Euler angles, or quaternions.

Reference frames

A robot can contain multiple coordinate frames:

• world,
• base,
• body,
• links/joints,
• end effector,
• camera,
• target object.

A target detected in camera coordinates must be transformed into the coordinate system required by the manipulator controller.

A homogeneous transformation combines rotation and translation:

T = [ R  p ]
    [ 0  1 ]

where R is a 3x3 rotation matrix and p is a 3x1 position vector.

Forward kinematics

Forward kinematics computes end-effector pose from joint variables:

q -> x

For a serial manipulator, link transforms are chained:

T_0^n(q) = A_1(q_1) A_2(q_2) ... A_n(q_n)

This calculation underpins visualization, control, collision checking, and many other functions.

Inverse kinematics

Inverse kinematics searches for joint variables that realize a desired end-effector pose:

x -> q

The problem can have:

• one solution,
• multiple solutions,
• infinitely many solutions,
• no solution.

Software should not stop at a mathematical solution. Joint limits, self-collision, cabling constraints, and distance from the current configuration can determine which solution is physically appropriate.

Workspace

The workspace is the set of poses that the robot can reach under its kinematic and mechanical constraints. A coordinate that is valid numerically is not necessarily reachable by the robot.

Unit 6: Jacobians, singularities, and robot dynamics

Differential kinematics

The Jacobian relates joint velocity to end-effector velocity:

x_dot = J(q) q_dot

Because J(q) depends on configuration, it changes as the robot moves. It is central to velocity control, force mapping, numerical inverse kinematics, and singularity analysis.

Singularities

At some configurations the Jacobian loses the rank needed for full local motion. The robot may lose mobility in a task-space direction, or require very large joint velocities to produce a small desired end-effector velocity.

A singularity is therefore not merely a mathematical corner case. It can cause:

• velocity commands to grow,
• torque demand to increase,
• numerical sensitivity,
• path-planning failure.

Force and torque mapping

In an idealized form, an end-effector force maps to joint torques through:

τ = J(q)^T F

This relationship helps connect task-space force requirements to actuator loading.

Dynamic model

A common compact representation of serial-robot dynamics is:

M(q) q_ddot + C(q, q_dot) q_dot + g(q) + f(q_dot) = τ

where:

• M(q) is the mass/inertia matrix,
• C represents Coriolis and centrifugal effects,
• g(q) represents gravity,
• f represents friction,
• τ is the joint-torque vector.

Detailed dynamics may be unnecessary for slow, simple systems, but high speed, precision, and variable payloads make a purely kinematic treatment insufficient.

Unit 7: Robot control and feedback

Open-loop and closed-loop control

Open-loop systems issue commands without correcting from the measured output. Closed-loop systems compare measured state against a reference:

error = target - measured

This is the robotics manifestation of the principles developed in Automatic Control.

PID control

One common controller is PID:

u(t) = Kp e(t) + Ki ∫e(t)dt + Kd de(t)/dt

• P responds to current error,
• I responds to accumulated error,
• D responds to the rate of error change.

PID is widely used in robot joints, but it is not a universal solution. Feedforward, gravity compensation, state feedback, torque control, and model-based approaches may be needed.

Cascaded control

Servo systems can use nested loops:

position loop -> velocity loop -> current/torque loop -> motor

The inner loop usually runs faster. The software architecture must respect these different time scales.

Saturation and anti-windup

Real actuators have voltage, current, speed, and mechanical limits. A controller that ignores those bounds can accumulate integral action and recover poorly after saturation.

Physical constraints must therefore be explicit in robot software.

Safe states

Communication loss, invalid sensing, or controller faults require predefined behavior. Keeping the last command may be dangerous in one robot, while immediate stop can be more dangerous in another. Safety behavior has to be designed for the mission and physical mechanism.

Unit 8: Motion planning, task execution, and autonomy

Path versus trajectory

A path describes where the robot should move geometrically. A trajectory adds timing.

A collision-free path may still be infeasible if acceleration, velocity, or torque limits cannot satisfy it.

Search and planning

Grid or graph environments may use Dijkstra or A*, while continuous high-dimensional spaces may use sampling-based approaches. The objective is not always shortest distance. A cost function can include:

• distance,
• energy,
• collision risk,
• number of turns,
• time,
• visibility.

Behavior layer

While working on AR-CORE at AKINROBOTICS, I saw directly that higher-level behavior is not one “AI function”. A behavior needs to:

• start,
• decompose into steps,
• react to events,
• report failure,
• support interruption/recovery,
• coexist with competing priorities.

Reliable autonomy therefore often becomes an execution problem involving state machines, behavior trees, task graphs, event systems, and planners.

Tree- and circuit-based visual programming

A significant part of my AKINSOFT work involved tree/circuit-oriented visual programming for behavior definition. The difficult problem was not drawing blocks on screen; it was executing user-defined structures reliably at runtime.

A behavior editor needs to control:

• invalid connections,
• data types,
• parameter validation,
• cycles and dependencies,
• runtime error visibility,
• separation between UI and execution engine.

This reinforced a principle I later applied in many other software domains: giving users expressive power requires aggressively reducing invalid state space.

Autonomy under uncertainty

Perception is not exact. Higher-level behavior may need to carry confidence, age, source, and validity instead of reducing everything to a hard “detected/not detected” state.

A false positive in a physical robot can become movement, not merely an incorrect label.

Unit 9: Embedded systems and robot software architecture

Layered architecture

A useful abstraction for robot software is:

Hardware / drivers
        ↓
Device abstraction and communications
        ↓
Real-time control
        ↓
State and capability services
        ↓
Behavior / mission / autonomy
        ↓
Operator interface and external systems

Not every project needs these exact layers, but clear responsibility boundaries prevent hardware-specific changes from propagating through the entire software stack.

AROS / AR-CONTROL experience

AROS / AR-CONTROL was at the center of my AKINSOFT & AKINROBOTICS work. The problem was much broader than transmitting a motor command. It included:

• tracking multiple subsystem states,
• command sequencing,
• communication continuity,
• recovery after faults,
• matching software state to physical state,
• safely executing requests coming from higher-level behavior.

I used C, C++, C#, Java, and Python for different needs across the product family. Hardware-near time-sensitive code and a graphical operator layer do not have the same constraints. Choosing language and runtime according to layer responsibility became natural in this environment.

Microcontrollers and peripherals

A robot's lower layers may interact with:

• GPIO,
• PWM,
• ADC,
• encoder counters,
• UART,
• SPI,
• I2C,
• CAN or comparable buses.

Timing, interrupts, buffers, and failure behavior at this level have physical consequences. My work with microprocessors, microcontrollers, FPGA and PLC, together with the earlier TMS570/lwIP experience at Baykar, formed a practical base for understanding robot hardware-software boundaries.

Real-time behavior

Real-time does not simply mean fast. Correct computation must complete within the relevant timing bound.

A 200 ms vision delay can be a minor UI issue in one context and unacceptable in a balance or joint-control loop. Latency therefore has to be interpreted by where it appears in the control hierarchy.

Concurrency

A robot may process simultaneously:

• sensor input,
• control loops,
• telemetry,
• vision,
• speech recognition,
• operator commands,
• logging.

More threads do not automatically improve the system. State ownership, lock duration, priority inversion, queue growth, and stale-data processing require explicit design.

Unit 10: Communications, telemetry, and distributed state

A command is not state

Sending a command does not mean that it was received or executed. A robust protocol may distinguish states such as:

created -> sent -> received -> accepted -> executing -> completed / failed

The UI must define which state is sufficient before it presents success.

Telemetry

Telemetry is more than a debugging window. It is engineering evidence that helps explain what the physical system was doing at a given time.

Useful telemetry may include:

• timestamps,
• state identifiers,
• sensor values,
• commands,
• controller outputs,
• error codes,
• connectivity state,
• resource use.

In AR-CONTROL and AR-GUI work, telemetry was one of the main tools for checking consistency between the physical robot and the software/operator view.

Freshness

The “last received value” is not always the “currently valid value”. A packet may be delayed, queued, or retransmitted.

Data may therefore need metadata such as:

• measurement time,
• reception time,
• sequence number,
• validity horizon.

Link failure

Loss of connectivity is not merely a networking-layer exception. It changes robot behavior.

The system must decide whether the robot should:

• continue the current task,
• stop,
• return to a safe location,
• continue with local autonomy,
• expose a particular state to the operator.

This is a direct connection between computer networks and robot control.

Unit 11: Human-robot interaction, GUI, speech, and vision

AR-GUI and operator interfaces

Working on AR-GUI made it clear that a robot-control interface is fundamentally different from a conventional CRUD screen. The operator has to trust that the state shown on screen corresponds to the physical robot.

The interface should distinguish clearly among:

• link state,
• robot mode,
• active task,
• sensor/joint state,
• critical faults,
• commands currently being executed.

Presenting stale telemetry as current data or presenting an unapplied command as completed is not merely a usability defect; it can become an operational defect.

Speech recognition

One of the areas I worked on directly at AKINROBOTICS was HMM-based automatic speech recognition. Transformer ASR dominates many current systems, but the architecture at that time exposed acoustic feature extraction, HMM states, pronunciation/language structures, and decoding decisions more directly.

For a robot, word accuracy is not the only metric. Important dimensions include:

• false command acceptance,
• behavior under noise,
• endpointing,
• recognition latency,
• confidence thresholds,
• current behavioral context.

A transcription error in desktop dictation can be edited. A falsely accepted physical command has a different safety profile.

That early work became one of the foundations for my later work on speech feature extraction with MFCC, automatic speech recognition, and production-scale ASR systems.

Speech synthesis

TTS is not only a way to make the robot “talk”; it is an output channel for system state. Spoken feedback needs to be correctly timed with movement, interruptible, and tied to the same state transition that the robot has actually reached.

Computer vision

Robot vision cannot be separated from camera calibration, frame timing, processing latency, and the behavior layer that consumes the result.

High algorithmic accuracy is insufficient if information becomes stale before the physical action uses it. In such pipelines, throughput and age of information both matter.

Unit 12: Industrial, mobile, and humanoid robots

Industrial robots

Robots are particularly effective for tasks that are:

• repetitive,
• precise,
• heavy,
• hazardous,
• high-cycle-rate.

Welding, painting, loading/unloading, and assembly are classical industrial examples in which repeatability and process safety have to be evaluated together.

Robot selection should consider more than reach:

• payload,
• repeatability,
• cycle time,
• workspace,
• process force,
• safety envelope,
• integration cost,
• maintainability.

Mobile robots

Mobile robots emphasize localization, mapping, and path planning because the base itself moves through the environment.

Wheel kinematics, slip, terrain, and sensor field of view influence localization quality. Outdoor GPS may help, while indoor systems may combine lidar, camera, odometry, and other sources.

Robots for hazardous environments

One major use of robots is work that would expose humans to unacceptable risk. Mines, biochemical sampling, radiation, and firefighting environments illustrate a different requirement: the robot must be engineered to survive the hazardous environment as well as perform the task.

The design problem is not simply replacing a person. The robot itself can fail because of:

• temperature,
• radiation,
• water,
• dust,
• explosive atmospheres,
• chemical contamination.

Environmental survivability therefore belongs inside mission design.

Humanoid robots

Humanoid geometry is not valuable only because it looks human. It can support operation in environments designed around human proportions, tools, doors, stairs, and social interaction.

The cost is rapid growth in:

• degrees of freedom,
• kinematic complexity,
• balance control,
• energy use,
• real-time workload,
• wiring,
• mechanical constraints,
• software state space.

My AKINROBOTICS work turned this complexity from an academic description into daily engineering practice.

Unit 13: Simulation, testing, and debugging

ADA H4 and simulation

I worked on graphical interface and simulation software around ADA H4. I used simulation not merely as a visual demonstration, but as a controlled way to evaluate behavior that could be expensive or risky to reproduce repeatedly on the physical robot.

The central limitation is that simulation can only validate what it models. If friction, backlash, delay, sensor noise, and fault behavior are missing or unrealistic, the simulation can be overly optimistic.

SIL, HIL, and physical testing

Robot software can be validated at several layers:

• software/model simulation,
• algorithm tests,
• Software-in-the-Loop,
• Hardware-in-the-Loop,
• bench tests,
• physical robot tests.

Each level reveals different defects. A kinematic unit test can detect a sign error in a transform but cannot detect electrical noise from a motor drive.

End-to-end debugging

A complaint such as “the arm moves to the wrong position” can originate anywhere in:

target -> inverse kinematics -> trajectory -> controller -> drive -> motor -> mechanics -> sensor -> feedback

Good debugging follows data across those layers.

The earlier Baykar experience of tracing embedded software, electronics, and physical signals within the same fault investigation directly shaped the way I later debugged physical robot/software state at AKINROBOTICS.

Logging and reproducibility

When a field failure cannot be reproduced immediately, the following become essential:

• event timeline,
• commands,
• sensor data,
• configuration,
• software version,
• fault codes,
• operating mode.

“It worked on my machine” is not sufficient verification for a physical system.

Unit 14: Reliability, safety, and maintainability

Enforcing physical bounds

Joint, velocity, temperature, and current limits should not exist only as GUI validation. Important constraints should be enforced as close as practical to the layer that can guarantee them.

One higher-level software defect should not be enough to push a mechanism beyond safe physical bounds.

Watchdogs and liveness

A component that is technically running may still be failing to perform its time-critical function. A watchdog or heartbeat can represent different questions:

• Is the process alive?
• Is the control loop advancing?
• Is the data fresh?
• Is the deadline being met?

These meanings should not be conflated.

Fault isolation

Should a camera failure stop all motion? The answer depends on the mission. Separating critical functions can prevent one subsystem failure from unnecessarily disabling independent capabilities.

Coding standards

After my MISRA C and static-analysis work at Baykar, I continued to treat coding standards and maintainability as reliability concerns during the AKINSOFT period. Long-lived robot software benefits from:

• isolated device dependencies,
• shared and explicit data models,
• deterministic state transitions,
• clear failure contracts,
• separation of responsibilities.

These reduce the cost of hardware revisions and limit fault propagation.

Safety

Robot safety is not only an emergency-stop button. Risk depends on speed, force, workspace, proximity to people, and control mode. Industrial systems combine mechanical guarding, safety circuits, software limits, and operating procedures.

Unit 15: Engineering context of my AKINSOFT & AKINROBOTICS work

Education and professional work reinforcing each other

My AKINSOFT period was where computer engineering and mechatronics truly converged in daily practice. My Computer Engineering background at Kırıkkale University provided the algorithmic, software, operating-system, networking, and computer-architecture foundation. Sakarya University Mechatronics strengthened motors, electronics, control, hydraulics/pneumatics, and mechanical design. While working at AKINSOFT I completed that program and began Mechatronics Engineering at Afyon Kocatepe University, which allowed formal system modeling and professional robot development to reinforce one another in the same period.

A sensor or control topic from coursework would appear at work as physical robot behavior; a difficult integration issue at work would make the mathematical and system-modeling material at university much more concrete.

AROS / AR-CONTROL

One of the areas I worked on most intensively was robot control software. The problem extended from sending commands to establishing a reliable mapping between software state and physical state.

The questions were practical:

• What state is the robot actually in?
• Which command is executing?
• Was it physically applied?
• Does sensor feedback confirm it?
• What happens when communication fails?
• How does failure propagate to the behavior layer?

AR-CORE and autonomy

On AR-CORE I worked on higher-level behavior, task flow, events, and autonomy. The main challenge was not the existence of isolated functions but composing them in the correct order, at the correct time, and under the correct conditions.

This is where I learned that the hardest part of autonomy is often edge-case management rather than one impressive “intelligent” algorithm.

AR-GUI

On the operator side I worked with telemetry, faults, modes, and commands while keeping the presentation consistent with the physical robot. That experience later became a general principle in my real-time interfaces:

the UI is not decoration around system state; it is a representation of system state that must be trustworthy.

HMM-based ASR and TTS

I worked directly on HMM-based speech recognition, acoustic/feature processing, recognition logic, and behavior integration. TTS had to fit the robot's behavior timeline rather than merely generate audio.

Those projects became an early technical foundation for my later work in speech processing, speaker recognition, and large-scale ASR systems.

Computer vision

I worked on processing camera data, deriving useful information from images, and feeding that result into behavior logic. The durable lesson was that algorithmic correctness alone is insufficient: the result must also be timely and valid in the current physical context.

Visual behavior programming

My tree/circuit-based visual programming work was an early practical example of separating domain intent from implementation code. The user could define behavior visually, while the execution engine still had to enforce type, state, timing, and failure rules.

Many software-architecture ideas I now describe as separating intent from execution had an early physical-system counterpart in that work.

Expanding technical responsibility

My role gradually expanded from implementing individual modules toward evaluating the broader technical integrity of control software. That did not simply mean writing more code. Subsystem boundaries, integration, failure behavior, and maintainability became increasingly important.

Robotics therefore became less a narrow specialty and more a systems-thinking discipline for me.

Unit 16: General engineering principles I carried forward from robotics

Physics belongs to the software requirement

If software controls a physical system, mechanical and electrical limits are not external implementation details.

Measurement is not reality

Sensor values need uncertainty, time, and validity semantics.

Autonomy is state management

Planning and AI matter, but reliable autonomy also requires explicit failure, interruption, priority, and recovery behavior.

Location of latency matters

100 ms in a GUI and 100 ms in a motor-control loop have completely different effects.

Telemetry is a design requirement

The system's physical behavior should be explainable after the event.

The interface is part of the reliability chain

Correct lower-level computation may not save a mission if the operator sees the wrong state.

Simulation does not replace reality

A model cannot provide confidence about physical effects that it does not represent.

Modularity is not code aesthetics

Hardware revisions and multi-layer robot software rapidly expose the cost of poorly bounded dependencies.

Conclusion

Robotics engineering is not software added to a mechanical body.

Sensors measure the physical world.

State estimation turns measurement into a model.

Planning and behavior decide what should happen.

Control applies that intent to the physical system over time.

Actuators convert electrical commands into force and motion.

Telemetry makes the system observable.

The operator interface connects people to that loop.

Safety, fault handling, and testing attempt to make all those components reliable together rather than only individually.

For me, robotics extended the embedded and physical-systems discipline I had seen at Baykar in 2015 into a much broader engineering environment during my 2016-2019 AKINSOFT & AKINROBOTICS work. My Computer Engineering foundation, concurrent mechatronics education, and direct humanoid-robot software work reinforced each other during the same period.

Working on AROS/AR-CONTROL, AR-CORE, AR-GUI, ADA H4, visual behavior programming, HMM-based speech recognition, TTS, computer vision, and telemetry demonstrated that there is no isolated island called “software” inside a robot.

A robot's behavior is the combined result of code, electronics, mechanics, control, data, and time.

References

Bruno Siciliano, Lorenzo Sciavicco, Luigi Villani, Giuseppe Oriolo, Robotics: Modelling, Planning and Control, Springer.

Mark W. Spong, Seth Hutchinson, M. Vidyasagar, Robot Modeling and Control, Wiley.

John J. Craig, Introduction to Robotics: Mechanics and Control, Pearson.

Peter Corke, Robotics, Vision and Control: Fundamental Algorithms in MATLAB, Springer.

My AKINSOFT and AKINROBOTICS experience

What Is Mechatronics?

Automatic Control

Avionics Systems and Unmanned Aerial Vehicles