RobotBASIC co-developer John Blankenship accomplishes a lot in his “cluttered” Vero Beach, FL-based workspace.
He develops software, designs hardware, packages robot parts for sale, and write books and magazine articles. Thus, his workspace isn’t always neat and tidy, he explained.
“The walls are covered with shelves filled with numerous books, a wide variety of parts, miscellaneous tools, several pieces of test equipment, and many robot prototypes,” he noted.
“Most people would probably find my space cluttered and confining, but for me it comforting knowing everything I might need is close at hand.”
Blankenship co-developed RobotBASIC with Samuel Mishal, a friend and talented programmer. The introductory programming language is geared toward high school-level students.
You can read Blankenship’s article, “Using a Simulated Robot to Decrease Development Time,” in the March 2014 edition of Circuit Cellar. He details how implementing a robotic simulation can reduce development time. Here’s an excerpt:
If you have ever built a robot, you know the physical construction and electronic aspects are only the first step. The real work begins when you start programming your creation.
A typical starting point is to develop a library of subroutines that implement basic behaviors. Later, the routines can be combined to create more complex behaviors and eventually full-blown applications. For example, navigational skills (e.g., hugging a wall, following a line, or finding a beacon) can serve as basic building blocks for tasks such as mowing a yard, finding a charging station, or delivering drinks to guests at a party. Developing basic behaviors can be difficult though, especially if they must work for a variety of situations. For instance, a behavior that enables a robot to transverse a hallway to find a specified doorway and pass through it should work properly with different-width hallways and doorways. Furthermore, the robot should at least attempt to autonomously contend with problems arising from the imprecise movements associated with most hobby robots.
Such problems can generally be solved with a closed-loop control system that continually modifies the robot’s movements based on sensor readings. Unfortunately, sensor readings in a real-world environment are often just as flawed as the robot’s movements. For example, tray reflections from ultrasonic or infrared sensors can produce erroneous sensor readings. Even when the sensors are reading correctly, faulty data can be obtained due to unexpected environmental conditions. These types of problems are generally random and are therefore difficult to detect and identify because the offending situations cannot easily be duplicated. A robot simulator can be a valuable tool in such situations.
Do you want to share images of your workspace, hackspace, or “circuit cellar”? Send your images and space info to firstname.lastname@example.org.