Notifications
Clear all

ESP32-CAM Robot Car - Thoughts on the software and User Interface

1 Posts
1 Users
0 Likes
790 Views
jBo
 jBo
(@jbo)
Member
Joined: 3 years ago
Posts: 100
Topic starter  

First off, none of this is meant as any criticism of the design of the project, the libraries from Espressif, or the robot car code as provided. Congratulations to Bill et al at @dronebot-workshop for a great project. I'm actually thinking of building a second one so I can show my wife and have a "race" around the living room. It's just that software types are tinkerers, so I have trouble seeing an interface without thinking, you know, what if I put an extra button over there and . . . .

So here are some points I thought about; others may have already considered some of this. I should also add that I purposely have not looked deeply into the code yet, trying to separate requirements from design.

* We cannot hold a button down on cell phone or tablet. We can only press it. So each "click" or button press is just one unit of driving. It's definitely still fun as a game; however, it might be nice to see what else could be done for a more pleasant commute.

* Assuming we only get one "unit" of driving for each button press, one way to get more driving is to increase the motor speed. This is already in place in the existing code, and works great. Another possibility is to increase the driving time, the duration, how many milliseconds the motors stay on. I would add another slider control for this driving duration. Like the motor speed, it wouldn't need to be labeled in any units. As a first guess I would set it from 300 ms to 2000 ms or 2 seconds. Set for full duration, this allows a satisfying bit of travel. Unless, of course, I've run it into a piano leg, laser printer or some such. 😣 

* The "More Travel" buttons. The slider idea for driving duration would work, but some might feel it is not interactive enough. That is, the user might find it inconvenient to change the slider very often. Another possibility is to keep the 4-way arrangement of forward, reverse, left turn, right turn, but enhance it, augment it. For instance, above the Forward button, place another button which goes forward twice as fast, or twice as long, or some combination, and label this button "Turbo Forward" or "Boost" or something. On the bottom end, below the Reverse button, place another reverse called "Fast Reverse." To the left of the Left button, place a button which turns more left, and so on. To be clear, the touch screen of a phone or tablet is not a joystick; still, some of the capabilities of a joystick can be obtained.

* Buttons at the NW, NE, SE, SW positions. The previous button ideas are all based on the layout of buttons in a North, South, East, West pattern. These are good, and found on many game controllers. However, some game controllers also have buttons on the diagonals, that is, northwest, northeast, and so on. What would this mean for the little robot car? A relatively simple enhancement might be that pressing Northwest, the button between Forward and Left, results in turning left one unit, and then driving forward one unit. This is cool, and it might be useful enough that the user would want to use it. Another variation of "Northwest" is that the car drives forward one unit, but gradually curves to the left. This has the potential to be smoother driving than the turn-stop-forward-stop method, though it is a potentially more complicated algorithm.

Better stop now. While still using the touchscreen of a cell phone or tablet (not standalone game controller), has anyone thought up any tweaks to the user interface?

In theory, theory and practice are the same.
In practice, they're different.


   
Quote