Provide bin state

[Hypfer]

Neither the local nor the cloud miio interface seem to provide a way to fetch the current Bin state.
It would be nice if the robot could report when the bin is removed/reinstalled/full/etc.

Since the robot does know about it, the data has to be somewhere. Is it handled by the player process? If yes maybe we could connect to its local socket and fetch the info from there?
Can we get it by sniffing the serial communication between OS and the STM32?
It could also be possible to just log read access onto the relevant wav files. Thats very hackish, though.

[cryptomilk]

I've also looked into that but haven't had the time to track down what triggers the sound files: bin_in.wav and bin_out.wav

[cryptomilk]

/opt/rockrobo/firmware/uart_test can figure it out via -g. It is part of the MCU status, however uart_test can't connect to the serial port, because that's in use by the player software. This means the player is informed about the bin state. Now the question is if we can query the player for the info.

[cryptomilk]

It looks like the BinCheck is implemented in /opt/rockrobo/cleaner/bin/RoboController this opens several pipes in /tmp/

lr-x------ 1 root root 64 Apr  5 17:44 10 -> /tmp/NvRc|
lr-x------ 1 root root 64 Apr  5 17:44 11 -> /tmp/ApRc|
l-wx------ 1 root root 64 Apr  5 17:44 12 -> /tmp/RcMc|
lr-x------ 1 root root 64 Apr  5 17:44 13 -> /tmp/McRc|
lr-x------ 1 root root 64 Apr  5 17:44 14 -> /tmp/UpRc|
l-wx------ 1 root root 64 Apr  5 17:44 15 -> /tmp/RcLg|
lr-x------ 1 root root 64 Apr  5 17:44 16 -> /tmp/LgRc|
l-wx------ 1 root root 64 Apr  5 17:44 17 -> /tmp/RcWd|
lr-x------ 1 root root 64 Apr  5 17:44 18 -> /tmp/WdRc|
l-wx------ 1 root root 64 Apr  5 17:44 19 -> /tmp/RcWm|
lr-x------ 1 root root 64 Apr  5 17:44 20 -> /tmp/WmRc|
l-wx------ 1 root root 64 Apr  5 17:44 21 -> /tmp/RcLr|
lr-x------ 1 root root 64 Apr  5 17:44 22 -> /tmp/LrRc|
l-wx------ 1 root root 64 Apr  5 17:44 23 -> /tmp/RcCs|
lr-x------ 1 root root 64 Apr  5 17:44 24 -> /tmp/CsRc|
l-wx------ 1 root root 64 Apr  5 17:44 28 -> /tmp/RcAp|
lr-x------ 1 root root 64 Apr  5 17:44 3 -> /tmp/RcWd|
lr-x------ 1 root root 64 Apr  5 17:44 4 -> /tmp/ApWd|
lr-x------ 1 root root 64 Apr  5 17:44 5 -> /tmp/McWd|
lr-x------ 1 root root 64 Apr  5 17:44 6 -> /tmp/UpWd|
lr-x------ 1 root root 64 Apr  5 17:44 7 -> /tmp/WmWd|
l-wx------ 1 root root 64 Apr  5 17:44 8 -> /tmp/RcNv|

I guess we have to figure out how to use them.

[cryptomilk]

The RoboController connects to the player on port 6665. You can subscribe to events and react on them. Maybe an strace can help to reveal what is sent over that connection.

[TheMicroDevil]

Would be great to know. My idea was to send the robot to a predefined spot, if dust bin is full, but could not find any information either.

My actual findings:

• Error code 9 => 'Dust bin missing'
• My workaround: Error code 9 followed by error code 0 = dust bin installed
• State 100 => 'Full', maybe this means 'dust bin full', but never saw this state.
• Removing dust bin while device is charging will not throw any error code (/api/current_status) but only trigger the sound files. So state 100 could probably be only seen, when device is not charging.

[hagenuck1]

I’ve just found out, that there is some kind of counter in /mnt/data/rockrobo/RoboController.cfg

Its „bin_in_time“ and I’ll try to find out in the next days how much it adds to this each clean.

Would be awesome to have this in the Valetudo UI and published by mqtt to HA, so we could send a notify from HA if the hin could be full. This time it was at 15989, when I cleaned it (looked very full, so cleaning was necessary).

When I inserted the cleaned bin it sets the value to „0“ within 10 seconds.

[cnrd]

I am pretty sure the value is cleaning time in seconds since last empty of bin.

I had a cleaning running for about 27 mins and the value is 1603

[Hypfer]

#17

[ADiea]

It looks like the BinCheck is implemented in /opt/rockrobo/cleaner/bin/RoboController this opens several pipes in /tmp/

lr-x------ 1 root root 64 Apr  5 17:44 10 -> /tmp/NvRc|
lr-x------ 1 root root 64 Apr  5 17:44 11 -> /tmp/ApRc|
l-wx------ 1 root root 64 Apr  5 17:44 12 -> /tmp/RcMc|
lr-x------ 1 root root 64 Apr  5 17:44 13 -> /tmp/McRc|
lr-x------ 1 root root 64 Apr  5 17:44 14 -> /tmp/UpRc|
l-wx------ 1 root root 64 Apr  5 17:44 15 -> /tmp/RcLg|
lr-x------ 1 root root 64 Apr  5 17:44 16 -> /tmp/LgRc|
l-wx------ 1 root root 64 Apr  5 17:44 17 -> /tmp/RcWd|
lr-x------ 1 root root 64 Apr  5 17:44 18 -> /tmp/WdRc|
l-wx------ 1 root root 64 Apr  5 17:44 19 -> /tmp/RcWm|
lr-x------ 1 root root 64 Apr  5 17:44 20 -> /tmp/WmRc|
l-wx------ 1 root root 64 Apr  5 17:44 21 -> /tmp/RcLr|
lr-x------ 1 root root 64 Apr  5 17:44 22 -> /tmp/LrRc|
l-wx------ 1 root root 64 Apr  5 17:44 23 -> /tmp/RcCs|
lr-x------ 1 root root 64 Apr  5 17:44 24 -> /tmp/CsRc|
l-wx------ 1 root root 64 Apr  5 17:44 28 -> /tmp/RcAp|
lr-x------ 1 root root 64 Apr  5 17:44 3 -> /tmp/RcWd|
lr-x------ 1 root root 64 Apr  5 17:44 4 -> /tmp/ApWd|
lr-x------ 1 root root 64 Apr  5 17:44 5 -> /tmp/McWd|
lr-x------ 1 root root 64 Apr  5 17:44 6 -> /tmp/UpWd|
lr-x------ 1 root root 64 Apr  5 17:44 7 -> /tmp/WmWd|
l-wx------ 1 root root 64 Apr  5 17:44 8 -> /tmp/RcNv|

I guess we have to figure out how to use them.

Hi

These pipes seem to be used for inter process communication between RobotController, Player and other processes.
If you use lsof you see exactly what processes have them opened it looks like the naming convention is this: first 2 letters from the Process/Thread for ex /tmp/RcNv would be from RobotController to Navigation thread which is in the player process.
The communication is binary probably not very hard to crack because we also have some pretty detailed logs for the RobotController

I was interested mainly in the /dev/ttyS2 file which is the uart comm with the MCU

I have spied a little today using strace. I wanted to better understand how everything works. Eventually I would like to make a script that spies on the communication and provides latest state data to a file in /run/shm/
Can valetudo pick it up from there if it's in json format and serve it through an api, would that be easy to implement?

888 is the PID of RoboController

root@rockrobo:~# lsof -p 888
COMMAND   PID USER   FD   TYPE     DEVICE SIZE/OFF    NODE NAME
RoboContr 888 root  cwd    DIR      179,8     1024   69204 /opt/rockrobo
RoboContr 888 root  rtd    DIR      179,8     1024       2 /
RoboContr 888 root  txt    REG      179,8   244496   69220 /opt/rockrobo/cleaner/bin/RoboController
RoboContr 888 root  mem    REG       0,18   204192    6006 /run/shm/SharedMapInfo
RoboContr 888 root  mem    REG      179,8    34536  100537 /lib/arm-linux-gnueabihf/libnss_files-2.19.so
RoboContr 888 root  mem    REG      179,8    30424  100631 /lib/arm-linux-gnueabihf/libnss_nis-2.19.so
RoboContr 888 root  mem    REG      179,8    55248  100621 /lib/arm-linux-gnueabihf/libnsl-2.19.so
RoboContr 888 root  mem    REG      179,8    22404  100602 /lib/arm-linux-gnueabihf/libnss_compat-2.19.so
RoboContr 888 root  mem    REG       0,18      368    6004 /run/shm/PersistInfo
RoboContr 888 root  DEL    REG        0,4           425997 /SYSV08010000
RoboContr 888 root  mem    REG       0,18     4096    2722 /run/shm/StateChange
RoboContr 888 root  mem    REG      179,8    75400  100446 /lib/arm-linux-gnueabihf/libz.so.1.2.8
RoboContr 888 root  mem    REG      179,8     9824  100628 /lib/arm-linux-gnueabihf/libdl-2.19.so
RoboContr 888 root  mem    REG      179,8   906980  100625 /lib/arm-linux-gnueabihf/libc-2.19.so
RoboContr 888 root  mem    REG      179,8   100012  100464 /lib/arm-linux-gnueabihf/libgcc_s.so.1
RoboContr 888 root  mem    REG      179,8   407136  100612 /lib/arm-linux-gnueabihf/libm-2.19.so
RoboContr 888 root  mem    REG      179,8   723396   68500 /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22
RoboContr 888 root  mem    REG      179,8  2226296   69244 /opt/rockrobo/cleaner/lib/libprotobuf.so.15.0.1
RoboContr 888 root  mem    REG      179,8    55480   69246 /opt/rockrobo/cleaner/lib/librobopersist.so
RoboContr 888 root  mem    REG      179,8     9656   69234 /opt/rockrobo/cleaner/lib/librrlocale.so
RoboContr 888 root  mem    REG      179,8     9780   69248 /opt/rockrobo/cleaner/lib/libpkginfoapi.so
RoboContr 888 root  mem    REG      179,8   119476   69155 /usr/lib/libconfig.so.9.1.3
RoboContr 888 root  mem    REG      179,8   596360   68472 /usr/lib/arm-linux-gnueabihf/libasound.so.2.0.0
RoboContr 888 root  mem    REG      179,8    22580  100632 /lib/arm-linux-gnueabihf/librt-2.19.so
RoboContr 888 root  mem    REG      179,8   102203  100613 /lib/arm-linux-gnueabihf/libpthread-2.19.so
RoboContr 888 root  mem    REG      179,8    44260   69229 /opt/rockrobo/cleaner/lib/libroboipc.so
RoboContr 888 root  mem    REG      179,8    22176   69251 /opt/rockrobo/cleaner/lib/librrlog.so
RoboContr 888 root  mem    REG      179,8   101684  100595 /lib/arm-linux-gnueabihf/ld-2.19.so
RoboContr 888 root  DEL    REG        0,4           851994 /SYSV08020000
RoboContr 888 root  mem    CHR      10,56             1126 /dev/jiffies
RoboContr 888 root  DEL    REG        0,4          5963958 /SYSV07000000
RoboContr 888 root    0r   CHR        1,3      0t0    1030 /dev/null
RoboContr 888 root    1w   REG      179,1   300824      16 /mnt/data/rockrobo/rrlog/watchdog.log
RoboContr 888 root    2w   REG      179,1   300824      16 /mnt/data/rockrobo/rrlog/watchdog.log
RoboContr 888 root    3r  FIFO       0,15      0t0    5462 /tmp/RcWd
RoboContr 888 root    4r  FIFO       0,15      0t0    2646 /tmp/ApWd
RoboContr 888 root    5r  FIFO       0,15      0t0    4396 /tmp/McWd
RoboContr 888 root    6r  FIFO       0,15      0t0    4411 /tmp/UpWd
RoboContr 888 root    7r  FIFO       0,15      0t0    2632 /tmp/WmWd
RoboContr 888 root    8w  FIFO       0,15      0t0    5459 /tmp/RcNv
RoboContr 888 root    9r   REG      179,8       92   69271 /opt/rockrobo/firmware/bin/MCU_FIRMWARE_MATCH
RoboContr 888 root   10r  FIFO       0,15      0t0    4373 /tmp/NvRc
RoboContr 888 root   11r  FIFO       0,15      0t0    4380 /tmp/ApRc
RoboContr 888 root   12w  FIFO       0,15      0t0    2557 /tmp/RcMc
RoboContr 888 root   13r  FIFO       0,15      0t0    4389 /tmp/McRc
RoboContr 888 root   14r  FIFO       0,15      0t0    2604 /tmp/UpRc
RoboContr 888 root   15w  FIFO       0,15      0t0    2558 /tmp/RcLg
RoboContr 888 root   16r  FIFO       0,15      0t0    4412 /tmp/LgRc
RoboContr 888 root   17w  FIFO       0,15      0t0    5462 /tmp/RcWd
RoboContr 888 root   18r  FIFO       0,15      0t0    1633 /tmp/WdRc
RoboContr 888 root   19w  FIFO       0,15      0t0    2559 /tmp/RcWm
RoboContr 888 root   20r  FIFO       0,15      0t0    4429 /tmp/WmRc
RoboContr 888 root   21w  FIFO       0,15      0t0    4368 /tmp/RcLr
RoboContr 888 root   22r  FIFO       0,15      0t0    2638 /tmp/LrRc
RoboContr 888 root   23w  FIFO       0,15      0t0    1590 /tmp/RcCs
RoboContr 888 root   24r  FIFO       0,15      0t0    4437 /tmp/CsRc
RoboContr 888 root   25u  unix 0xd90c04c0      0t0    6007 socket
RoboContr 888 root   26u   REG       0,18    20180 6958405 /run/shm/EVENTTASK_normal.log
RoboContr 888 root   27u   REG       0,18     4096    2722 /run/shm/StateChange
RoboContr 888 root   28w  FIFO       0,15      0t0    4365 /tmp/RcAp
RoboContr 888 root   29r   CHR      13,64      0t0    4103 /dev/input/event0
RoboContr 888 root   30u   REG       0,18        1    6005 /run/shm/IPC_normal.log (deleted)
RoboContr 888 root   31u   REG       0,18      368    6004 /run/shm/PersistInfo
RoboContr 888 root   32u   REG       0,18   204192    6006 /run/shm/SharedMapInfo

26 is file descriptor of /run/shm/EVENTTASK_normal.log
8 fd for /tmp/RcNv so Robot controller -> navigation
12 fd /tmp/RcMc --> Not sure what Mc is..possibly MCU thread in player
28 fd of pipe to ApplicationProxy

short sequence when going to spot (#./strace -p 888 -e trace=write,read,send -s 1024 -f -o /run/shm/robcontrl_strace)

write(26, "45223613 T888 SendEvent:1217 [stat] Sender: To = 2, Id = 156, Async = 0\n", 72) = 72
write(8, "\1\22\1\2\361\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 76) = 76

write(26, "45223620 T888 PlayLED:296 [stat] PlayLED enter\n", 47) = 47
write(26, "45223625 T888 SendEvent:1217 [stat] Sender: To = 4, Id = 80, Async = 0\n", 71) = 71
write(12, "1\0\1\4\362\1\0\0\20\0\0\0\10\1\4\0\0\0\0\0\0\0\377\377\5\0\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 76) = 76

write(26, "45223630 T888 PlayLED:335 [stat] Sent ChangeLED to player: LED value=00040108, 00000000, FFFF0000, FFFF0005\n", 108) = 108
write(26, "45223638 T888 SendEvent:1217 [stat] Sender: To = 2, Id = 55, Async = 0\n", 71) = 71
write(8, "2\0\1\2\363\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 76) = 76

write(26, "45223643 T888 pDoFreshSpot:855 [stat] Sent Spot to Nav\n", 55) = 55
write(26, "45223649 T888 main:1495 [stat] State transit from [Standby] to [Spot]\n", 70) = 70

send(25, "\3\1\10\0\1\v\0\2\1-lM]\3\v\0\0", 17, 0) = 17

write(26, "45223654 T888 PegStateChangeStat:295 [stat] PegStateChangeStat: StartTime=1565355053, PreState=3, NextState=11\n", 111) = 111
write(26, "45223657 T888 SendEvent:1217 [stat] Sender: To = 3, Id = 262, Async = 0\n", 72) = 72
write(28, " \3\1\3\364\1\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 76) = 76

Looks like these are IPC messages, byte 3 seems to be adress of the process/thread(2=navigation thread, 28=application proxy)

So by making some tests from "dock" to "spot" to "start full cleaning" etc we could guess all the missing bits and pieces

Now for the player process, I was more interested in the /dev/ttyS2 since that is the uart of the mcu. What's weird is that it only writes to that, of course binary data, difficult to understand but we could probably disable the player in watchdog and play around with uart_test to see the patterns then try to match for player

(57 is the fd for ttyS2)

846   write(57, "\252\22\1\320\2\0\377\300\f\0\0\0\0\0\0\0\0\1\0\0\0\271", 22) = 22
846   write(57, "\252\22\2\320\2\0\1\300\f\0\0\0\0\0\0\0\0\1\0\0\0\251\1", 23) = 23
846   write(57, "\252\22\1\320\2\0\2\300\f\0\0\0\0\0\0\0\0\1\0\0\0003", 22) = 22

This being said, using strace (with the cost of some performance drop?) we could spy on the communication of the sensors etc. Probably we will not be able to inject data into the MCU stream, not sure if possible with strace