Web-Based RoboClaw Control For Test and Configuration

The first step in the journey to a HTML-based rover UI is to prove we can write something in Flask to allow a web browser to send command to a RoboClaw motion controller. The next step is to build something useful. Early on in SGVHAK rover project, that meant a technical tool to configure and test motor control parameters.

The goal of this tool is to simplify tasks done earlier via typing RoboClaw API commands into the interactive Python shell. As part of proving the browser interface concept, we’ll also try to make the interface usable from a touchscreen device. More point-and-click, less typing on a keyboard. We’re not putting too much effort into making the user experience pretty and polished, though. This is an engineering tuning and testing tool, not an end-user tool.

The advantages of using a web framework immediately paid off in the ease of building sets of motor controls. It allowed rapidly iterating through ideas to find the feature set that would be useful and discarding features that are not. There’s little wasted effort as we’re not worried about making things look good and are OK with primitive web 1.0 forms.

One downside is not the fault of a web framework, it is more a consequence of trying to fit a square peg in a round hole. Web apps are fundamentally focused on supporting large numbers of users, and here we’re really only concerned about controlling a single resource: the RoboClaw. Flask is built around some patterns intended to help developers write code that scales to high number of users & sessions. But in the context of this single-user, single-session usage, such patterns sometimes got in the way.

Another downside is a web-based interface inherits all the problems of the web. Inputs sent by a client is inherently untrustworthy and must be properly validated before processing. The web framework can help handle some of that with automatic protection of cross-site scripting attacks, but the developer is ultimately responsible for sanitizing the input before processing. In the context of an engineering tool with short expected useful life, it’s a problem we can set aside for now.


The proof of concept code discussed in this blog post is available on GitHub: testconfig.py under https://github.com/Roger-random/RogerPiBot

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s