A realtime software and hardware-based display for data collected by the LIDAR Station and transmitted to the display computer/device.

LIDARDisp is a small Linux/svgalib application using parts of rcxlib from Dave Baum's NQC to communicate with the LIDARStation RCX to start/stop scanning, and upload the logged data at the end of each scanning pass.

The uploaded data is plotted radially, and a small amount of diagnostic data (samples, sample angular resolution, RCX battery voltage) is displayed.

Previous sensor sweeps 'decay' in intensity until they disappear (8 levels of decay). The display background color switches from black to green during LIDARDisp<->LIDARStation communications (to mimic the IR Tower's green 'activity' LED which is not always visible to the operator.

Pressing the 's' key will cause a screenshot to be saved to a numbered PNG image after the next redraw. All screengrab on this page were created this way (and then resaved as GIF for portability). Holding shift and pressing 'S' causes a data dump of the LIDAR array to be written to a numbered file after the next redraw. Keys are not queued, so you may have to hold the key down for a while until after the next redraw.

LIDARDisp sends a 'run' command to the LIDARStation RCX program when started, and sends a 'halt' command when LIDARDisp exits. It uses the RCXlib code from NQC to accomplish this, and to execute Datalog upload. Thanks for the great code, Dave! Would have been very tedious to rewrite this myself, glad I could use your very-well-designed class library. Look here for simple examples of how to use RCXlib for these purposes.

The software conveniently core dumps on CTRL-C exit. I'm not sure why, but it seems to have something to do with svgalib and LIDARDisp fighting over signals.

I'm sure it would be easy to port this to other platforms, as nothing svgalib does is very complex. Notify me if you do, and please try to use #ifdefs so the two ports can coexist.

C++ Source code with a makefile for Red Hat Linux 6.x is available.

Operation with LIDAR Station

When LIDARDisp starts, it uses the RCX_Link and RCX_Cmd RCXlib classes to issue a 'run program' command to the RCX, assuming that the LIDARStation code (xlidarst.nqc) has already been downloaded into the active program slot.

LIDARDisp then goes into a 30-second sleep stage while LIDARStation calibrates its orientation and executes the first sweep. (One sweep usually takes less than 14 seconds, and there is a 1.5 second pre-calibration reverse phase.)

LIDARStation attempts to create a 360-entry datalog. In practice, with a program the size of LIDARStation resident, I've not been able to get more than about a 175-entry datalog, but I have not tried clearing any other RCX-resident programs. We only use about 140 entries anyway.

LIDARStation, on startup, reverses the rotation motor for 1.5 seconds. This way, if the unit was shut down with the sync sensor right on the sync trigger, we will find the sync trigger quickly instead of having to execute a full rotation. Once the rotating assembly passes the sync sensor over the sync trigger, the first Sweep begins.

The apparatus rotates at about 1 revolution every 14 seconds, and samples LIDAR range values at about 10Hz, resulting in (on average) 137-140 samples per sweep. Each sample is written to the RCX datalog as it is captured. An optional piece of code (#ifdef'ed PLAY_RANGETONES) enables tones of various pitch to be played when a non-zero range value is detected. No rotation value is stored for each sample, the rotation position is inferred from the context of the Range value in the datalog.

When the LIDARStation completes a full sweep (by crossing the magnetic sync sensor again) it stops the rotation motor and goes into a 'sync stall' state, with the RCX IR window hopefully pointed toward the IR Tower. In this stage, it awaits a request for datalog upload and then a message permitting it to clear the datalog and continue with the next sweep.

The LIDARStation code does not actually participate in the datalog upload. The datalog upload happens 'behind its pack' as it were by the host LIDARDisp software commanding the RCX firmware to begin the upload. (LIDARDisp turns the host computer display's background color dark green during the upload to mimic the IR Tower's activity LED which might or might not be visible to the operator.) When the upload is successfully completed (handled by RCXlib's RCX_Log and RCX_Link classes), the LIDARDisp software simply sends standard Message #1 to the LIDARStation program. Message #1 causes the LIDARStation code to clear the Datalog, and exit the 'sync stall' state, embarking on a new sweep. (Note, after the upload but before Message #1 is sent, RCXlib/RCX_Link/RCX_Cmd is used to query the battery voltage level of the RCX).

After the LIDARDisp software sends Message #1 to begin the next sweep, if it finds any records in the datalog, it calculates the angular extent of each record by dividing 360 degrees by the number of records. Then, it plots the full set of received records radially to the host computer's display. 'Up' on the computer display is the direction that the sensor apparatus is facing when it stops on the sync trigger. A few statistics (Samples, Sample Angular Resolution and Battery Voltage) are printed in the upper right corner of the display. Defining LOG_MESSAGES in lidardisp.cpp also causes this info to be printed to stdout.

Before each new sweep's data is plotted, the existing onscreen and in-memory data are 'aged' by dimming their color slightly to simulate a RADAR display's persistence. In this way, moving or changing entities can be more easily detected. There are 7 levels of decay before eldest data points are finally cleared.