Scribbler 2
MyroC

Materials to Support a C-based Course with Scribbler 2 Robots
Scribbler 2
 
 

MyroC: Data Structure Design for Scribbler 2 Camera Images

The Scribbler 2 robot with a fluke component includes a camera, and images can be sent over Bluetooth to a paired workstation. Image size depends upon the specific fluke hardware:

Motivations for Pictures in MyroC

MyroC utilizes these images to meet several pedagogical goals and objectives within an introductory course on imperative problem solving and data structures.

Altogether, pictures provide a motivating context for a wide range of experiments and experiments with structs, 1-dimensional arrays, 2-dimensional arrays, and data abstraction.

A Natural Struct Definition

Pragmatically, a MyroC user may run a program on either an original fluke or a Fluke 2. Further, since a workstation may connect to multiple robots, a program may connect to one or more Scribbler 2 robots that use original flukes and one or more that use Fluke 2s. Within an introductory course, students should not have to focus on which fluke is being used for any run, so the same defined data structure (e.g., Picture) should work without change and without recompilation for either fluke. This suggests that data for an original fluke might be stored in a subset of the structure declared for a Fluke 2 image.

As an initial design, a Picture might allocate space for a high resolution image:

typedef struct {
   int height;
   int width;
   Pixel pix_array [800][1280];
} Picture;

Since a Pixel requires 3 bytes for RGB data, this Picture struct requires 3,072,008 bytes of storage. Unfortunately, the run-time stack on both Linux and Mac OX X are limited to 8,192K bytes, allowing only a Picture array of size 2 to be declared.

Altogether, use of an array of high-resolution images of this type is not helpful for an introductory course.

Alternative Structures

At least three alternative approaches can help resolve this storage problem, but each has drawbacks.

Low-resolution struct struct with pointer to pixels separate struct into separate components
Typical declarations
typedef struct {
   int height;
   int width;
   Pixel pix_array [266][427];
} Picture;
Picture pic1;
rDisplayPicture (pic1, ...)
typedef struct {
   int height;
   int width;
   Pixel * pix_array;
} Picture;
Picture pic1;
... 
pic1.pix_array
   = malloc(sizeof(Pixel)
            *pix.height*pix.width);
int pic1_height;
int pic1_width;
  ...
int pic1_pix_array[pic1_height]
                  [pic1_width];
  ...
rDisplayPicture (pic1_height,
                 pic1_width,
                 pic1_pix_array);
Description Pixel array size limited to low-resolution images Picture struct points to array of Pixels, allocated separately Picture data divided into three separate variables, taking advantage of C's variable-sized arrays
Advantages
  • Maintains grouping of data in struct
  • Allows practice with 2-dimensional arrays
  • Allows arrays of up to about 30 Pictures
  • Maintains grouping of data in struct
  • Only uses memory as needed
  • A [very] few high-resolution images possible
  • Allows arrays of a moderate number of Pictures of low-resolution
  • Only uses memory as needed
  • Allows practices with 2-dimensional arrays
  • Allows arrays of a moderate number of Pictures of low-resolution
Disadvantages
  • Removes option of high-resolution images
  • Manipulation of Pixel[i][j] requires colSize*i + j indexing
  • Double subscripting of 2-dimensional data not available
  • Illustration of struct grouping lost
  • Picture functions require 3 parameters (height, width, pixels)
  • Picture sequences require 3 supporting arrays (height, width, pixels), and all images must have the same resolution

Conclusion

Use of the low-resolution struct is the only option that supports all three learning goals: grouping of data, practice with 2-dimensional arrays, and example with a 1-dimensional array of images. Further, since high-resolution images are quite large, no solution can support more than 2-3 such images — greatly reducing any benefits of the alternatives for image storage.


created 21 February 2016
revised 22 February 2016
Valid HTML 4.01! Valid CSS!
For more information, please contact Henry M. Walker at walker@cs.grinnell.edu.