Improving a robot's ability to navigate the plane with Karel J. Robot
Commands is a poor name for this class.  It's a robot of some kind.  Better names would be EnhancedRobot or GridAwareRobot or CartesianRobot.
What is the point of the currentDirection member variable?  It's a write-only variable, and is therefore useless.
Reusing code via inheritance is always tricky business, especially here, where the Robot class that you are extending is a bit of a poorly documented black box.
The way you use super calls is confusing.  For example, a call to Commands.move(2) chains to Robot.move().  However, to ensure that the zero-parameter .move() method on a Commands object works consistently, you also override Commands.move() to chain to move(1).  If you were to add another level of inheritance on top of this, it could get very difficult to trace what calls what, especially with overriding and overloading involved.
In addition, you also have to be concerned that the superclass methods to move, turn, and pick/drop beepers don't always succeed the way you would expect.  Indeed, a robot can enter a &quot;crashed&quot; state if it tries to drop a beeper when the bag is empty, or if it runs out of bounds, or if it runs into a wall (see the World class).  Since the Robot offers no way to detect and recover from such errors after the fact, you must proceed with extreme caution with every action.  This is especially important since your Commands and the underlying Robot are keeping track of the state independently, and your information could get out of sync if you assume that everything has gone smoothly.
The Robot's capabilities are actually deliberately limited to one primitive action at a time to force you to build reliable state machines in these exercises.  By writing a move(int steps) method, you are, in a sense, missing the point of these algorithm-design exercises.  What should happen if, say, Karel runs into a wall after 2 steps of a move(5)?  Karel has no remote-sensing capabilities, so your options are:

Let it crash, and fail the exercise. ☹

Move 2 steps, detect that the front is not clear, avoid telling the Robot superclass to move the third step, and somehow give your caller a way to query the position of the robot and deduce that the move(5) only got partially executed.  This is better than crashing, but puts your user in the nasty position of figuring out what to do with a partially-executed command.
And how would the user figure out what state Karel is in after a partially-executed command?  You'll notice that the language you are allowed to use in these exercises is a restricted subset of Java: you aren't supposed to assign or compare variables (except in a counting for-loop).1  In a sense, you have already cheated in writing this code, by assigning variables.  But with this strategy, you would also be forcing your user to cheat too.

Move 2 steps, detect that the front is not clear, turn around 180°, move 2 steps, and turn around 180° again.  This is known as atomically failing.  This kind of behaviour would restore sanity to your user's algorithms: at least you would be assured that after a move(5), the robot is in one of two states (either five steps ahead, or not moved at all).

Endow your Commands class with a canMove(int steps) method to emulate remote-sensing capability, which you implement by carefully walking out and walking back.  Then, if the user calls move(5) and crashes, it's not your fault.


You'll probably realize that none of these strategies is palatable, and do your exercises using a dumb Robot after all.

1 Based on the reference in Karel the Robot Learns Java, Appendix A