My Roomba632 class kinda works but still has some issues:

- Roomba doesn't respond to commands reliably;

- Reading datastream fails; 

These are the 2 things it was designed for, but I refuse to call it a failure. It's a "work in progress".

One of the problems with troubleshooting and debugging is the lack of feedback. Sending a command works, or doesn't work. But I can't see where the code breaks down. 

Does the request for a datastream actually start a datastream? Or does my interpretation of the data fail?

Luckily I have a separate ESP8266 set up on a breadboard. I can connect this to the computer and use the computer as a stand-in for the roomba.

This gave me some AHaH!-moments. Most of them already taken care of in the previously posted code. For instance:

• A waaaay to complicated state machine with too many copies of mostly the same code. Transition changes are now in their own function;
• Because of all the copies, I didn't notice I was sending the same opcode for all commands. Big DOH!;

When I was confident I was sending out the proper commands in the proper order I connected the roomba for even MORE troubleshooting:

First I connected the roomba on it's own to the computer to check its responses to the commands I had lined up.

Then I connected the breadboard-ESP8266 to the Rx of the roomba and the Tx of the roomba to the computer.  This way I could check if the datastream would start and stop on command. 

And then I had my second round of AhAH!-moments:

Datastream:

I was expecting something with a header of '19' then '16' for the number of databytes, 16 databytes and a byte for the checksum at the end.

What I got was:

19 26 15 0 22 62 159 23 254 246 24 27 25 10 129 26 10 136 35 2 37 0 43 0 5 44 0 2 155 
19 26 15 0 22 62 159 23 254 246 24 27 25 10 129 26 10 136 35 2 37 0 43 0 5 44 0 2 155 
19 26 15 0 22 62 159 23 254 246 24 27 25 10 129 26 10 136 35 2 37 0 43 0 5 44 0 2 155 
19 26 15 0 22 62 159 23 254 246 24 27 25 10 129 26 10 136 35 2 37 0 43 0 5 44 0 2 155 
19 26 15 0 22 62 159 23 254 246 24 27 25 10 129 26 10 136 35 2 37 0 43 0 5 44 0 2 155 

Why 26 bytes?? Rereading the docs closely makes me feel stoopid, again! The ID's are also sent with the datastream preceding the databytes. So above stream translates to:

[19] Message header

[26] Number of total bytes before checksum

[15] Packet ID for "dirt detect"

[0] Databyte for "dirt detec". No dirt detected.

[22] Packet ID for "battery voltage"

[62] Most significant data byte for "battery voltage"

[159] Least significant data byte for "battery voltage"

*

*

[44]  Packet ID for "Wheel encoder counts right"

[0] Most significant data byte for "Wheel encoder counts right"

[2] Least significant data byte for "Wheel encoder counts right"

[155] Checksum. 

All bytes including header and checksum added together without rollover, gives 0;

Timing:

This setup also showed me I need a short delay after sending a "start" and after a "set mode" command. 

I can't find any documentation on these delays, but the 20ms seems to work fine.

More more troubleshooting:

The ESP8266 only has 1 serial port. To get more feedback from the code I sprinkled some commands to set variables that I can request through MQTT.  This way I can check which state the code reaches and what bytes it receives.

Apparently It only receives 1 byte, which seems a bit random. 

It appears to be only the last byte of a stream because all the previous bytes are handled and discarded. And after much thinking I came to the conclusion it was the "Wake up" message that was handled... The datastream isn't starting for some reason.

Back to the breadboard and upload the code to see if the command to start the stream is handled correctly. And it wasn't! So the problem is manageable!

I made a mistake when putting in another state in the state machine to send the command to start the stream with a delay. I never transitioned from that state because I forgot to set it like this:

datastreamState = datastreamStarting;

Instead it was set to it's own case by: 

datastreamState = datastreamSetMode;

 So .. problem found??

I checked by manually feeding some dummy streamdata I captured earlier from the roomba to the breadboard setup. This worked! So feeling confident I uploaded the new code to the roomba setup and BEHOLD!!!

What we see here is messages with the actual battery voltage: 16.949V and current -203mA draw when Idle to -1117mA when cleaning.

These values update about 60 times / second on the ESP8266. From there I can combine them with sensordata from the IMU for instance or use it to make world peace.

I will call this a succes and upload the library I have so far.

Next up: changing the power configuration and adding the IMU somewhere in the roomba.