ROB 599: Programming for Robotics | Fall 2019
Instructor: Acshi Haggenmiller (acshikh), PhD Candidate
1620 Bob and Betty Beyster Building (CAEN lab in the hallway to DOW)
This class is designed for engineering students who have a basic understanding of programming but haven’t majored in computer science or taken a dedicated sequence of programming courses. The goal of this class is for students to learn how to 1) write programs from scratch that meet robotic system requirements; 2) organize programs into logical sections; 3) critique program design and implementation choices; 4) use appropriate debugging tools and methodology to efficiently understand and correct program behavior; and 5) use the command line to work with git and other relevant utilities and scripts.
As it is titled Programming for Robotics, we have tried to design the in-class problems and homework assignments to be relevant to common robotics situations and algorithms, with the greater goal of demystifying programming and avoiding black-box magic. To be relevant and exciting, we designed the homework assignments around building a robotics simulation environment. While there are many excellent libraries and tools available for this (ROS among them), we will figure it out for ourselves! The best way to learn programming is by programming, so there will not be any quizzes or exams, and algorithms and necessary math will be provided so you can focus on implementation and not derivation.
The class is based around programming in the C programming language. C is a relatively simple language that will let us understand computer programs fundamentally works because the language itself will do very little complicated work for us. Although most robotics programming is done in languages like Python and C++, the fundamentals you learn in C will help you to better understand what is happening in those more complicated languages.
Most class sessions will follow a “labture” format. We will start with a series of segments containing a short lecture, an instructor demo, individual work on a self-contained problem, and finally class solution evaluation. Students are encouraged to ask each other and the instructor for help, but only students who have finished a problem should be looking at other students’ code. In the evaluation, we will review several anonymous solutions and talk about their relative strengths.
Some class sessions will not have any formally scheduled instruction or problems. Instead, topics will be addressed on an as-needed basis, with the remaining time open for working on the homework assignments with instructor help. The homework assignments are intended to require about 4 hours per class session. In general, they will be due 1 week after the end of the topic section they were assigned in. For example, the first homework will be due before class session 5.
Classes 1-3: Data representation
- Goals: 1) Inspect abstract data (e.g. pictures, text, plans) at the byte and bit level, and understand how changing low-level numbers effects high-level meaning. 2) Use the command line with git and the class submission system to get feedback.
- Class 1: Using git to commit and submit code; expressing logic
- Class 2: Arrays, ASCII, bytes, and GDB
- Class 3: As needed
- Homework 1: Polygonal collision detection, cryptogram
- There are variety of C concepts that will not be explicitly covered in class! We are providing a tutorial document to help explain the necessary syntax and basic ideas so we can delve right into the good stuff!
- For an even gentler introduction to C, I highly recommend Harvard’s CS50 lectures. Although the whole lectures can be long, they have good tables of contents on each lecture on YouTube, and work well at 2X playing speed. This clip focuses on compiling C, on using make, and on common compiler errors. This one is on the compilation process. If you want to follow along with their examples, you will need to use their sandbox.
Classes 4-7: Memory concepts and debugging
- Goals: 1) Determine when dynamic memory is appropriate and how to prevent and detect memory leaks. 2) Determine when pointers are necessary and reason about when they are valid. 3) Use feedback from GDB, Valgrind, and AddressSanitizer to fix memory and other bugs.
- Class 4: Addresses, pointers
- Class 5: Malloc/free, debugging errors, and dynamic arrays
- Class 6: Linked lists
- Class 7: As needed
- Homework 2: Rasterizing bitmaps, Braitenberg vehicles
- This clip talks about how data is stored in memory. This one talks about pointers. This one talks about malloc and free. This one talks about memory addresses and hexadecimal. This one is on stack overflows.
Classes 8-10: Recursion and Search
- Goals: 1) Reason about and write recursive algorithms. 2) Use search algorithms with forward simulation to choose robot actions.
- Class 8: Recursion vs iteration, tree search
- Class 9: Bisection search, midpoint method
- Class 10: As needed
- Homework 3: Equation parsing, robot chase
Classes 11-13: Object abstractions
- Goals: 1) Analyze algorithmic complexity and determine when it matters. 2) Choose data structures based algorithm needs. 3) Separate and hide implementation from specification.
- Class 11: Complexity/Big-O Notation
- Class 12: Hash tables
- Class 13: As needed
- Homework 4: Nested settings parsing
Classes 14-17: Threading
- Goals: 1) Understand when threading is necessary and how to avoid using it unnecessarily. 2) Determine when variables may be subject to race conditions and how to prevent them. 3) Use threading for terminal input control.
- Class 14: Basic threading
- Class 15: Race conditions, deadlock, mutexes
- Class 16: Terminal settings, I/O threading, manual robot control
- Class 17: As needed
- Homework 5: Live-tuning potential fields with visualizations
Classes 18-19: Message passing and networking
- Goals: 1) Divide robotic systems into independent parts. 2) Coordinate program communication across network nodes. 3) Use logging and playback features to debug specific modules.
- Class 18: LCM/ROS basics, hybrid architectures
- Class 19: Networking
- Class 20: As needed
- Homework 6: Split project into communicating processes
Classes 21-27: Final projects
- Goal: Implement a complex robotics algorithm in simulation and evaluate its performance.
- Class 21+: Special topics: coding interviews, web programming, etc…
- Choice A: Sensor fusion
- Choice B: LIDAR scanmatching
- Choice C: Visual odometry
Grades will be 40% in-class assignments and 60% homework assignments (evenly split between all the homework assignments, including the final project). In-class assignments will be 50% participation (meaning a non-trivial submission) and 50% correctness. Assignments will report their percentage completion through the auto-grader, with points given for completing objectives and points taken away for things like memory errors or inconsistent style.
For in-class work, the lowest score for a day’s in-class assignments will be dropped.
For homework, over all the homework assignments, 48 total cumulative hours of tardiness are “free”. After this, each hour an assignment is late (rounded up by ceiling) will reduce its maximum score by one percentage point (so 80% completion of an assignment 10 hours late would be 80% * 90% = 72%). The auto-grader will report these percentage calculations and keep your highest final score from any submission.
Accessing CAEN Computers
To have a consistent development environment for all users, we will be using the CAEN computers in our classroom space. No matter which computer you log into, your will have access to your files.
If you so like, you can also access the CAEN computers remotely from your own computer through the
While on campus run
ssh -X email@example.com your uniqid and enter your password and DuoMobile 2-factor authentication.
When off campus, instead use
ssh -X firstname.lastname@example.org.
-Xoption enables X11 Forwarding, which lets you open graphical programs over
sshand have them appear on your host computer. If you are running Windows as your host computer, you will then also need to install an X11 server to actually manage these windows. I recommend xming. If you don’t need to use a gui over ssh, you can omit this option. X11 Forwarding is pretty slow, though, so I don’t recommend it for general work.
The programs you submit, for both in-class and homework assignments, must be your own work, and significant similarity to other submissions will be considered highly suspect. Ultimately, the basic guideline is to be reasonable.
While working on problems, you are encouraged to search the internet to learn how to perform specific functions or techniques. In general, if you find a trivial one-liner on StackOverflow, you do not need to cite this. If you are copying a full algorithm, say for quicksort, you would need to cite this (or just use the standard library function qsort!). If that algorithm is a core objective of the assignment, however, then this would not be appropriate regardless of citation. Especially when you implement trickier algorithms or mathematical calculations, it can be wise to include a link to the original description of that method in a comment. This makes it easier to check or resume your work later.
You are also encouraged to get help from your peers. This means that after honestly trying to figure out how to fix your code, you may ask another student who has finished that section to look at your code and provide feedback on potential issues. When viewing another student’s code, however, the conversation should remain high-level and not be guided instructions on what to type. The most useful thing would be to point out flawed logic and allow the student to come up with the fix themselves. For earlier brainstorming of problem solutions, students are encouraged to discuss problems using a whiteboard or a sheet of paper so that they can later code unaided. You should not show your own working code to another student who is struggling to complete theirs.
If on the homework you get significant help from your peers, please consider adding a comment in your code saying who you collaborated with and what information was shared. This may help avoid potential confusion in similar solutions. However, since sharing of code is not permitted, we still expect the small details to be significantly different.
If it has been determined that students have flagrantly violated this policy, we reserve the right to respond severely.