Greg's Scratchpad Thread on Roomba Comm Hacking

[gssincla]

EDIT: WHAT YOU DO WITH THIS IS YOUR OWN BUSINESS. THIS IS NOT PART OF THE iROBOT SPECS. DOING ANY OF THIS COULD HAVE THE FOLLOWING AFFECTS:

1) VOID WARRANTY
2) REALLY ANNOY YOUR SIGNIFICANT OTHER
3) CAUSE YOUR ROOMBA TO COMMIT SUICIDE BY RUNNING UNDER YOUR CAR

THIS IS SOLELY FOR YOUR INFORMATION AND BETTER UNDERSTANDING OF HOW THINGS WORK. YOU HAVE BEEN WARNED

(Sorry, had to put my legal disclaimer in there)

Ok, this thread is my way of showing what I know at any given point in time about the comm traffic between the roomba and OSMO. If you see anything I'm missing, anything I've gotten completely wrong or have thoughts of your own, please feel free to throw them in here. :D

so far i've been able to toy with the roomba to make it produce the date key that rj5555 found in his thread on serial communciation (http://www.robotreviews.com/chat/viewto ... t&start=60). I think I have a basic idea of what is going on, so let me see if the group agrees...

The simulation goes like this...

1) power up the roomba (update commands dont seem to work on an off roomba) ... either manually power it up or toggle DD

2) send the following string:

<CRLF><CRLF>contains 1 image(s):<CRLF>
1: roomba DG256 2005-08-11-1007<CRLF><CRLF><CRLF><08>

where <08> is Chr(08) in VB.NET

3) the roomba will reply with

0 0x12(18)
1 0x5(5)
2 0x8(8)
3 0xB(11)
4 0x11(17)
5 0x7(7)
6 0x10(16)

(thats my program's output.. the string is actually 18 5 8 11 17 7 16 in decimal)

this seems to break down into
byte 0: magic byte? header byte?
byte 1: date code year (2 digit)
byte 2: data code month (2 digit)
byte 3: data code day (2 digit)
byte 4,5: revision number (???) 4 digits
byte 6: packet end byte? checksum? options bits?


now an interesting variation on a theme is that if you send TWO Chr(8) bytes as done in the referenced post you get the reply TWICE! ...

so it looks like 8 is the command to return the current version of the firmware. To test this, I sent:

<CRLF><CRLF><CRLF><08>

this gives me the exact same reply as before. It seems that the three <CRLF> puts the system into command mode and any bytes sent after that are the command packets.

So using this, I went from 0 to 255 to see how many one byte command there were and what they did... i only found 2... 0x07 and 0x08.

These commands are
7: reset system
8: get firmware version

The interesting thing about #7 is that on my disco it gives me

bl-start
2004-08-31-1548-L
Roomba by iRobot!
MC9S12E128
2005-08-11-1707-L
battery-current-quiescent-raw 535 battery-current-zero 521

whereas doing a cold reset (removing battery and putting it back in) gives me

?bl-start
2004-08-31-1548-L
Roomba by iRobot!
MC9S12E128
2005-08-11-1707-L
battery-current-quiescent-raw 535 battery-current-zero 521

The difference being the first character... so I'm going to call this a soft-cold reboot.

Once I get my OSMO I suspect I'll find that the flash command is probably a multibyte command that operates pretty much like what I outlined above.[/b]

[vic7767]

Really good effort gssincla. Hope the wedding doesn't take too much of your time. lol

[gssincla]

Thanks for the kind words and support vic. And nope, the wedding is months away... this keeps me busy and out of Shilpa's (my wife-to-be) way.


I found that if you send a command that isn't recognized, it will simply ignore the value. This can be proven by sending the following string

<crlf><crlf><crlf><06><08><07>

where <0x> is the Chr(x) value...

this will give you the following output...

Code: Select all

bl-start
2004-08-31-1548-L   
Roomba by iRobot!
MC9S12E128
2005-08-11-1707-L   
battery-current-quiescent-raw 535  battery-current-zero 521
device-detect
2005-08-11-1707-L   

the "" is the date version information. since we know that 0x08 is the date-version packet and 0x07 will reset the the roomba, its fair to say that 0x06 isn't a valid command. using this technique, I found the following to be POSSIBLY valid commands IDs....

Code: Select all

0x01: diagnostic mode? system monitor interface?
0x07: reset roomba
0x08: get FW version

A little more experimentation reveals that you don't even need to enter "command mode" by supplying the three <crlf>... simply issuing the command packet (ie. <07> or <08>) will execute the command.


So far I've found the following sub commands of command 0x01
[any byte labeled as <x> means that any value can be inserted]

Code: Select all

0x0 <x> <x> - sends a stream of data (requires reset to end.. simply hitting power just pauses the stream)
0x1 <x> <x> - puts the processor to sleep (requires RTS toggle to wake up)
0x2 <x> <x> - enters diagonistic mode 0 ("flash LEDS, wait false")
0x3 <?> <?> - flashes "dirt detect" (only works AFTER 0x1 0x2 <x> <x> is engaged) -- UNKNOWN FUNCTION

so far i havent found any subcommands above 0x2...

at one point i did get it to do the bootloader test but havent been able to recover the keysequence that caused that. once i find it, i'll post it.

greg.

[gssincla]

This is a bit of a random observation....

When I send the command to do the LED flash diagnostic and follow it immediately with the Get Date Code command, the data code comes back BEFORE the diagnostic header. Any ideas why?

Also, sending 0x0 0x0 as the "anything" valids does not illict the diagnostic response.

Code: Select all

Sending command 1 with 3 subpackets
Packet:  0x1 0x2 0x0 0x0 0x8
Sending command 1 with 3 subpackets
Packet:  0x1 0x2 0x0 0x1 0x8


factory-test 0  leds
wait: false

[gssincla]

More randomness....

if you have the system in "process sleep" and you wake it via a keypress, the result code will indicate which key actually made the system wake up.

Code: Select all

key-wakeup 1000000000000000	-- wake up via Mode buttons (clean, max, spot)
key-wakeup 0100000000000000	-- wake up via device-detect (RTS)
key-wakeup 0000000000000100	-- wake up via charger being engaged
key-wakeup 0000000000000010	-- wake up via remote buttons
key-wakeup 0000000000000001	-- wake up via Power Button

I did have one outlier... once when i pressed the power button i got the following:

Code: Select all

 
key-wakeup 0000000001000001

After some testing, I found that this happens when the front wheel is off the ground. so it looks like what is being shown is a bitmask. Of the 16 bits (WORD) 6 have been assigned values (see below). Taking a look at the the pin outs on http://prj.perquin.com/roomba/uc.php, these actually match up pretty close to the pin outs for register H .. well, with the exception of the 2 MSB. The high values, especially Bit15, could be the result of an interrupt call (hence the fact that all three mode buttons give the same key-wakeup)

Code: Select all

bit 15: mode button pressed
bit 14: device-detect
bit 13:
bit 12:
bit 11:
bit 10:
bit  9:
bit  8:
bit  7:
bit  6: front wheels-up
bit  5:
bit  4:
bit  3:
bit  2: charger engaged
bit  1: remote (IR) buttons pressed
bit  0: power button pressed

And as a side note, if you press the power button to wake up the system, it WILL NOT display the key-wakeup sequence until AFTER you have released the button. This is the only key that does this... leading me to believe more in the theory that the mode buttons are masked together via an interrupt when it comes to the key-wakeup sequence.

hhehe, at this rate, we'll have the whole maintenance manual for the roomba figured out next week

[gssincla]

Back a few posts I mentioned the fact that in the case of the diagnostic code that if you send the diagnostic code followed by the get-version command the date-code is printed first. To further test this, I sent the string <1> <2> <2> <2> <4> <5> <6> <7>. This resulted in

Code: Select all

Sending command 1 with 7 subpackets
Packet:  0x1 0x2 0x2 0x2 0x4 0x5 0x6 0x7


factory-test 0  leds
bl-start
2004-08-31-1548-L   
Roomba by iRobot!
MC9S12E128
2005-08-11-1707-L   
battery-current-quiescent-raw 535  battery-current-zero 521

2005-08-11-1707-L   

processor-sleep

Since commands <4> <5> and <6> are the roomba equivalent to NOPs, the roomba saw "do diagnostic" <pause> "reboot".

Now why is this important or the least bit interesting? Well, it shows us how the command pipeline operates... enough to let us make some basic assumptions (this will come in handy later when we disassemble).

since the diag command was already engaged, the fact that the reset command executed shows the following:

1) the serial is interrupt driven
2) the command pipeline is pre-emptive

Another interesting behavior involves the use of command packets and the device-detect signal. Sending the following sequence:

RTS.0, 0x08, RTS.1, 0x08, RTS.0

(with RTS.X indicating the state of the RTS signal -- either 1 [on] or 0 [off])

produces the the following reply:

Code: Select all

device-d2tect
005-08-11-1707-L 

notice that the command packets are both processed before the RTS is handled. Since this might be a fluke of the testing PC, I expanded the sequence to give the computer additional time to process the RTS request... so sending this sequence:

RTS.0, 0x08, 0x8, RTS.1, 0x8, 0x8, 0x08, RTS.0

produces this result:

Code: Select all

device-dete2t
005-08-11-1707-L

This shows that the serial processing for command packets take absolute precedence of the device-detect signal (in other words, the serial interface has a lower interrupt number than the DD line). From this we can build the hierarchy of exemptions for the roomba. From highest priority to the lowest priority, we have:

Code: Select all

- serial comm processing
- command processing
      - reset command
      - other commands
- device-detect response

ok, i'll admit at this point in the game this is all theory and not very useful to actual application.. but this should come in handy later on when we start developing our own firmware mods. so to the group I say thank you for humoring me

[gssincla]

For those who are interested, I've upload the rar file of my test bed program. This is the program I've been using to do the tests above.

(EDIT: new version uploaded. use this link)
http://rapidshare.de/files/28588345/rs232.rar.html

or

NO SCI ROOMBA HACK (Hosted by RoombaReview.com)

This is code based off the RS232 package found at http://www.codeworks.it/net/VBNetRs232.htm

Again, no warranties, etc on this code. its a use at your own risk.

you'll need to change the com port to match your set up.

EDIT: README

By request, here's a quick readme on how the program works....

With the exception of the "close" and Open Comm buttons, all of the controls to the left of the separator box can be ignored... these are original to the RS232 sample program that I ripped from.

First thing you need to do is to specify which port you are using your roomba on. If you are using COM1, just enter the number 1. Once you have specified the comm port, click the Open Comm button to engage. This has ONLY been tested on a roo232 interface. The rooStick might work, but i'm pretty sure the rooToothwill not without additional coding... lots of additional coding.

The roomba toys are in the box on the right side of the program's interface. There are two windows of importance: Hex View and ASCII view... both of these show the output from the roomba but in different formats. The Hex view will show the data stream as both a hex character and its decimal equiv in parathesis. The ASCII view will show the data stream without any interpretation.... so if the byte isn't printable, you'll get the square/box icon.

There are 5 dials on the interface for manipulating the data input to the roomba. CMD is the first byte to be sent. if you want trailing bytes, then adjust the number in the "Trailing Pkts" box. If you specify a number less than 4 but greater than 0 (ie. 1-3) you can adjust what is sent after the cmd byte by using the subPacketX dials. If you put 2 in the Trailing field, then subpacket0 and subpacket1 will be sent, for example.

if you want to send more than 3 additional bytes, the additional bytes will be an increment equal to their position in the streams starting from 0. In plain words, this means that the 5th byte will be 4, the 6th byte will be 5, and so on. Be warned that this means the 8th byte will be 7 and thus will cause a reboot of the roomba (typically).

Once you have your packet read to send, click the Send Raw Cmd button to send the packet as you specified.

To make testing easier, you'll notice that each of the command/subcommand dials has a button beside it that says "inc and send"... what this will do is adjust the corresponding dial by 1 and send the packet. So if you have 45 in the subPacket2 field and you click that "inc and send" button, the packet will take the form of

<cmd> <subpacket0> <subpacket1> 46 (where the <...> represent the values in the dials for those particular settings).

There are a few special buttons on the screen. Send Wake up will toggle the RTS line to force a device detect.

reset disco will send <7>.

get version will send <8>.

sleep will send <1> <1> <1> <1>.

Clear Windows will clear both the Hex View and ASCII view windows of any content and reset the stream counter.

The send header check box will send <crlf> <crlf> <crlf> before the command packet you specify

Trail with GetVersion will add <8> to the end of the packet you build

Trail with Reset will add <7> to the end of the packet you build. If both GetVersion and Reset are selected, GetVersion will be send followed by Reset.

Special Test Cmd is a button I used for testing special cases. It doesn't really add much to the party right now.

Let me know if you have any questions.

greg.

[gssincla]

VERSION PACKET ANALYSIS

Thanks to vic7767 I'm now able to do some additional analysis on the version packet (command 0x08). From the Roomba Red with 256K, the version code returns:

Code: Select all

0 0x12   (18)
1 0x5    (5)
2 0xA    (10) 
3 0x4    (4)
4 0xD    (13) 
5 0x8    (8)
6 0xE    (14)

Like before, bytes 1 through 5 represent the date-code. Byte 0 remains at 0x12. So it is safe to say that 0x12 is simply the magic byte (or header) for the packet

The interesting value is 0xE at byte 6. Since the datestamp for this particular roomba is 2005-10-04-1308-L, it is safe to say that byte 6 and the last letter of the packet are not related.

This leaves to readily available theories to the magic byte 6:

1) the byte represents the model of the device

or

2) the byte represents the processor type (128 or 256k).

Thanks again to Vic I have another Roomba Red to look at.. this time with 128K. The output for this model gives

Code: Select all

0 0x12   (18)
1 0x5    (5)
2 0xA    (10)
3 0x4    (4)
4 0xD    (13) 
5 0x8    (8)
6 0xE    (14)

So theory two is out. Since both the 128K and the 256K version both have 0xE as the 7th byte, then this byte is definitely not differentating between the processor models.

So this leaves me with the roomba model theory. Once I get another model to check, I'll be able to update this.

Again, I want to say thank you to Vic for his help with the testing!!!

------------------------
getVersion Packet Format:

Byte 0: Header (= 0x12)
Byte 1: 2 digit Year
Byte 2: Month
Byte 3: Day
Byte 4: Hour
Byte 5: Minute
Byte 6: ... (to be determined: probably model)

[gssincla]

Now that I have an OSMO to test with (thanks Vic!) and I've built the OSMO interface, it's time to get down to OSMO Communcations 101.

STAGE 0: Print OSMO Info
The first thing you'll notice when you hook up the OSMO to your terminal is that it produces a banner identifying what firmware its carrying. That's great, but not important so moving on...

STAGE 1: Finding Roomba FW Version
The OSMO will then attempt to query the roomba for its firmware version by sending the 0x08 command. It will do this up to 10 times trying to get a valid response. A valid response, in terms of the OSMO, is a reply that matches some pre-determined pattern. (No, i've not figured out the pattern yet... it has something to do with the last byte... but not sure how it works yet.)

At this point if the OSMO gets a version that is the same or newer than the firmware contained on the OSMO it will shut down all communication and the game is effectively over.

If the OSMO never receives a version packet that it likes, after the 10th attempt the OSMO will simple skip to the next stage in the protocol. (see below). I suspect this is an attempt by the designers to prevent a roomba from becoming a brick as the result of a bad firmware upgrade... like if someone removes the OSMO too soon or the battery falls out in the middle of an update. If the version packet isnt correct the OSMO assumes a problem and begins flashing the firmware as a safety precaution.This is something you could use to your advantage if you wanted to downgrade your firmware. Simply disconnect the RX line for the duration of the 10 version requests and reattach it at the time of the next step and the OSMO will blindly flash the firmware.

STAGE 2: ... not sure what this is yet
But lets say that the OSMO gets a version that is older than the firmware on the device... at this point the OSMO will send out a series of packets with the following format

07 01 04 Z Y X W V U

(where Z->U are parameters of seemingly random values... but i'll get back to this in a second)

The roomba will do the following with this set of bytes:

1) 07 will reset the roomba

2) within milliseconds of the reboot, even before the bootloader has totally finished, the roomba will reply with

Code: Select all

06 05 04 04 00 27 3
06 05 04 Z  00 27 3
06 05 04 Y  00 27 3
06 05 04 X  00 27 3
06 05 04 W  00 27 3

3) the OSMO will repeat these commands over and over, each time with a different set of values for the parameter fields. After the 64th such packet, the entire set of values will repeat.. thus, if the first packet had the values 1 4 3 3 3 3 3 3 then the 65th packet will have 1 4 3 3 3 3 3 3.

There are three exceptional packets values that appear from the OSMO... exceptional in that they are larger than the standard packets. These packets are:

Code: Select all

070104933B80005E66E0
0701040F8087C3A988AB
0701044008E5E8539B3C76657273696F6E3E
070104738090353C81FF

So far I've not been able to figure out how the roomba knows that these packets will take additional parameters instead of the standard 6. However, the roomba reply is consistent with the above mentioned response pattern.

At this point I'm attempting to simulate the roomba's response to the OSMO so I can determine what the next step of the protocol is.

It is worth noting that there is the possibility that the packets with the extra parameters might not be any different the than rest. Recall from earlier that I stated that unknown packet values are ignored by the roomba. So in essence, these could be placeholder bytes or NOPs in assembly terms. My simulator for instance will just ignore them. There is also the possibility that these values (again, acting as NOPs) are used to ensure timing capability. Since there is no flow control line between the OSMO and the roomba, these extra bytes could be used to waste time to let the system finish processing the previous bytes.

Speaking of the simulator... once I get it to do something useful, I'll post here with the help of THX.

Below is the full set of 64 packets sent in Stage 2. Remember that after the 64th sequence, the sequence starts again at the first sequence.

Code: Select all

0701042F11CF1C7352
07010465245FE7FDD3
07010478C003CE63E3
070104F9E6C43A99C3
070104C9C7B87F873C
070104933B80005E66E0
0701044F49CA8295B7
070104BFA304F4CF32
07010428D4E9C8FA0A
07010463AAA109EBD0
07010430887D67F6B0
070104064EFBF2A365
0701045AB5B60A8D17
0701041A0E798DA169
0701049BFA59051F69
070104317AEE9E3FF1
07010492ED9FEB95E6
07010457443F37BA79
070104D02776892F88
0701048E7B3EAFE72C
070104FD132045A102
07010422B4B796701A
0701048F19E1BC7FA5
0701046FF04243228F
070104693253585E92
0701040C488AC6BC96
0701040F8087C3A988AB
0701044008E5E8539B3C76657273696F6E3E
0701044B2A7E7CD676
0701046AB36146F0B5
070104A0E095AD480C
0701049C6487C5A30D
07010423BD368306E4
0701046DFCFEDA4000
0701041FAE1DEA5195
070104DD2BB070D8C6
07010400EFA4561D0F
070104D22ED9CC6105
070104472925D37F56
0701040BF894D6D351
070104F35BA51BF0D5
0701041E01CD330306
0701048C1516A72F52
070104684A4D216223
07010498D777ECE989
070104A6F7A897420E
070104738090353C81FF
070104B2F50D51B271
0701042DABBE5498BF
07010481385260C9F3
070104758BDCAC5D92
07010402DF6E90E5AA
0701041491E49AD83D
07010417E266861197
07010462E3BBF18CBD
0701042650F6C2939A
0701049918B1BA28EC
070104DBCBDED84E8A
070104122C39B90027
07010472A27455B47C
070104D5415C5D45A8
0701044CC13D6B2218
070104349D858403E0
070104D1FF6C71F47C

[THX-1138]

Is this Roomba's equivalent of the 'Rosetta Stone' ? Good progress! Send me a PM when you have the sim ready.

[gssincla]

I'll be the first one to admit when I have made a wrong assumption... I think I might have made a mistake in Stage 2. When I was testing I was sending the packet after the reboot had cycled through too far.

I'm still stuck on the 07 01 04 sequences. I took the entire 64 sequence block and ran it through my roomba. i matched the OSMO timing. now i'm getting an entirely different response (not the 06 05 04... response, but now 10 02 06). (see below). Using the OSMO's timing and sequences, I seem to be getting a response once every three sequences from the roomba. I need to confirm this, however. Unfortunately when I sent the block out via my program it locked up the main thread so the RX buffer just filled up and once the TX thread was finished it dumped to the output. So the correlation between the two is a bit hit and miss.

What I think is happening though is that the firmware is updated through the bootloader!!! not the running firmware . This would make sense since if the firmware was screwy, you'd have to drop back to the bootloader. My guess is that between the time the first header is sent:

Code: Select all

bl-start
2004-08-31-1548-L 

And the time the second header is sent

Code: Select all

Roomba by iRobot!
MC9S12E128
2005-08-11-1707-L   
battery-current-quiescent-raw 535  battery-current-zero 521

you are in the bootloader exclusively. once the second header comes up you are in the running firmware and thus a completely different set of commands. So i'm guessing (i seem to be guessing a lot, huh?) that the commands i'm seeing right now are trying to engage some sort of ROM monitor (bootloader interface). The responses I'm getting now are being sent after the datecode's <crlf> in the bootloader and immediately before the R in "Roomba by iRobot!"


(output... whitespaces added by me for clarity)

Code: Select all

10 02 06   65 24 5F E7     51 00   E0 9E 
10 02 06   C9 C7 B8 7F     51 00   26 86 
10 02 06   BF A3 04 F4     51 00   5D F5 
10 02 06   30 88 7D 67     51 00   E4 80 87
10 02 06   1A 0E 79 8D     51 00   B0 36 
10 02 06   92 ED 9F EB     51 00   7D 0E 
10 02 06   8E 7B 3E AF     51 00   00 61 
10 02 06   8F 19 E1 BC     51 00   4D E0 
10 02 06   0C 48 8A C6     51 00   B6 BB 
10 02 06   4B 2A 7E 7C     51 00   06 47 
10 02 06   9C 64 87 C5     51 00   98 DD 
10 02 06   1F AE 1D EA     51 00   67 E7 
10 02 06   D2 2E D9 CC     51 00   F6 DC 
10 02 06   F3 5B A5 1B     51 00   94 55 
10 02 06   68 4A 4D 21     51 00   48 12 
10 02 06   73 80 90 35 3C  51 00   56 C6
10 02 06   81 38 52 60     51 00   2C 9B 
10 02 06   14 91 E4 9A     51 00   CD 63 
10 02 06   26 50 F6 C2     51 00   0F 03 
10 02 06   12 2C 39 B9     51 00   44 4E 
10 02 06   4C C1 3D 6B     51 00   8B 66 

if you want to modify your copy of the program to try the 64 sequence, create a button called "sendOSMOStageTwo" and add the following lines of code:

Code: Select all

  Private Sub pauseAndReset(ByVal delay As Integer)
        update_tbASCII(">resetting<")
        moRS232.Write(Chr(7))
        System.Threading.Thread.Sleep(delay)

    End Sub
    Private Sub sendOSMOStuff(ByVal command As String)
        Dim specialPacketDetail As String = ""
        Static commandCount As Integer = 0
        Dim valueI As Integer
        Dim indexer As Integer

        For indexer = 0 To command.Length - 1
            valueI = Convert.ToInt16(command(indexer))
            specialPacketDetail += String.Format(" 0x{0}", valueI.ToString("X"))
        Next

        update_tbASCII("[sending stage 2 packet " & commandCount & " : " & specialPacketDetail & "]" & vbCrLf)
        tbHex.AppendText("[sending stage 2 packet " & commandCount & " : " & specialPacketDetail & "]" & vbCrLf)
        pauseAndReset(20)
        update_tbASCII(">sending command<")
        moRS232.Write(command)
        System.Threading.Thread.Sleep(980)
        update_tbASCII(">command sent<")

    End Sub
    Private Sub sendOSMOStage2()
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H2F) & Chr(&H11) & Chr(&HCF) & Chr(&H1C) & Chr(&H73) & Chr(&H52))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H65) & Chr(&H24) & Chr(&H5F) & Chr(&HE7) & Chr(&HFD) & Chr(&HD3))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H78) & Chr(&HC0) & Chr(&H3) & Chr(&HCE) & Chr(&H63) & Chr(&HE3))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HF9) & Chr(&HE6) & Chr(&HC4) & Chr(&H3A) & Chr(&H99) & Chr(&HC3))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HC9) & Chr(&HC7) & Chr(&HB8) & Chr(&H7F) & Chr(&H87) & Chr(&H3C))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H93) & Chr(&H3B) & Chr(&H80) & Chr(&H0) & Chr(&H5E) & Chr(&H66) & Chr(&HE0))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H4F) & Chr(&H49) & Chr(&HCA) & Chr(&H82) & Chr(&H95) & Chr(&HB7))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HBF) & Chr(&HA3) & Chr(&H4) & Chr(&HF4) & Chr(&HCF) & Chr(&H32))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H28) & Chr(&HD4) & Chr(&HE9) & Chr(&HC8) & Chr(&HFA) & Chr(&HA))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H63) & Chr(&HAA) & Chr(&HA1) & Chr(&H9) & Chr(&HEB) & Chr(&HD0))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H30) & Chr(&H88) & Chr(&H7D) & Chr(&H67) & Chr(&HF6) & Chr(&HB0))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H6) & Chr(&H4E) & Chr(&HFB) & Chr(&HF2) & Chr(&HA3) & Chr(&H65))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H5A) & Chr(&HB5) & Chr(&HB6) & Chr(&HA) & Chr(&H8D) & Chr(&H17))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H1A) & Chr(&HE) & Chr(&H79) & Chr(&H8D) & Chr(&HA1) & Chr(&H69))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H9B) & Chr(&HFA) & Chr(&H59) & Chr(&H5) & Chr(&H1F) & Chr(&H69))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H31) & Chr(&H7A) & Chr(&HEE) & Chr(&H9E) & Chr(&H3F) & Chr(&HF1))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H92) & Chr(&HED) & Chr(&H9F) & Chr(&HEB) & Chr(&H95) & Chr(&HE6))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H57) & Chr(&H44) & Chr(&H3F) & Chr(&H37) & Chr(&HBA) & Chr(&H79))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HD0) & Chr(&H27) & Chr(&H76) & Chr(&H89) & Chr(&H2F) & Chr(&H88))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H8E) & Chr(&H7B) & Chr(&H3E) & Chr(&HAF) & Chr(&HE7) & Chr(&H2C))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HFD) & Chr(&H13) & Chr(&H20) & Chr(&H45) & Chr(&HA1) & Chr(&H2))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H22) & Chr(&HB4) & Chr(&HB7) & Chr(&H96) & Chr(&H70) & Chr(&H1A))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H8F) & Chr(&H19) & Chr(&HE1) & Chr(&HBC) & Chr(&H7F) & Chr(&HA5))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H6F) & Chr(&HF0) & Chr(&H42) & Chr(&H43) & Chr(&H22) & Chr(&H8F))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H69) & Chr(&H32) & Chr(&H53) & Chr(&H58) & Chr(&H5E) & Chr(&H92))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HC) & Chr(&H48) & Chr(&H8A) & Chr(&HC6) & Chr(&HBC) & Chr(&H96))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HF) & Chr(&H80) & Chr(&H87) & Chr(&HC3) & Chr(&HA9) & Chr(&H88) & Chr(&HAB))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H40) & Chr(&H8) & Chr(&HE5) & Chr(&HE8) & Chr(&H53) & Chr(&H9B) & Chr(&H3C) & Chr(&H76) & Chr(&H65) & Chr(&H72) & Chr(&H73) & Chr(&H69) & Chr(&H6F) & Chr(&H6E) & Chr(&H3E))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H4B) & Chr(&H2A) & Chr(&H7E) & Chr(&H7C) & Chr(&HD6) & Chr(&H76))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H6A) & Chr(&HB3) & Chr(&H61) & Chr(&H46) & Chr(&HF0) & Chr(&HB5))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HA0) & Chr(&HE0) & Chr(&H95) & Chr(&HAD) & Chr(&H48) & Chr(&HC))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H9C) & Chr(&H64) & Chr(&H87) & Chr(&HC5) & Chr(&HA3) & Chr(&HD))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H23) & Chr(&HBD) & Chr(&H36) & Chr(&H83) & Chr(&H6) & Chr(&HE4))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H6D) & Chr(&HFC) & Chr(&HFE) & Chr(&HDA) & Chr(&H40) & Chr(&H0))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H1F) & Chr(&HAE) & Chr(&H1D) & Chr(&HEA) & Chr(&H51) & Chr(&H95))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HDD) & Chr(&H2B) & Chr(&HB0) & Chr(&H70) & Chr(&HD8) & Chr(&HC6))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H0) & Chr(&HEF) & Chr(&HA4) & Chr(&H56) & Chr(&H1D) & Chr(&HF))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HD2) & Chr(&H2E) & Chr(&HD9) & Chr(&HCC) & Chr(&H61) & Chr(&H5))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H47) & Chr(&H29) & Chr(&H25) & Chr(&HD3) & Chr(&H7F) & Chr(&H56))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HB) & Chr(&HF8) & Chr(&H94) & Chr(&HD6) & Chr(&HD3) & Chr(&H51))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HF3) & Chr(&H5B) & Chr(&HA5) & Chr(&H1B) & Chr(&HF0) & Chr(&HD5))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H1E) & Chr(&H1) & Chr(&HCD) & Chr(&H33) & Chr(&H3) & Chr(&H6))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H8C) & Chr(&H15) & Chr(&H16) & Chr(&HA7) & Chr(&H2F) & Chr(&H52))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H68) & Chr(&H4A) & Chr(&H4D) & Chr(&H21) & Chr(&H62) & Chr(&H23))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H98) & Chr(&HD7) & Chr(&H77) & Chr(&HEC) & Chr(&HE9) & Chr(&H89))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HA6) & Chr(&HF7) & Chr(&HA8) & Chr(&H97) & Chr(&H42) & Chr(&HE))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H73) & Chr(&H80) & Chr(&H90) & Chr(&H35) & Chr(&H3C) & Chr(&H81) & Chr(&HFF))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HB2) & Chr(&HF5) & Chr(&HD) & Chr(&H51) & Chr(&HB2) & Chr(&H71))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H2D) & Chr(&HAB) & Chr(&HBE) & Chr(&H54) & Chr(&H98) & Chr(&HBF))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H81) & Chr(&H38) & Chr(&H52) & Chr(&H60) & Chr(&HC9) & Chr(&HF3))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H75) & Chr(&H8B) & Chr(&HDC) & Chr(&HAC) & Chr(&H5D) & Chr(&H92))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H2) & Chr(&HDF) & Chr(&H6E) & Chr(&H90) & Chr(&HE5) & Chr(&HAA))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H14) & Chr(&H91) & Chr(&HE4) & Chr(&H9A) & Chr(&HD8) & Chr(&H3D))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H17) & Chr(&HE2) & Chr(&H66) & Chr(&H86) & Chr(&H11) & Chr(&H97))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H62) & Chr(&HE3) & Chr(&HBB) & Chr(&HF1) & Chr(&H8C) & Chr(&HBD))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H26) & Chr(&H50) & Chr(&HF6) & Chr(&HC2) & Chr(&H93) & Chr(&H9A))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H99) & Chr(&H18) & Chr(&HB1) & Chr(&HBA) & Chr(&H28) & Chr(&HEC))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HDB) & Chr(&HCB) & Chr(&HDE) & Chr(&HD8) & Chr(&H4E) & Chr(&H8A))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H12) & Chr(&H2C) & Chr(&H39) & Chr(&HB9) & Chr(&H0) & Chr(&H27))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H72) & Chr(&HA2) & Chr(&H74) & Chr(&H55) & Chr(&HB4) & Chr(&H7C))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HD5) & Chr(&H41) & Chr(&H5C) & Chr(&H5D) & Chr(&H45) & Chr(&HA8))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H4C) & Chr(&HC1) & Chr(&H3D) & Chr(&H6B) & Chr(&H22) & Chr(&H18))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&H34) & Chr(&H9D) & Chr(&H85) & Chr(&H84) & Chr(&H3) & Chr(&HE0))
        sendOSMOStuff(Chr(&H7) & Chr(&H1) & Chr(&H4) & Chr(&HD1) & Chr(&HFF) & Chr(&H6C) & Chr(&H71) & Chr(&HF4) & Chr(&H7C))

    End Sub

    Private Sub sendOSMOStageTwo_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles sendOSMOStageTwo.Click
        sendOSMOStage2()
    End Sub

 

btw, if there are any employees of iRobot here... let me know if i'm on the right track or not

[gssincla]

Stage 2

After doing more testing I found out how to force a stage 2 completion. As I noted earlier only 1/3 of the commands send actually return a reply from the roomba. Fortunately, you only need to get one valid response to move to stage 2. The quickest way to do this is to ignore the first 070401... sequence and reply to the second sequence with:

Code: Select all

 10 02 06 65 24 5F E7 51 00 E0 9E 

This will then move you into stage 3

Stage 3

Stage 3 starts with the OSMO sending the following command sequence:

Code: Select all

0x7 0x3 0x0 0xC7 0x9E

The system will attempt to get a response from the roomba 10 times. After the 10th attempt the OSMO will simply stop sending ANY data and you will have to power cycle the device and start back over at Stage 0.

The roomba will reply with the following code:

Code: Select all

 0x10 0x4 0x0 0x21 0xEC 

At this point it's good night Gracie for the roomba. The roomba will now flash the status light RED and the bootloader is as far as you will get when you boot up.


IF YOU DO THIS YOU WILL HAVE TO REFLASH YOUR ROOMBA TO MAKE IT FUNCTIONAL AGAIN!!!!! You have been warned.

At this point you'd think the system would start the update, right? Oh but you'd be wrong! Welcome to Stage 4

Stage 4

After successfully completing stage 3, the OSMO sends the following packet to the roomba:

Code: Select all

 0x07 0x05 0x00 0xB1 0x27 

The OSMO will attempt this command 20 times waiting for the proper response from the roomba. If the roomba does not reply correctly in this time frame the OSMO will terminate communication and the OSMO must be power cycled again putting you back at Stage 0.

In response to the OSMO request, the roomba will return the following:

Code: Select all

 0x10 0x6 0x3 0x0 0x78 0x78 0x66 0x87

EDIT: Changed the roomba response codes to Stage 4

[gssincla]

Stage 5

(I moved stage 5 into its own thread because of the problems i'm having with it)

Stage 5 begins after the roomba successfully replies with the previous output. Stage 5 is signaled by the following packets:

Code: Select all

07 80 87 0A 00 00 3E 7D FC 62 59 58 36 F9 DC D3 

and

Code: Select all

07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 

I found that my roomba would only reply to one of those commands. Interestingly, the OSMO will toggle between the two seemingly indefinitely.

My roomba replied to the first command. It replied with:

Code: Select all

0x10 0x8 0x1 0x0 0xF 0xF9 

Once I send this command back to the OSMO, I was given another Cmd 80 packet:

Code: Select all

07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 

Giving this command to my roomba yielded the following response:

Code: Select all

0x10 0x9 0x1 0x1 0xC7 0x9E

Giving this back to OSMO has put me in a loop. The OSMO now toggles between the packets 07 80 87 0A 01 01.... and 07 80 87 22 02 02....

I can't seem to get past this stumbling block. Once I figure out how to get into stage 6, i'll update this page. Right now my current guess is that either 1) my program is faulty (always a possiblity!) or 2) I need to figure out how to get a response code for the 07 80 87 0A 01 01... packet to send back to the OSMO. I'm leaning toward #2 at the moment simply because the behavior I'm seeing now mirrors the issue of not giving a proper response to the first two packets of Stage 5.

(my current output from the OSMO)

Code: Select all

07 80 87 0A 00 00 3E 7D FC 62 59 58 36 F9 DC D3 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38 
07 80 87 0A 01 01 47 D7 0B 3B 90 E8 1C 6F D6 61 
07 80 87 22 02 02 A5 82 72 B0 A0 49 92 B3 B4 B5 19 88 8C 81 35 03 DB 8D A2 4C EA 2C E2 59 EF FA 2A D6 46 1F B4 B9 0D 38

[gssincla]

After getting very very frustrated with my progress, I employed a different approach. I hooked up my roomba and my OSMO to the extension cable I'd spliced together earlier for the OSMO reader. I rewired it so that it was a straight-through patch cable. I then wired my roo232 inline with the RX pin of the roomba. Then I plugged in the OSMO and off it went updating. I then stage 3'd the roomba so i could flash it again and this time I read the TX pin. Basically what this does is let me see both sides of the conversations and save them to file.

So in a nutshell, I now have a serial capture of both sides of the communication when an OSMO is flashing a roomba.

My new OSMO came in today with Oct 2005 firmware (thanks Alex and Fred from roombadevtools!!). So I have two versions to flash my roomba with. I found out that if you Stage 3 the roomba you can actually downgrade your firmware to an older version (in my case the Aug 2005 firmware).

Once I'd proven to myself I could get the full conversation, I went on to capture all possible combinations of the version flashings (upgrading, downgrading, reflashing). The reason I did this was simply because it dawned on me that if i was running the Oct version and i recorded the roomba responses to the flashing, that if i flipped to the OSMO side of the conversation, I'd be watching a different version being flashed. So I had to make sure that the conversations matched... that if i recorded a reflash of the Aug version I was starting the process with the roomba in the same state each time. This required me to flash my roomba 8 times! I plotted the time it took between each variation and the results were:

Code: Select all

10 ->  8:  95s/95s
 8 ->  8: 91s/91s
 8 -> 10: 117s/110s
10 -> 10: 95s/95s

Notice that it takes significantly longer to flash from the Aug (8) version to the Oct (10) version. Not sure why that is yet.


The interesting thing is that the files have the exact same size at first inspection. I haven't had a chance to fully disassemble the data but i'm working on it.

My initial observations are:

1) the data has NO text strings.. this makes finding a reference point for reverse engineering difficult
2) the data is largely in consistent packet sizes though so have a few extra bytes... not sure if these are separate commands or just outliers
3) the data patterns look similar acros the board

It's going to take me a while to figure out what I have obviously. But what I do know now is that Stage 5 is the actual flashing stage. There is a stage 6 at the end that seems to reset the box to engage the new firmware.

Once I have more information, I will post it here.

Please note that I cannot release the captures at this time. I am afraid this might cause me grief when iRobot's lawyer's accuse me of copyright issues and intellectual property issues. But keep in mind that I have been very very detailed in what I've done. It should be easy to replicate it.

I will, however, post my findings such that you can see what is going on. From this point on I feel I'm walking a very fine line. But don't worry, I'm all about sharing!!!

greg.

[vic7767]

Greg,

Let us not forget, IRobot created, designed, engineered, installed, and sold us the SCI interface as well as OSMO peripheral devices so that we could play. Good Luck!!!

[gssincla]

Let us not forget, IRobot created, designed, engineered, installed, and sold us the SCI interface as well as OSMO peripheral devices so that we could play.

you know, that's a bloody good point! Maybe i'm being overly cautious. How about this, what do the moderators think? If you think its ok to release this, let me know and I'll PM you with the captures to post here.

greg.

[THX-1138]

Vic has a point there but I would have to read the disclosure found inside the OSMO package that we agree if used. Last time I read it said that we can test and work around it but could not profit from it. Do you have the disclosure in PDF or txt format? Let me go over it with the site admin and we go from there.

[gssincla]

Vic has a point there but I would have to read the disclosure found inside the OSMO package that we agree if used. quote]

Looking at the website I found this under the EULA

5. YOUR SOFTWARE : Use and distribution of Your Software is also subject to thefollowing limitations: You (i) shall be solely responsible for any update or support obligation or other liability which may arise from your use or distribution, (ii) shall not make any statement that Your Software is ?certified,? or that its performance is guaranteed, by iRobot, (iii) shall not use iRobot?s name or trademarks, (iv) shall prohibit disassembly and reverse engineering of the iRobot Software and the Roomba , (v) shall not publish reviews of iRobot products designated as beta without written permission from iRobot, and (vi) shall indemnify, hold harmless, and defend iRobot and its suppliers from and against any claims or lawsuits, including attorney?s fees, that arise or result from Your Software, including your use and your distribution.

See the section iv. This is what concerns me.

I'll send you my files THX. Right now they are pretty rough.

Needless to say I'm very excited about this.

[gssincla]

Ok, here are the captures I made. They are broken up with one file (roomba*.hex) being for the roomba transmissions and the other type (osmo*.hex) being the OSMO transmissions.

I'm about 99% certain that the data is encrypted.

I've also attached an excel sheet that shows the frequency of any one value in the capture. Notice how in the OSMO transmissions you will not see 0x10 in any command after the bootloader is engaged (thus after the version commands were issued) and in the roomba transmissions you will not see 0x07 in any response. This is interesting because OSMO uses 0x07 to identify the start of packets and roomba uses 0x10 to indicate the start of a reply.

Something I'll get into in more detail later (well, after i figure it out) is that it seems that packets that don't match the standard pattern have 0x80 in them. Take a look at one of the OSMO captures... you'll see in the .txt versions how i've broken them up into packets (starting with 0x07) but some while having the 0x22 packet size actually exceed this limit. The ones that have uneven line endings will have 0x80 somewhere in the data field. This is interesting. Not sure why, but it is interesting.

Anyone, please post your thoughts and inputs on these.

AND ... Lets all give the Admins a big hand for allowing us to upload files now! Thanks guys!!!!

[Howard]

0x80 is being used as a command character.
The way that they have structured the com protocol 0x07 and 0x10 cant be used as part of a message because they indicate the start of a new message. What they have done to get around this is to precede the byte that cant be transmitted with a 0x80 which is indicating to XOR that byte with the following byte. This results in the following translations

0x80 0x87 becomes 0x07
0x80 0x90 becomes 0x10
0x80 0x00 becomes 0x80