How to add noise to a single transformation

[miguelriemoliveira]

Hey @brunofavs ,

I remember for your M.Sc. you implemented this functionality, but now its lost on the gigantic PR that you did.

Could you do a simple, very focused PR just to include this functionality?

Was it possible to define noise for several transformations?

[brunofavs]

Hey @miguelriemoliveira
Yes this functionality was entirely implemented before. It allowed users to add a desired amounts of noise to whichever transformations the user wants.

Like I could add X noise for transformation A; Y noise to transformation B... etc . I don't recall if you could add different amounts of translation vs rotation.

Could you do a simple, very focused PR just to include this functionality?
I added it to my to do list of tomorrow already :)

I remember I also did a overhaul of the noise implementation, a refactoring of sorts. I will assess it tomorrow and keep you updated.

PS: If the user added noise to a transformation that already had noise applied, like one of sensors being estimated, it would overwrite the previous noise with the latter.

[miguelriemoliveira]

OK, thanks.

[brunofavs]

Hey, I was looking at this issue this afternoon, I found a way to isolate most of the changes that I did in my MsC. branch that will mitigate a lot of potential work lost.

The main problems are that the features back then weren't properly isolated in a easy to find commit so that I could easily now use the git cherry pick command. Moving forward I'm considering adopting the workflow where multiple commits for a single feature are done, but squashed (git squash) into one before committing to the online repo to achieve a clean commit tree.

The other problem is that by using a DiffView now and comparing it to the current main branch, there are a bazillion changes and its hard to track things, as the main branch as already been developed a ton since. Seeing the log of commits of my branch could also work but they are a bit messy as the implementations of the features are spread out across multiple commits.

Then I found a very useful command git merge-base that finds the best possible common ancestors for a merge. With this, you usually find the commit hash where the feature branch branched from the main. Now, with a DiffView between my branch and this hash, i can see super clearly all the bits of code implemented.

I will do individual PR's for all these features here. I detailed with this approach as it might be a good future reference for someone dealing with forgotten features on old branches, plus I was happy to finally find a way to solve the mess I did before on my branch so I wanted to share :)

[miguelriemoliveira]

Thanks @brunofavs . Great work!