The loop is the whole robot's brain, keep it simple and readable
Strip away everything else and a robot's behavior comes down to one repeating pattern: read a sensor, decide what that reading means, command the motors accordingly, repeat. For an obstacle-avoidance rover, that's: read distance from the ultrasonic sensor, compare it to a threshold, and either drive forward or pivot away. This is deliberately not a sophisticated algorithm, it's an if-statement, and that's the point. A first control loop's job is to prove the whole chain works end to end (sensor to logic to motor), not to be clever. Sophistication can come later, once you trust that a sensor reading reliably produces the motor response you expect.
Pay attention to loop pacing and blocking calls, concepts straight out of the embedded systems course. A function like pulseIn() for reading an ultrasonic sensor blocks execution until it gets a result or times out, which means your 'loop' isn't running at a perfectly fixed rate, and a timeout that's too long makes the robot sluggish to react to a sudden obstacle. Always set an explicit timeout, and treat a timed-out read as 'no obstacle detected' rather than leaving it undefined, an unhandled timeout is a common cause of a rover that randomly freezes instead of driving.