Timeline of takePicture
Timeline of the takePicture() function.
What happens when you enter the command:
Quite a lot, actually! This timeline describes the process in some detail.
This assumes that you have your computer running a Myro language, and that your computer is connected to the Fluke and Scribbler robot.
|1||You enter the command to take a picture on the host computer, using one of many possible Myro languages (including Java, C++, C, Python, etc.) The language looks up the code for taking a picture. The code (called a "bytecode") for getting a JPEG-compressed image from the Fluke is 138---the Fluke designers picked an arbitrary number to mean "snap a picture, and compress using jpeg".|
|2||The bytecode 138 is written onto the serial port connection. The host computer is not aware of whether the serial port is using an actual serial cable, or if it is a wireless connection over Bluetooth. It doesn't matter to the host computer.|
|3||The code travels over the connection (wire or wireless) and is received by the Fluke. The Fluke is running a program called "firmware". It has a series of bytecodes pre-defined in the firmware that it is programmed to respond to. The Fluke has been waiting for a bytecode, and it knows what 138 means when it finally arrives. If it received a bytecode that it didn't know about, the Fluke would pass it on to another serial port, the one connected to the Scribbler. But this one, it handles itself.|
|4||As the bytecode is 138 (meaning "snap a picture, and compress using jpeg") the Fluke begins grabbing the bytes spewing out of the Fluke's on-board camera, a Charged coupled device (CCD). The CCD represents 256 columns by 192 rows of pixels in an interesting format, called YUV. When the Fluke determines that it has an entire image in YUV format, it then compresses the image into the JPEG format on the Fluke.|
|5||After the image is compressed into the JPEG format, the Fluke takes each byte of the image representation and sends it back to the host computer over the serial port. As the image can be represented by a variable number of bytes, we need to send a special signal to the the host computer know when it reaches the end of the image data. The Fluke designers decided to signal the end of this "stream" of bytes representing the image with two bytes, 255 followed by a 217.|
|6||The host computer has been waiting since it wrote 138 on the serial port. Finally, after a few dozen milliseconds, data starts coming back. The host computer collects the stream of bytes, in order, until it receives a 255 followed by a 217, which signals the end of the image. It takes about 0.3 seconds to for the Fluke to compress and transmit a 256 by 192 JPEG image. The Fluke takes a little bit of time to compress the image, but it is worth it. If the Fluke sends an uncompressed image, it takes about 1 second.|
|7||The host computer then takes the received JPEG image bytes, and decompresses them into an image using the host Myro language. This also takes a little bit of time, but compared to the transmission time, is negligible.|
|8||At this point the image only exists in memory. The language packages up the image appropriately creating a data structure in the host language, and returns the image from the takePicture command. And that is the end of the "snap a picture, and compress using jpeg" process.|