As the title says.

I had this idea and I think it's cool:

lidar-vis should be broken into lidar-scan and lidar-vis

• lidar-scan
  it just connects to the rplidar on port and outputs the data to stdout
• lidar-vis
  basically current lidar-vis, but with rplidar-specific functionality stripped. It accepts data on stdin and visualizes them in a window

Advantages of this approach:

• we would have 2 nice, tiny programs that do one thing and do it well instead of 1 bigger monolith
• easier & faster development, because the parts are independent
• cleaner and simpler code, uncluttered with ifdefs

lidar-scan

lidar-scan would be always compiled with rplidar_sdk (because it's main and only purpose is get data from lidar and print it to stdout).

Example lidar-scan usage

Perform a single scan and create a single cloud. Write output to stdout.
$ lidar-scan --port <lidar_port>

Perform a single scan and create a single cloud. Write output to some file.
$ lidar-scan --port <lidar_port> >> cloud.txt

Scan forever (until e.g CTRL+C) and create a cloud series. Write output to stdout.
$ lidar-scan --port <lidar_port> --series

lidar-vis

lidar-vis would be always compiled with SFML (because it's main and only purpose is to visualize lidar data).

It would work in 2 modes (like currently): file and file series

Example lidar-vis usage:

Visualize single cloud scan:

$ cat cloud.txt | lidar-vis

Visualize only the first 30 points of a single cloud scan:

$ head -n 30 cloud.txt | lidar-vis

Visualize cloud series scan:

$ cat cloud_series.txt | lidar-vis --series

Visualize live data from lidar:

$ lidar-scan --port <lidar_port> | lidar-vis --series

You see where it goes...basically unlimited flexibility with what we want to do with the data.

This way, they won't clutter up the root dir and won't be accidentally added to .gitignore

so:

• on screenshot button click, save a screenshot to /screenshots dir (when there is no such dir, create it)
• add /screenshots do .gitignore

The options in the README and program help menu are different – e.g --gui is only listed in README (but it indeed exists and works)

README:

help message:

I think the following behavior (i.e when no options/flags are passed) is a bit confusing:

I'd suggest displaying help when no options/flags are passed.

I can't pronounce it.

We need to be able to build the project on Unix-like systems (*nix).

Error:

Step 6/10 : RUN ./install_sfml
 ---> Running in 1f37aba2626c
./install_sfml: line 2: $'\r': command not found
./install_sfml: line 5: $'\r': command not found
./install_sfml: line 9: syntax error near unexpected token `$'{\r''
'/install_sfml: line 9: `_log() {
The command '/bin/sh -c ./install_sfml' returned a non-zero code: 2

As the title says. If we want to have >1 developers working on this project, we need to use some simple-to-setup and use code formatting solution.

I just don't know why it's like that