Add fake devices

[EpicEric]

No description provided.

[patrickelectric]

Thanks @EpicEric I should review it by the end of the day

[patrickelectric]

The commits need to be organized:

• 94eeed0 is changing front, back, dependencies and a .mcap file (?)
• 6e7b2f3 is changing code that was added in 94eeed0. The corrections need to be done in the commit that added them.
• 176760f is changing code from previous commits and also deleting the .mcap file

Just to quote:

Details

Create atomic and self-contained commits, avoid doing multiple tasks in the same commit.

E.g: You created a commit to fix the serial communication class, and inside the same commit you are doing 3 different tasks, removing trailing spaces, fixing a pointer validation check and a typo in the documentation of a different class. This appear to be silly and bureaucratic, but there are good reasons to break this simple commit and at least 3 different commits, one for the pointer check, a second one for the typo and a third one for the trailing space.

Developers usually track lines history to understand the changes behind a functionality, it's common to search with grep history from commits or line changes in specific commits to understand the history of a library, function, class, or a small feature, if the commits start to be polluted with unnecessary changes, this development practice will be almost impossible to be done, since a bunch of unrelated lines will me changed between commits and this technic will be unable to help the dear developer. git blame will also be of little help.

The example was also really simple, but you can imagine what happens if you change different parts of the code, for unrelated things, and a bug appears, technics such as git bisect will still work, but the result will be much harder to understand and to find which line is the one that created such bug.

Create atomic and self-sustained PRs, avoid doing multiple things in the same PR, like different features. They may appear simple with small pieces of code/functionality but they can escalate quickly after a review process, and if both features are somehow related or dependently, it's recommended to break it in multiple PRs with code to maintain compatibility with current code base.

E.g: You have applied a PR for software notifications, and somehow you also added a URL fetch functionality to grab new software versions from the server. After the first review, the maintainer asks to create a more abstracted way to fetch data from a REST API and to deal with network requirements, this will start to convolute the PR, moving the initial idea of the notification feature to an entire network REST API architecture. With that, it's better to break the PR in two, one that only provides the notification and a second PR that is used for the REST API related code.

[patrickelectric]

Nice cleanup!

[patrickelectric]

It's ok to merge as a first version, I recommend taking a look in the fake ping used in ping-viewer (the old one):

• https://github.com/bluerobotics/ping-viewer/blob/master/src/link/ping1dsimulationlink.cpp
• https://github.com/bluerobotics/ping-viewer/blob/master/src/link/ping360simulationlink.cpp

I also recommend compiling and running the fake devices to see how they play