![](\"https:\/\/lh7-us.googleusercontent.com\/_hRwvBDcsFqN5cl5a3OovjTD_27k_hHMcI7TQZNsqwGI3C4nZpkgt_oYy-a-LgAg-pIOz72C0RsS61lfs7K5jg7k_5FBIcvN79TBH-SGlpuJyFdUrjjuRYsCVICWL8gFxUxNjxkgASYYQlAsPX2WfQw\")
![](\"https:\/\/lh7-us.googleusercontent.com\/P4FxLKz-O9KXkod7z6S4bR1i29KGk-dZKWLpaiRdO9yFdgFKvwIyc2v16EtpdNsBiKSss2os_L3Ar0cKXES81Er1oc1dhWKqeeQcnGIEFK8FQPdoDnp4AM5y-ZI2msbPon7RBuefhcj1SjaTv8N1czY\")
G\u00f3ndola<\/h3>\n\n\n\n
La g\u00f3ndola, denominada as\u00ed por ser la parte del mecanismo que sujeta el bol\u00edgrafo o rotulador, fue dise\u00f1ada tomando como inspiraci\u00f3n las herramientas de dibujo, como los compases, que poseen una pieza externa que permite la adici\u00f3n de un lapicero a su estructura.<\/p>\n\n\n\n
Finalmente, se lleg\u00f3 a un dise\u00f1o formado por:<\/p>\n\n\n\n
- \n
- Un cuadrado 10×10 cm de madera con un orificio de 25mm ligeramente desplazado del centro, que constituye la estructura base de la pieza.<\/li>\n\n\n\n
- Un tubo de pvc de 25mm de di\u00e1metro, situado sobre el orificio del componente anterior. Este tiene un tornillo en el lado m\u00e1s cercano al borde de la pieza de madera, que al enroscarlo, permite fijar el lapicero en el centro de la estructura.<\/li>\n\n\n\n
- Dos tornillos colocados en las dos esquinas superiores, que aseguran la correa conectada a ambos motores, proporcionando la fuerza necesaria para los movimientos.<\/li>\n\n\n\n
- Una pesa colocada en la parte m\u00e1s baja de la estructura para equilibrar la estructura y optimizar la precisi\u00f3n en el trazo.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
Im\u00e1genes del Proceso de Dise\u00f1o<\/h3>\n\n\n\n
Este dise\u00f1o ha sido fruto de un proceso iterativo y colaborativo, donde cada ajuste se realiz\u00f3 con el objetivo de mejorar la eficiencia y la estabilidad del plotter. Como prueba de esto, a continuaci\u00f3n se adjuntan im\u00e1genes de dicho proceso:<\/p>\n\n\n\n
Cuerpo principal<\/strong><\/h4>\n\n\n\n
![\"\"](\"https:\/\/blogs.etsii.urjc.es\/dseytr\/wp-content\/uploads\/sites\/8\/2023\/12\/diseno-cuerpo-1024x979.png\")
<\/figure>\n\n\n\nG\u00f3ndola<\/strong><\/h4>\n\n\n\n
![\"\"](\"https:\/\/blogs.etsii.urjc.es\/dseytr\/wp-content\/uploads\/sites\/8\/2023\/12\/diseno-carrito-1-1024x770.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/blogs.etsii.urjc.es\/dseytr\/wp-content\/uploads\/sites\/8\/2023\/12\/diseno-carrito-2-1024x714.png\")
<\/figure>\n\n\n\nMateriales requeridos y precio total<\/h2>\n\n\n\n
Para llevar a cabo este proyecto, se han aprovechado varios componentes proporcionados en la caja Elegoo facilitada por la universidad:<\/p>\n\n\n\n
- \n
- Un motor Stepper.<\/li>\n\n\n\n
- Cableado.<\/li>\n\n\n\n
- Un joystick.<\/li>\n\n\n\n
- Placa y breadboard de Arduino.<\/li>\n<\/ul>\n\n\n\n
Sin embargo, a pesar de contar con estos elementos, fue necesario realizar algunas adquisiciones de manera personal para garantizar el \u00e9xito del proyecto. Estos componentes adicionales, indispensables para continuar con el desarrollo, incluyeron:<\/p>\n\n\n\n
- \n
- Un motor Stepper adicional (1,50\u20ac)<\/li>\n\n\n\n
- Una correa GT2 (8m) (10,24\u20ac)<\/li>\n\n\n\n
- Dos poleas GT2 de 5mm y 36 dientes (3,70\u20ac)<\/li>\n\n\n\n
- Una tabla de contrachapado (4,50\u20ac)<\/li>\n\n\n\n
- Un tubo de PVC (1,00\u20ac)<\/li>\n\n\n\n
- Un bote de pegamento extra fuerte (6,55\u20ac)<\/li>\n\n\n\n
- Tornillos, tuercas, pizarra y pesas (Propiedad de los alumnos)<\/li>\n<\/ul>\n\n\n\n
El costo total de estos materiales adicionales ascendi\u00f3 a 27,49\u20ac, aunque es importante se\u00f1alar que al considerar los gastos de env\u00edo de algunos de estos elementos, el costo total del proyecto fue de 32,99\u20ac. Esta inversi\u00f3n result\u00f3 crucial para asegurar la disponibilidad de los recursos necesarios y mantener la viabilidad y calidad del proyecto en su conjunto.<\/p>\n\n\n\n
2. Desarrollo del proyecto<\/h1>\n\n\n\n
Funcionamiento de los Steppers<\/h2>\n\n\n\n
En primer lugar, comenzamos el proyecto averiguando c\u00f3mo funcionan los motores. Estos est\u00e1n conectados al driver ULN2003 que se conecta a 4 pines digitales en la placa de Arduino.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blogs.etsii.urjc.es\/dseytr\/wp-content\/uploads\/sites\/8\/2023\/12\/stepper-1024x671.jpg\")
<\/figure>\n\n\n\nEn el c\u00f3digo, se asignan los pines a cada una de las entradas y la rotaci\u00f3n se establece mediante la funci\u00f3n step, que indica el n\u00famero de pasos que tiene que dar el motor.<\/p>\n\n\n\n
Fue necesario utilizar una librer\u00eda en la que se implementara su funcionamiento, inicialmente empezamos a implementar unas funciones propias para el control de los motores (funciones step personalizadas, controlando la secuencia de la actuaci\u00f3n de los polos del motor de forma directa), ya que con la librer\u00eda que proporciona Arduino nos fue imposible hacer que rotasen simult\u00e1neamente debido al interbloqueo de su funci\u00f3n step(). Finalmente, recurrimos a una librer\u00eda llamada \u00abCheapStepper\u00bb, puesto que la encontramos mientras est\u00e1bamos implementando nuestra propia librer\u00eda y decidimos usarla para ahorrar tiempo (porque era un problema resuelto). Esta librer\u00eda permiti\u00f3 resolver los problemas de sincronizaci\u00f3n de los motores[link] por medio de las funciones de movimientos no-bloqueantes (step() y run()). Sin embargo, a pesar de haber utilizado una librer\u00eda externa, fue necesario modificarla para el proyecto.<\/p>\n\n\n\n
Clases implementadas y modelo matem\u00e1tico<\/h2>\n\n\n\n
Para facilitar la representaci\u00f3n de los datos y el modelo matem\u00e1tico del sistema hemos creado algunas clases y structs:<\/p>\n\n\n\n
- \n
- Una clase Vec2 para el facilitar el uso y las operaciones de vectores y coordenadas.<\/li>\n\n\n\n
- Un struct Belt que permite almacenar las longitudes de las correas que corresponde a cada motor. <\/li>\n<\/ul>\n\n\n\n
Estos datos se utilizan en una serie de funciones:<\/p>\n\n\n\n
- \n
- canvasCoordinatesToBeltLengths<\/strong>. Calcula la longitud que se corresponde a la posicion sobre el lienzo proporcionada. Hace esto calculando las distancias a los ejes de los motores desde el punto del lienzo (para poder hacer este c\u00e1lculo correctamente primero traduce las coordenadas del lienzo a coordenadas de \u201cmundo\u201d que son el sistema de referencia de los motores).<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
- \n
- beltLengthsToCanvasCoordinates<\/strong>. <\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
- \n
- worldToCanvasCoordinates<\/strong>. Convierte las coordenadas globales (el sistema de referencia de los motores), a coordenadas del lienzo. En el caso de las coordenadas globales, el punto (0,0) est\u00e1 situado en la esquina superior izquierda (sobre el motor 0) el eje coordenado x (horizontal) avanza hacia la derecha, mientras el eje y (vertical) crece hacia abajo en el caso de las coordenadas del lienzo, el punto (0,0) est\u00e1 colocado en el origen que se le ha indicado.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
- \n
- canvasToWorldCoordinates<\/strong>. Convierte las coordenadas del lienzo a coordenadas globales.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
- \n
- moveToPoint<\/strong>. Mueve la g\u00f3ndola a la coordenada indicada, traduciendo la longitud de las correas a n\u00famero de pasos que mueve el motor.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
- \n
- moveBelts<\/strong>. Establece una longitud concreta de las correas.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
Joystick y funciones para probar el funcionamiento<\/h2>\n\n\n\n
Para poder probar el funcionamiento de las clases implementadas, se utiliz\u00f3 un joystick que controla la direcci\u00f3n en la que se mueve la g\u00f3ndola. Este joystick va conectado a un pin digital para usar el clic del bot\u00f3n y a dos pines anal\u00f3gicos que reciben la entrada de los ejes en los que se mueve.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Se utiliza la siguiente funci\u00f3n para procesar el joystick:<\/p>\n\n\n\n
<\/p>\n\n\n\n
Adem\u00e1s del joystick, antes de pasarle a Arduino c\u00f3digo de G-Code, se prob\u00f3 tambi\u00e9n el funcionamiento del dispositivo mediante una funci\u00f3n matem\u00e1tica que dibuja una circunferencia:<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
G-Code a Arduino<\/h2>\n\n\n\n
Antes de poder pasarle una imagen a Arduino, primero, hay que obtener un archivo .gcode del camino que se quiera recorrer, y por tanto dibujar. Para obtener este .gcode, hemos optado por generarlo a partir de archivos vectoriales .svg proces\u00e1ndolos con svg2gcode<\/a>. Estos archivos vectoriales los hemos obtenido a partir de im\u00e1genes (.png o .jpeg) por medio de la herramienta de vectorizaci\u00f3n de Image Trace de Adobe Illustrator. Adem\u00e1s para previsualizar el recorrido G-Code final hemos utilizado gcode-viewer<\/a>.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blogs.etsii.urjc.es\/dseytr\/wp-content\/uploads\/sites\/8\/2023\/12\/image-96-1024x555.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Esta p\u00e1gina convierte gr\u00e1ficos vectoriales a G-Code, creando un archivo con las coordenadas de cada uno de los puntos de las figuras de la imagen, incluyendo la interpolaci\u00f3n (discretizaci\u00f3n) de los puntos de las curvas propias del formato vectorial, a una resoluci\u00f3n configurable (mediante prueba y error concluimos que la resoluci\u00f3n \u00f3ptima era de 0,1mm).<\/p>\n\n\n\n
Una vez creado el archivo G-Code, lo interpretamos y comunicamos al Arduino a trav\u00e9s de un script de Python que hemos programado.<\/p>\n\n\n\n
Las funciones del script son las siguientes:<\/p>\n\n\n\n
- \n
- parse_gcode<\/strong>. <\/strong>Primero extrae la informaci\u00f3n de las coordenadas contenidas en el archivo .gcode.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
- \n
- normalize_and_map. <\/strong>Despu\u00e9s se traducen estas coordenadas al sistema de referencia del lienzo del plotter, que el arduino es capaz de interpretar correctamente.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
- \n
- send_to_arduino<\/strong><\/span><\/span>. Finalmente estas coordenadas se transmiten al Arduino de forma progresiva, seg\u00fan el protocolo de comunicaci\u00f3n que hemos desarrollado. Vamos a concretar el funcionamiento de este protocolo y el proceso de interpretaci\u00f3n de las coordenadas del Arduino: El plotter realiza movimientos exclusivamente en l\u00ednea recta, entre cada coordenada que recibe a su variable \u2018targetPosition\u2019 (bien sea interpretada de gcode o introducido por el terminal a trav\u00e9s del puerto serial, o por la manipulaci\u00f3n del Joystick) y su posici\u00f3n actual \u2018carriagePosition\u2019.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
- \n
- main<\/strong>. En el main se busca el archivo .gcode, se ajusta el tama\u00f1o del lienzo y se establece el puerto serie.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
Ejemplo de protocolo de comunicaci\u00f3n con Arduino en ejecuci\u00f3n. <\/strong>R(coordenadas) \u2190 la salida Serial del Arduino que recibe el script. Indica las coordenadas actuales de la g\u00f3ndola del plotter. La R se\u00f1aliza ‘Ready’ de la solicitud de coordenadas al script. Las coordenadas que se muestran bajo el mensaje del plotter es el mensaje que env\u00eda el script por medio de la interfaz Serial, que son las coordenadas en el formato que comprende el plotter. Debajo se imprime el estado de ejecuci\u00f3n que refleja el porcentaje de compleci\u00f3n del camino G-Code, el tiempo transcurrido (en segundos) y una estimaci\u00f3n calculada din\u00e1micamente del tiempo de dibujado restante.<\/p>\n\n\n\n
Problemas encontrados<\/h1>\n\n\n\n
Durante el desarrollo del proyecto, encontramos varios problemas que tuvimos que solucionar o solventar de ciertas maneras. A continuaci\u00f3n, explicamos cuales fueron y c\u00f3mo fueron solucionados.<\/p>\n\n\n\n
- \n
- Tensi\u00f3n de las correas<\/strong>. Hemos tenido varios problemas a nivel f\u00edsico. Uno de los mayores limitantes del proyecto es el problema ocasionado por el tensionado de las correas a medida que la g\u00f3ndola se aleja del centro. Cuando esta sube a una determinada altura, hay demasiada tensi\u00f3n en una de las correas, por lo que los motores deben girar mucho para moverse un poco, mientras que, cuando se mueve a una de las esquinas inferiores, la tensi\u00f3n en una de las correas es muy poca por lo que, con que el motor gire un poco, la g\u00f3ndola va a moverse mucho. A continuaci\u00f3n, mostramos una imagen explicativa de este fen\u00f3meno:<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
Al final, debido a la complejidad que esto supondr\u00eda y al resto de limitaciones que acompa\u00f1an el proyecto, se decidi\u00f3 que lo m\u00e1s conveniente era establecer un lienzo en el que pintar, aproximado a la zona verde indicada en la imagen anterior.<\/p>\n\n\n\n
- \n
- Sincronizaci\u00f3n de los motores<\/strong>. Como ya se ha mencionado con anterioridad, los Steppers y la librer\u00eda proporcionada por Arduino, no solventan los problemas de sincronizaci\u00f3n proporcionados al utilizar dos motores. Es por eso que se mov\u00edan haciendo, primero un movimiento uno de los motores, y una vez acabado, se hac\u00eda el otro movimiento. Es gracias a una librer\u00eda que encontramos en internet que proporciona funciones de movimiento no-bloqueantes, que pudimos abarcar este problema. A continuaci\u00f3n, dejamos el enlace al repositorio de GitHub de esta librer\u00eda: Repositorio de Github: CheapStepper<\/a><\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
- \n
- Traducci\u00f3n de longitud a pasos del motor<\/strong>. Otro de los problemas encontrados fue el paso de las revoluciones del motor a la longitud que recorre la correa. La ecuaci\u00f3n que permite conocer este dato es la de la longitud de una circunferencia: 2*\u03c0 * r . Sin embargo, esto no fue todo, ya que fue necesario pasar la longitud que recorr\u00eda la g\u00f3ndola a steps<\/em> del motor, lo que no fue f\u00e1cil ya que lo m\u00ednimo que permite recorrer un motor es \u00bd paso. Si el paso es menor que esto, lo aproxima a 0 y no permite moverse. La manera en la que esto fue resuelto fue almacenando la cantidad de longitud que tiene que moverse cada vez que da un paso, por lo que, si es menor a medio paso, la siguiente vez que compruebe cu\u00e1nto tiene que moverse, se mover\u00e1 la longitud acumulada. Esto hace que siempre quede un peque\u00f1o error en las longitudes, por lo que se almacena tambi\u00e9n este valor en una variable.<\/li>\n\n\n\n
- Debug con Serial<\/strong>. Otro de los problemas que tuvimos al principio fue que para comprobar muchos valores simult\u00e1neos, imprimimos en Serial bastantes valores, para conocer las longitudes de la correa, el error, los pasos que se mov\u00eda el motor, etc. Es por culpa de lo ineficiente de esta funci\u00f3n que se ralentizaba el dispositivo e iba tan lento que no parec\u00eda funcionar correctamente. Finalmente concluimos con que era mejor debuguear cuando fuese necesario, y solamente con lo que quer\u00edamos comprobar en ese momento.<\/li>\n\n\n\n
- L\u00edneas rectas<\/strong>. Uno de los problemas que encontramos al enviar las coordenadas de un punto era que, cuando ten\u00eda que moverse en l\u00ednea recta, la g\u00f3ndola se mov\u00eda haciendo una especie de zigzag, primero movi\u00e9ndose como una diagonal, y al final movi\u00e9ndose a la coordenada indicada. Para solventar este problema, se recurri\u00f3 a subdividir los trazos en funci\u00f3n de una constante, para que corrigiese la direcci\u00f3n del movimiento a medida que se fuese moviendo en la recta.<\/li>\n<\/ul>\n\n\n\n
Soluci\u00f3n:Para solventar esto se implementaron dos funciones, una \u2018created Waypoints\u2019 que establece las variables que se utilizan para la interpolaci\u00f3n del recorrido (siempre que la longitud de este supere la resoluci\u00f3n de subdivisi\u00f3n establecida en mm), y otra funci\u00f3n \u2018moveTo Waypoints\u2019 que va moviendo la variable \u2018targetPosition\u2019incrementalmente seg\u00fan un vector en la direcci\u00f3n del trazo, con una magnitud dada por la resoluci\u00f3n de subdivisi\u00f3n.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blogs.etsii.urjc.es\/dseytr\/wp-content\/uploads\/sites\/8\/2023\/12\/image-55.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
<\/p>\n\n\n\n
- \n
- Verticales<\/strong>. Debido a un problema en una de las funciones programadas, cuando la g\u00f3ndola se mov\u00eda en direcciones verticales, funcionaba incorrectamente. Esto se solucion\u00f3 ya que nos dimos cuenta de que la funci\u00f3n que permit\u00eda controlar el flujo del programa, runStepper<\/em> (controla el no mandar un movimiento nuevo antes de acabar el anterior), que va sumando el n\u00famero de pasos que tiene que hacer, sumaba incorrectamente, ya que no hac\u00eda el valor absoluto. Al moverse la g\u00f3ndola en vertical, los motores se mov\u00edan en direcciones contrarias, y el valor que almacena los pasos que tiene que dar el motor val\u00eda 0 antes de tiempo, por lo que asum\u00eda una posici\u00f3n incorrecta.<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/blogs.etsii.urjc.es\/dseytr\/wp-content\/uploads\/sites\/8\/2023\/12\/image-56.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Esta es la funci\u00f3n en la que ocurr\u00eda el error.<\/p>\n\n\n\n
- \n
- Orden de recorrido<\/strong>. Al procesar una imagen en Illustrator para obtener el archivo .svg y as\u00ed convertirlo a G-Code y envi\u00e1rselo a Arduino, el recorrido de las coordenadas que se realizaba no era el m\u00e1s \u00f3ptimo, por lo que, al no haber implementado funcionalidad que permitiese levantar el bol\u00edgrafo de la g\u00f3ndola, el dibujo quedaba cubierto por un mont\u00f3n de l\u00edneas de tr\u00e1nsito. Es por ello que se program\u00f3 un c\u00f3digo que ordenaba en Illustrator los puntos en funci\u00f3n al camino m\u00e1s corto, haciendo que el resultado final fuese mucho m\u00e1s legible.<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/td>
<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Una vez solucionado el problema, el resultado es el siguiente:<\/p>\n\n\n\n
<\/td>
<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
V\u00eddeo demostrativo<\/h2>\n\n\n\n
- Orden de recorrido<\/strong>. Al procesar una imagen en Illustrator para obtener el archivo .svg y as\u00ed convertirlo a G-Code y envi\u00e1rselo a Arduino, el recorrido de las coordenadas que se realizaba no era el m\u00e1s \u00f3ptimo, por lo que, al no haber implementado funcionalidad que permitiese levantar el bol\u00edgrafo de la g\u00f3ndola, el dibujo quedaba cubierto por un mont\u00f3n de l\u00edneas de tr\u00e1nsito. Es por ello que se program\u00f3 un c\u00f3digo que ordenaba en Illustrator los puntos en funci\u00f3n al camino m\u00e1s corto, haciendo que el resultado final fuese mucho m\u00e1s legible.<\/li>\n<\/ul>\n\n\n\n
- Debug con Serial<\/strong>. Otro de los problemas que tuvimos al principio fue que para comprobar muchos valores simult\u00e1neos, imprimimos en Serial bastantes valores, para conocer las longitudes de la correa, el error, los pasos que se mov\u00eda el motor, etc. Es por culpa de lo ineficiente de esta funci\u00f3n que se ralentizaba el dispositivo e iba tan lento que no parec\u00eda funcionar correctamente. Finalmente concluimos con que era mejor debuguear cuando fuese necesario, y solamente con lo que quer\u00edamos comprobar en ese momento.<\/li>\n\n\n\n
- Traducci\u00f3n de longitud a pasos del motor<\/strong>. Otro de los problemas encontrados fue el paso de las revoluciones del motor a la longitud que recorre la correa. La ecuaci\u00f3n que permite conocer este dato es la de la longitud de una circunferencia: 2*\u03c0 * r . Sin embargo, esto no fue todo, ya que fue necesario pasar la longitud que recorr\u00eda la g\u00f3ndola a steps<\/em> del motor, lo que no fue f\u00e1cil ya que lo m\u00ednimo que permite recorrer un motor es \u00bd paso. Si el paso es menor que esto, lo aproxima a 0 y no permite moverse. La manera en la que esto fue resuelto fue almacenando la cantidad de longitud que tiene que moverse cada vez que da un paso, por lo que, si es menor a medio paso, la siguiente vez que compruebe cu\u00e1nto tiene que moverse, se mover\u00e1 la longitud acumulada. Esto hace que siempre quede un peque\u00f1o error en las longitudes, por lo que se almacena tambi\u00e9n este valor en una variable.<\/li>\n\n\n\n
- Sincronizaci\u00f3n de los motores<\/strong>. Como ya se ha mencionado con anterioridad, los Steppers y la librer\u00eda proporcionada por Arduino, no solventan los problemas de sincronizaci\u00f3n proporcionados al utilizar dos motores. Es por eso que se mov\u00edan haciendo, primero un movimiento uno de los motores, y una vez acabado, se hac\u00eda el otro movimiento. Es gracias a una librer\u00eda que encontramos en internet que proporciona funciones de movimiento no-bloqueantes, que pudimos abarcar este problema. A continuaci\u00f3n, dejamos el enlace al repositorio de GitHub de esta librer\u00eda: Repositorio de Github: CheapStepper<\/a><\/li>\n<\/ul>\n\n\n\n
- Tensi\u00f3n de las correas<\/strong>. Hemos tenido varios problemas a nivel f\u00edsico. Uno de los mayores limitantes del proyecto es el problema ocasionado por el tensionado de las correas a medida que la g\u00f3ndola se aleja del centro. Cuando esta sube a una determinada altura, hay demasiada tensi\u00f3n en una de las correas, por lo que los motores deben girar mucho para moverse un poco, mientras que, cuando se mueve a una de las esquinas inferiores, la tensi\u00f3n en una de las correas es muy poca por lo que, con que el motor gire un poco, la g\u00f3ndola va a moverse mucho. A continuaci\u00f3n, mostramos una imagen explicativa de este fen\u00f3meno:<\/li>\n<\/ul>\n\n\n\n
- main<\/strong>. En el main se busca el archivo .gcode, se ajusta el tama\u00f1o del lienzo y se establece el puerto serie.<\/li>\n<\/ul>\n\n\n\n
- send_to_arduino<\/strong><\/span><\/span>. Finalmente estas coordenadas se transmiten al Arduino de forma progresiva, seg\u00fan el protocolo de comunicaci\u00f3n que hemos desarrollado. Vamos a concretar el funcionamiento de este protocolo y el proceso de interpretaci\u00f3n de las coordenadas del Arduino: El plotter realiza movimientos exclusivamente en l\u00ednea recta, entre cada coordenada que recibe a su variable \u2018targetPosition\u2019 (bien sea interpretada de gcode o introducido por el terminal a trav\u00e9s del puerto serial, o por la manipulaci\u00f3n del Joystick) y su posici\u00f3n actual \u2018carriagePosition\u2019.<\/li>\n<\/ul>\n\n\n\n
- normalize_and_map. <\/strong>Despu\u00e9s se traducen estas coordenadas al sistema de referencia del lienzo del plotter, que el arduino es capaz de interpretar correctamente.<\/li>\n<\/ul>\n\n\n\n
- parse_gcode<\/strong>. <\/strong>Primero extrae la informaci\u00f3n de las coordenadas contenidas en el archivo .gcode.<\/li>\n<\/ul>\n\n\n\n
- moveBelts<\/strong>. Establece una longitud concreta de las correas.<\/li>\n<\/ul>\n\n\n\n
- moveToPoint<\/strong>. Mueve la g\u00f3ndola a la coordenada indicada, traduciendo la longitud de las correas a n\u00famero de pasos que mueve el motor.<\/li>\n<\/ul>\n\n\n\n
- canvasToWorldCoordinates<\/strong>. Convierte las coordenadas del lienzo a coordenadas globales.<\/li>\n<\/ul>\n\n\n\n
- worldToCanvasCoordinates<\/strong>. Convierte las coordenadas globales (el sistema de referencia de los motores), a coordenadas del lienzo. En el caso de las coordenadas globales, el punto (0,0) est\u00e1 situado en la esquina superior izquierda (sobre el motor 0) el eje coordenado x (horizontal) avanza hacia la derecha, mientras el eje y (vertical) crece hacia abajo en el caso de las coordenadas del lienzo, el punto (0,0) est\u00e1 colocado en el origen que se le ha indicado.<\/li>\n<\/ul>\n\n\n\n
- beltLengthsToCanvasCoordinates<\/strong>. <\/li>\n<\/ul>\n\n\n\n
- canvasCoordinatesToBeltLengths<\/strong>. Calcula la longitud que se corresponde a la posicion sobre el lienzo proporcionada. Hace esto calculando las distancias a los ejes de los motores desde el punto del lienzo (para poder hacer este c\u00e1lculo correctamente primero traduce las coordenadas del lienzo a coordenadas de \u201cmundo\u201d que son el sistema de referencia de los motores).<\/li>\n<\/ul>\n\n\n\n