.NET y robótica: ya va siendo hora de salir del CRUD
Este artículo forma parte del pilar .NET y arquitectura.
Cuando quise empezar con el hardware, pensé en un Arduino. Fue frustrante. Venía de trabajar con computadoras y de quejarme, a veces, de que tenían poca memoria o pocos recursos. Acercarme a un dispositivo de ese tamaño me hizo poner esas quejas en perspectiva.
Pero lo que más me hizo pensar fue descubrir cuánto tenía que aprender además de programar. El hardware me obligó a mirar problemas que desde el software daba por resueltos, o que ni siquiera había considerado.
Por eso me interesa que quienes trabajamos con .NET nos acerquemos más a la robótica y a los dispositivos físicos. Hay herramientas para entrar desde C#, y hay novedades interesantes. Pero antes de hablar de ellas, quiero contar una experiencia que explica mejor por qué creo que vale la pena.
Cuando un lector de huellas parecía una buena idea
Una vez trabajé con un sistema que utilizaba un lector de huellas para registrar asistencia. Desde el punto de vista del software, la decisión parecía bastante acertada: identificar a una persona y registrar su entrada.
El detalle era dónde se iba a utilizar. Muchas de esas personas trabajaban en minería, y las condiciones de sus manos y sus huellas dificultaban el uso del lector. En ese contexto, elegir la huella como mecanismo de asistencia terminó siendo una solución menos adecuada de lo que parecía al pensar solamente en la aplicación.
A eso se sumaba que la conectividad de la zona tampoco era buena.
Podías tener bien resuelta la lógica del registro y seguir teniendo un problema para tomar asistencia. La aplicación dependía de que una persona pudiera identificarse con ese dispositivo, en esas condiciones, y de una conectividad que no podíamos dar por sentada.
Habíamos elegido una solución que parecía correcta desde el software, pero el contexto físico tenía mucho que decir.
Esa experiencia me dejó una forma distinta de mirar estas decisiones. Antes de discutir cómo guardar el registro, había que entender quién iba a poner la mano en el lector, en qué condiciones lo haría y qué ocurriría cuando la lectura o la conexión fallaran.
La lección tampoco es descartar los lectores de huellas en cualquier escenario. Es probar la elección con las personas y las condiciones del lugar donde se va a usar. En nuestro caso, esa combinación importaba más de lo que la solución de software dejaba ver.
El mundo físico agrega variables que no estamos mirando
Cuando programamos, solemos buscar condiciones reproducibles. Con las mismas entradas y el mismo estado, esperamos obtener el mismo resultado. El software también tiene concurrencia, redes y fallos difíciles de reproducir; aun así, muchas veces podemos aislar el problema y controlar buena parte del entorno de una prueba.
Con hardware de por medio, es más fácil creer que estamos repitiendo las mismas condiciones cuando en realidad algo cambió. La posición de una mano, el contacto con un sensor o la alimentación de un dispositivo pueden afectar el resultado.
Eso obliga a revisar nuestras suposiciones. Que el código siga igual no significa que todo el sistema esté en el mismo estado.
Mi acercamiento a Arduino empezó por la frustración con los recursos disponibles. El aprendizaje iba más allá de ahorrar memoria: tenía que entender mejor el dispositivo y lo que ocurría a su alrededor. Resolver el problema exigía ampliar lo que estaba dispuesto a observar.
Y ahí veo una buena razón para tocar hardware, incluso si después seguimos dedicándonos al backend. Te acostumbra a preguntar qué estás dejando fuera de tu modelo del problema. En el sistema de asistencia, las manos de los trabajadores eran parte del sistema tanto como la base de datos.
Dónde encajan .NET y la robótica en todo esto
Acercarnos a ese mundo desde C# es posible. Las bibliotecas .NET IoT de Microsoft incluyen System.Device.Gpio e Iot.Device.Bindings, con ejemplos para trabajar con sensores y placas como Raspberry Pi. Hay que comprobar la compatibilidad concreta de la placa y sus periféricos, pero tenemos una entrada desde un lenguaje conocido.
Para microcontroladores compatibles existe .NET nanoFramework, con su propio runtime y sus restricciones. Eso no significa que cualquier Arduino ejecute .NET, ni que podamos llevar una aplicación ASP.NET a un microcontrolador. Elegir el dispositivo sigue siendo una decisión técnica.
En robótica industrial también hay un espacio para C#. Un ejemplo reciente es ABB: RobotStudio utiliza .NET 10 desde la versión 2026.1. Aquí .NET participa en el entorno de ingeniería y sus extensiones; los programas del robot siguen teniendo su propio lenguaje y controlador.
Lo interesante para nosotros es que podemos aprovechar lo que ya sabemos para entrar en otro dominio. Después tocará aprender sensores, coordenadas, movimiento o electrónica, según el proyecto. C# nos ayuda a empezar; entender el equipo y su entorno nos permite avanzar.
Un ejemplo reciente que conecta con ese aprendizaje
Hay un trabajo publicado el 13 de agosto de 2026 que conecta un modelo de lenguaje con RobotStudio mediante MCP. Genera programas en RAPID, el lenguaje de robots de ABB, y usa la simulación para ejecutarlos y corregirlos.
El detalle que me interesa es que aparecen errores que no se resuelven mirando solamente el texto del programa: una altura incorrecta al soltar una pieza o una posición que el robot no puede alcanzar. La evaluación se hizo en una celda simulada y mantiene la necesidad de preparación y supervisión experta.
Eso conecta con lo que aprendí con el lector de huellas: para evaluar una solución necesitas observar lo que ocurre cuando intenta cumplir su función. En aquel caso, con las personas que iban a usarla. En este, con el comportamiento que representa la simulación, antes de pasar al equipo real.
El puente público del experimento combina un servidor MCP en TypeScript con un add-in en C# para .NET Framework 4.8 y RobotStudio 2024. Es distinto de la migración de ABB a .NET 10; llevar ese add-in a RobotStudio 2026 requeriría revisar su compatibilidad y migrarlo.
Tenemos, entonces, un caso concreto de C# participando en robótica. Y también una buena muestra de cuánto trabajo queda después de generar código.
Antes de construir la interfaz, entender qué puede fallar
Si hoy planteara un proyecto pequeño con un sensor y un actuador, empezaría por comprobar el comportamiento físico. Qué detecta el sensor, cuándo deja de detectarlo y cómo sé que ocurrió el movimiento esperado. La interfaz vendría después de entender eso.
Una forma de ordenar las responsabilidades sería esta:
La aplicación puede pedir una operación. El control local necesita decidir si puede ejecutarla y utilizar las lecturas disponibles para comprobar qué pasó. Si una respuesta se pierde, repetir la orden a ciegas podría repetir también el movimiento.
En el caso de la asistencia, ese mismo hábito de pensar en los fallos lleva a preguntas muy concretas: cómo se registra a alguien cuando el lector no consigue identificarlo, qué pasa sin conexión y cómo se evita perder o duplicar registros al recuperarla. Son preguntas que hay que resolver con el proceso de trabajo y con quienes lo usan.
Para aprender, empezaría con un montaje pequeño y de baja energía. Para una máquina con exigencias estrictas de tiempo o seguridad, haría falta evaluar los controladores y mecanismos adecuados. Saber C# no sustituye ese conocimiento, y tampoco conviene forzar .NET en cada parte del sistema.
Lo que sí podemos llevar desde el primer día es la costumbre de comprobar nuestras suposiciones. Probar el dispositivo en el entorno previsto, observar sus fallos y ajustar la solución antes de darla por buena.
Ahí es donde nuestro análisis tiene más valor
Creo que esto cobra más importancia con la IA. Cada vez podemos delegar más trabajo de implementación y obtener código con menos esfuerzo. Mi impresión es que, en tareas concretas, ya nos está obligando a revisar cuánto de nuestro valor profesional apoyábamos en escribir ese código.
Pero alguien tiene que detectar que un lector de huellas puede ser una mala elección para esas personas. Alguien tiene que preguntar por la conectividad antes de diseñar un flujo que dependa de ella. Y alguien tiene que ir al lugar, escuchar y comprobar si la solución realmente sirve.
La IA puede ayudarnos a analizar esas situaciones si le damos el contexto. Reconocer qué contexto falta y buscarlo sigue siendo una responsabilidad nuestra. Una implementación impecable puede resolver con mucha eficiencia un problema que entendimos mal.
Por eso quiero acercarme más al hardware e invito a otros desarrolladores .NET a hacer lo mismo. Mi experiencia al empezar fue frustrante, pero me hizo pensar de otra manera. Nos viene bien trabajar con algo que nos obligue a levantar la mirada del código y prestar atención a las condiciones en las que vive la gente que lo usa.
El siguiente aprendizaje puede empezar con un sensor. Y puede terminar cambiando cómo elegimos la solución completa.
Si quieres seguir aprendiendo sobre estos temas te invito a ver mis otras publicaciones.
