{"id":2513,"date":"2020-07-19T09:59:03","date_gmt":"2020-07-19T09:59:03","guid":{"rendered":"http:\/\/blog.rastersoft.com\/?p=2513"},"modified":"2020-10-21T12:14:44","modified_gmt":"2020-10-21T12:14:44","slug":"a-ritmo-de-conga-y-7","status":"publish","type":"post","link":"https:\/\/blog.rastersoft.com\/?p=2513","title":{"rendered":"A ritmo de conga (7)"},"content":{"rendered":"\n

DISCLAIMER:<\/strong> no ser\u00e9 responsable si alguien decide seguir mis pasos y se carga su aspiradora. En principio todo lo que cuento deber\u00eda ser seguro, pero por motivos obvios no me puedo responsabilizar de lo que hagan otras personas, s\u00f3lo de lo que haga yo.<\/p>\n\n\n\n

En la anterior entrada par\u00e9 tras comentar los distintos comandos de que dispone la aspiradora y del formato del mensaje de estado. Ahora llega el momento de explicar el formato de los mapas. Claro que debo ser sincero: hace unos d\u00edas encontr\u00e9 un repositorio de Git donde Felix Engelmann explica ese formato para la aspiradora Proscenic 790T<\/a>, la cual parece ser la misma que la Conga 1490, y aunque pasa muy por encima del protocolo en general, s\u00ed explica en detalle c\u00f3mo funcionan los mapas, por lo que me ahorr\u00e9 el trabajo de descubrirlo por mi cuenta. Paso a limitarme a describir con mis palabras lo que explica ah\u00ed.<\/p>\n\n\n\n

{\n  \"version\": \"1.0\",\n  \"control\": {\n    \"targetId\": \"0\",\n    \"targetType\": \"6\",\n    \"broadcast\": \"0\"\n  },\n  \"value\": {\n    \"noteCmd\": \"101\",\n    \"clearArea\": \"0\",\n    \"clearTime\": \"10\",\n    \"clearSign\": \"2020-06-24-01-31-41-2\",\n    \"clearModule\": \"11\",\n    \"isFinish\": \"1\",\n    \"chargerPos\": \"8,12\",\n    \"map\": \"AAAAAAAAZABk0vwAaoDXAGpA1wBqgNcAqNL8AA==\",\n    \"track\": \"AQAEADIxMzExMTEy\"\n  }\n}<\/pre>\n\n\n\n
Aqu\u00ed hay tres elementos que nos interesan: los campos chargerPos<\/em>, map<\/em> y track<\/em>. Para entenderlos hay que saber primero que la aspiradora genera un mapa interno en forma de una cuadr\u00edcula, donde cada cuadrado que la compone puede estar en uno de varios estados (zona sin explorar<\/em>, zona libre<\/em> y obst\u00e1culo<\/em>).<\/p>\n\n\n\n
Tras hacer algunos c\u00e1lculos y ver c\u00f3mo trabaja la aspiradora, parece que cada elemento de la cuadr\u00edcula es un cuadrado de unos 20cm en el mundo real(tm)<\/em>. Esto es consistente con el modo area<\/em>, en el que la aspiradora va limpiando cuadrados de 2×2 metros (o sea, bloques de 10×10 cuadrados de la cuadr\u00edcula). Y como la aspiradora tiene un di\u00e1metro de 32cm, vemos que hay cierto solape, lo cual es perfectamente l\u00f3gico si queremos garantizar que aspire todo el polvo y suciedad. Por defecto, la cuadr\u00edcula que env\u00eda la aspiradora es de 100×100 elementos, lo que nos da un tama\u00f1o m\u00e1ximo de 20×20 metros para la casa, aunque tambi\u00e9n es cierto que el tama\u00f1o viene en la cabecera del bloque map<\/em>, por lo que supongo que en casas grandes lo ajustar\u00e1 din\u00e1micamente.<\/p>\n\n\n\n
El siguiente en complejidad es map<\/em>: es f\u00e1cil darse cuenta de que es una ristra de bytes codificado con base64<\/a>, por lo que lo primero que hay que hacer es convertirlo a bytes. En Javascript se puede hacer con atob<\/a>, y en Python con el m\u00f3dulo base64<\/a>. Una vez hecho esto, tiramos los primeros 4 bytes (que no sabemos qu\u00e9 significan), y luego cada par de bytes son las coordenadas x<\/em> e y<\/em> del recorrido de la aspiradora. As\u00ed, el primer par de bytes son las coordenadas del mapa en donde empez\u00f3 a limpiar, el siguiente par es la siguiente cuadr\u00edcula a la que se ha movido, etc. Dado que la cuadr\u00edcula, por defecto, es de 100×100, parece que no tendremos que preocuparnos de si son n\u00fameros en complemento a 2<\/a> (desde -128 hasta 127) o normales<\/em> (desde 0 hasta 255).<\/p>\n\n\n\n
El tercer campo es el m\u00e1s complejo, pues est\u00e1 comprimido utilizando una t\u00e9cnica Run-Length Encoding<\/a>, que, afortunadamente, es relativamente sencilla. Para ello tenemos que fijarnos en los dos primeros bits de cada byte. Si ambos est\u00e1n a 1, entonces es un contador de repeticiones y el n\u00famero de veces que se repetir\u00e1 el siguiente byte viene indicado por los seis bits inferiores. Ojo, porque si el siguiente byte tambi\u00e9n tiene ambos bits superiores a 1 entonces tambi\u00e9n se debe tener en cuenta para el n\u00famero de repeticiones, tomando los seis bits del primer byte y movi\u00e9ndolos seis posiciones a la izquierda, para luego anexionar los seis bits del segundo byte. Y as\u00ed sucesivamente, anexionando tantos bytes seguidos como haya con los dos bits superiores a 1. As\u00ed, si tenemos los bytes 0xC2 0xDA 0xAA, nos est\u00e1 diciendo que tenemos que repetir el byte 0xAA un total de 0x21A veces (0xC2 & 0x3F = 0x02; 0xDA & 0x3F = 1A).<\/p>\n\n\n\n