Any coordinate in a bitmap (note: the term bitmap here [all lower case] refers to the concept of a grid of pixels, not the Windows BMP file format which I will always refer to as BMP all in capitals) can easily be calculated as long as you know the width. The height is only needed to stop you going too far.
Any pixel offset in a buffer of pixels is calculated as y * height + x assuming a left-right / top-down pixel arrangement in the buffer.
The information you are really interested in with your bitmap is actually considerably less than is in the BMP that you show. Your BMP is 54x96 pixels, but the information you actually care about is actually only in a resolution of 7x12 blocks. A slight complication is that your outside border of blocks is slightly narrower than the rest, so you will have to compensate for that when examining it.
It would be far simpler if you could pre-process the provided BMP on a PC to create an array of 84 entries each with a different tag or value to represent what it is. Your image there could then be represented as the array:
{ 3, 3, 3, 3, 3, 3, 3,
3, 1, 0, 0, 0, 1, 3,
3, 0, 0, 0, 0, 1, 3,
0, 0, 1, 1, 0, 0, 3,
3, 2, 1, 0, 0, 0, 3,
3, 1, 0, 0, 1, 0, 3,
3, 0, 1, 0, 0, 0, 3,
3, 0, 0, 0, 2, 0, 3,
3, 0, 0, 1, 0, 0, 3,
3, 1, 1, 0, 1, 0, 3,
3, 0, 0, 0, 0, 0, 3,
3, 3, 3, 0, 3, 3, 3 };
Where 0 is an open white space, 1 is a closed black space, 2 is a black space with a cross and 3 is a border space.
The two crosses would then be calculated as (1,4) = 4 * 7 + 1 = 29 and (4,7) = 7 * 7 + 4 = 53.
Working with BMP files is somewhat more tricky. They come in multiple depths and multiple bit arrangements, as well as different versions with different header sizes. They also have different padding requirements for different line lengths and bit depths, and are generally a rather nasty file format all round.
And on top of that they are upside down. BMP is the only file format I know of where 0,0 is at the bottom left instead of the top left. Consequently you have to invert all your Y coordinates to make sense of it, and parsing a BMP file from the top down is really slow because you have to keep jumping backwards in the file.
So it would be much better if you could write a program on a PC using software which already understands the BMP format and can render it into a buffer for your program to then parse each block to work out what it is and build up a small 84 byte file of the actual information you need for your robot.
If you must read the BMP file directly on the Arduino then I have code you use to help you. It's not designed for the Arduino but for the chipKIT boards (though it's very similar) and is designed as part of my DisplayCore framework for chipKIT (and other more powerful) boards, but you are welcome to take whatever bits you like, or just use bits to give you more insight into how BMP files work. You can get the code from Github here: https://github.com/MajenkoLibraries/DisplayCore/tree/master/ImageReaders/BMPFile