Input and output formats
------------------------

The library understands two formats: a rich JSON format, and the old good Carmen format.

### The JSON log format ###

See this site: <http://www.json.org> for general information about JSON.

This is a sample laser data structure. It has only 5 rays (which all
happen to be invalid), and it has no `alpha`, `true_alpha`, `cluster` fields:

	{ 
	  "nrays": 5, 
	  "min_theta": null, 
	  "max_theta": null, 
	  "theta":    [ null, null, null, null, null ],   
	  "readings": [ null, null, null, null, null], 
	  "valid":    [ 0, 0, 0, 0, 0],

	  "odometry": [ null, null, null ], 
	  "estimate": [ null, null, null ], 
	  "true_pose": [ null, null, null ] 
	}

Note that `NAN` is represented with `null` in the JSON format.


### The Carmen log format ###

The 6 pose values in the log are interpreted as follows:

	estimate.x estimate.y estimate.theta ....
	odometry.x odometry.y odometry.theta 

<!--diego:
	quindi tu alla fine
	leggi il secondo campo
	e scrivi il secondo campo
	(e scrivi, per sicurezza, il primo campo)-->

#### Regarding the timestamp ####	
	
Regarding the timestamp "fields". The last three fields in a Carmen log can be:

	integer   string   integer

This is interpreted as seconds, hostname, microseconds. This is good if you want to write a `timeval` struct to the log and *be sure* it won't be modified by precision problems when writing, and parsing, as a `double`.

If it doesn't look like a timestamp, then it is assumed that the fields are:

	double string double

In this case, the first double is interpreted as the timestamp in seconds, while the second double is discarded.

The library will warn the user about these decisions by writing on the console this message:

	sm2:inf: Reading timestamp as 'sec hostname usec'.

or this one:

	sm2:inf: Reading timestamp as doubles (discarding second one).

