Some miscellaneous improvements to exercise 1 I found when running through the example:
Update README with some images
Remove the extension on the start script for consistency
Update RViz config to better see what the hot dog looks like (I spent a lot of time modelling that thing, I want people to see the mustard!)
Clarify some comments in the examples
Explicitly call out TODO where attendees are expected to change code
Add // Add your code here style comments to act as placeholders to highlight in the slides.
If attendees change these lines, they won't need to add new lines, and their line numbering should match with the presentation, which is nice. If they add new lines, anyway, the line numbers should be close enough regardless.
Don't use auto in some cases where the type is handy to know about
Don't use const for variables attendees will interact with - this allows them to add the change as a new line rather than having to change the line
Use magic numbers for eef_step and jump_threshold rather than having them be variables - the numbers are explained in the slides, and this keeps the code shorter and easier to talk to on the slide.
Some miscellaneous improvements to exercise 1 I found when running through the example:
// Add your code here
style comments to act as placeholders to highlight in the slides.auto
in some cases where the type is handy to know aboutconst
for variables attendees will interact with - this allows them to add the change as a new line rather than having to change the lineeef_step
andjump_threshold
rather than having them be variables - the numbers are explained in the slides, and this keeps the code shorter and easier to talk to on the slide.