User manual

old releases - latest release - trunk

Object overview

Spheres, cylinders, cubes, circles and polygons

basic_primitives.png

General purpose visualization primitives that can be used for a variety of visualization tasks.

The radius of spheres, cylinders and circles is 1 m, unless scaled otherwise. The height of cylinders and the sides of cubes are also 1 m by default.

Spheres, cylinders and circles are equipped with automatic level-of-detail (LOD) handling to yield better performance without lost aesthetics.

Currently, polygons are always filled and circles always non-filled. If you need an unfilled polygon, use a point cloud.

Client API:
SphereProxy, CylinderProxy, CubeProxy, CircleProxy, PolygonProxy
Definition file syntax:
Spheres, cylinders, cubes and circles and Polygons, point clouds and line clouds

Point and line clouds

clouds.png

Point and line clouds are used to represent one or more points or lines respectively. All points/lines contained in the cloud share the common properties such as color, opacity and in which coordinate system they are specifiecd.

A typical usage scenario is to use point/line clouds to visualize particle fitlers or sensor measurements not directly supported by peekabot's sensor construct.

The cloud primitives are very efficient at representing large sets, but to achieve the best performance, clusters that are very disjoint in space should be represented by separate clouds. For example, if you have 100 robots doing localization using particle filters in a huge environment you'd benefit from visualizing their particles using one point cloud per robot, rather than just one.

Client API:
PointCloudProxy, LineCloudProxy
Definition file syntax:
Polygons, point clouds and line clouds

Grids

grid_types.png

There are three different kind of grids: regular, radial and angular grids, all depicted above. Although there are three types of grids, there's only one grid primitive, which has a setting for configuring the type.

For radial and regular grids, the size of the segments in the grid is determined by the object's scale.

Client API:
GridProxy
Definition file syntax:
Grids

Cameras

camera.png

Every view in the peekabot server is rendered through a camera object, and different views can use different cameras. Having cameras as first class objects allows cameras to be attached to e.g. robots and move around with them as they are moved.

The FOV of the camera is depicted by the pyramid, and the focus point of the camera is shown by the dashed line.

Client API:
CameraProxy
Definition file syntax:
Cameras

Models

models.png

Models provide a way to show complex objects that aren't easy to represent using any other type of primitive. Models are currently the only primitive that can be textured.

Client API:
ModelProxy
Definition file syntax:
Models
See the section on Model conversion for documentation on which file formats are supported and how to convert your models into a suitable format.

Occupancy grids

2d_occupancy_grid.png

The occupancy grid primitive provides a convinient and efficient way for visualizing 2D occupancy grids. The storage is sparse: unused cells require no memory and adjacent cells with the same occupancy value are merged and stored as big cells.

Cells about which nothing is known are drawn transparent. The color used to draw other cells is linearly interpolated between a per instance configurable unoccupied and occupied color.

Client API:
OccupancyGrid2D
Definition file syntax:
Occupancy grids cannot currently be specified in scene or robot definition files.

Robots

Robots have no graphical representation themselves. In addition to all the standard primitives, robots can have sensors and degrees of freedoms as child objects.

Client API:
RobotProxy
Definition file syntax:
Robots

Sensors

To make your life easier, peekabot has a special framework for visualizing sensor data. You just send the data and peekabot takes care of transforming the readings into the proper visual representation. peekabot ships with support for a number of commonly used sensors such as laser range finders, sonars and bumpers.

To use a sensor, you define it in your robot's definition file. Then from your client, use an SensorProxy instance to update the sensor with your readings.

Most sensors have parameters that can be defined in the definition file. Which parameters are available, their accepted values and in what format the sensors expects the input data can be found at the respective sensor type's documentation page.

Client API:
SensorProxy
Definition file syntax:
Sensors

Joints and tracks

If your robot is equipped with a manipulator or similar device, peekabot's DOF constructs provide a nice interface for updating its degrees of freedoms (DOFs). Translating and rotating the manipulator's parts manually is normally both harder and more error prone than delegating the task to peekabot.

A DOF is an object that affects all of its children when its value is set, either by rotating (joints) or translating (tracks) them.

Client API:
DOFProxy
Definition file syntax:
Degrees of freedoms, Joints, Tracks

Text labels

label.png

Text labels provide orientable, scalable text annotations. Useful for annotating maps etc.

Currently only one font is supported, a serif font.

Client API:
LabelProxy
Definition file syntax:
Labels