Once we were confident our SGVHAK rover chassis control code looked pretty good, we were willing to trust that it could drive a rover without sending conflicting commands that make our rover try to twist itself into a pretzel. Now our focus turns to creating an interface for user control input.

A quick rough draft had been in place to help test rover chassis Ackermann math, letting a rover driver send a steering angle and travel speed to rover’s control code. But it was very tied to the current rover implementation: angle range was limited to angle range of what we have today, and speed was specified in raw quadrature pulses per second (QPPS) that we send straight down to RoboClaw motion controller‘s API.

Since we have ambitions for future rover variants, this direct dependency is not good. Future rovers may have a wider (or narrower) range of valid steering angles. They may also use something other than RoboClaw motor controllers. The answer is a typical software solution: abstraction!

This required changing the interface between our HTML UI front-end and the Flask-based Python code running on the rover. Instead of a fixed number angle or a fixed number of encoder pulses, user now send driving commands in terms of two percentages ranging from negative 100% to positive 100%.

For steering, -100% tells a rover to steer as far left as it could go, 0% is straight forward/back travel, and 100% is to steer as far right as it could go.

For velocity, -100% is travelling backwards as fast as it could, 0% is stop, and 100% is damn the torpedoes, full speed ahead.

Now when we adapt the code for future rover variants, we could focus on rover-side configuration and remain confident user-side HTML interface will automatically adapt to whatever capabilities are present on a particular rover variant.

This also allows us to experiment with user-side HTML without worrying about having to make matching changes in rover-side Python code. We can try different control schemes, as long as it ends up sending a velocity and steering angle percentage to the rover.

The first and crudest implementation of this concept is shown here: two HTML slider objects that move from -100% to 100%. The user can move the slider and tap “Send command” to rover. As the most basic HTML implementation possible, this is a useful test tool to isolate whether a particular control problem is in HTML front-end or in Python back-end, but it is obviously not a great driving interface.

That’s coming up next.

When we were putting together code to calculate Ackermann steering angles for SGVHAK rover‘s wheels, initial testing was done via Python command line using some fixed test values to match against results pre-calculated by hand. Once we built some confidence our math was on the right track, it was time to start testing against more varied inputs.

There was just one minor problem – at this point in rover development, our software is a tiny bit ahead of the hardware which means we can’t test on hardware that hasn’t yet been assembled. Even if we could, it wouldn’t be a great idea to jump from a small fixed set of test values to actual hardware. As an intermediate step, we created a bit of code to visualize results of roverchass.py calculations: the “Chassis Configuration” screen will show what our control code thinks all six wheels should be doing. (This shows the intent, which is different from hardware telemetry of what’s actually happening.)

Each of the six wheels got its own blue box, laid out roughly analogous to their physical position on the rover chassis. Originally wheel steering & speed was displayed as text: number of degrees a wheel should be steered, and a second number reflecting the intended velocity for each wheel. This was accurate information but it took some effort to interpret. To make this information easier to understand, numerical text was changed to a visual representation.

By using HTML’s <canvas> element, we could draw some simple graphics. Each wheel is represented by a black rectangular outline. A wheel’s steering angle is now represented by tilting its rectangle to that angle. Inside a wheel’s rectangle is a green fill representing desired velocity. When a wheel is supposed to be stopped, there is no green fill and its black rectangle is empty. When a wheel is supposed to be rolling forward, green rectangle fills from the middle upwards. Faster velocity is represented by more green in the upper half. For a wheel that should be rolling backwards, green fills downwards instead.

This visualization of roverchassis.py calculation results were far easier for humans to understand. This made it very quick to validate that roverchassis is behaving roughly correctly. There’s a place for precise engineering calculations, but there’s also place for a quick glance to check “yeah, that looks about right.”

One of the biggest changes in our new rover controller code is the goal of managing all ten rover chassis motors together, starting to think of the rover as a single unit instead of ten individual things.

This logic is centered in roverchassis.py, which is be responsible for calculating Ackermann angles for all steerable wheels in the rover, as well as calculating the desired travel velocity for each wheel. In order to make this code as flexible as we can, we offload details of rover chassis into configuration files and make our Python math as generic as possible running calculations based on configuration file values. This meant we could support rovers with different geometries without editing source code. This feature began with a desire to have flexible wheelbase and track dimensions of our rover chassis, but eventually extended to supporting similar but different configurations such as two-wheel differential drive.

Another goal was to support different types of motors and motor controllers. We appreciated all the features in the RoboClaw motor controller we started with, but we also thought about trading off some of these features for lower cost. In preparation for this flexibility, we kept roverchassis.py focused on general Ackermann-related math and kept motor-specific code in a separate class. In the first draft, this meant pulling all RoboClaw related code into roboclaw_wrapper.py which translates general concepts from roverchassis.py into specific commands in Ion Motion Control’s public domain API roboclaw.py. Later on we validated this flexibility by steering a single wheel with a RC servo followed by adding support for LewanSoul serial bus servos.

This was all possible using a flexible syntax in config_roverchassis.json that allows us to adjust wheel dimensions as well as switch out individual wheel travel or steering motors for different motor controllers.

When our SGVHAK rover project started moving beyond individual units of our custom wheel gearbox design and towards a multiple wheel chassis, it was happening on both the hardware and software fronts. Our Flask-based control UI has worked well up to this point, allowing us to tune RoboClaw motor controller parameters to suit our wheel design. Building this first draft UI taught us a lot, and as we learned we also realized how it reflected our ignorance at the beginning of this project.

And so we bid goodbye to our first draft rover UI RogerPiBot to start a new project SGVHAK_Rover. This way we retain all the testing & tuning capabilities of the existing software, leaving that as-is. Freeing us to create a new user experience.

The major changes are:

1. Simple touch-friendly controls instead of HTML forms with a lot of fields. The form was a very powerful tool for tuning parameters from a desktop workstation, but we’re getting out of the engineering test phase. All interfaces will now be tailored towards operation from a small touchscreen.
2. Rover as a unit instead of wheel as a unit. We need to start treating all six travel motors and four steering motors aboard our chassis as a single unit, as the user expects the software to do. Target audience for this software will not be interested in poke and prod at motors individually.
3. Configuration files instead of source code edits. The new software is built on the assumption that will be people who want to use it but is not familiar with Python or code in particular. Part of this meant configuration information will now be stored in human-readable JSON files at the root directory instead of asking people to go in and edit Python source code.

There were various other changes big and small. One of the larger changes was separate from the rover itself: we chose to switch away from using Bootstrap purely for the sake of HTML creation exercise. This time around we’re using a different library called Materialize to help create our responsive UI.

Our first attempt at rover software was a wonderfully informative hands-on adventure on creating a path from a cell phone’s web browser HTML all the way to serial bus commands sent to a RoboClaw motor controller. Fortunately or unfortunately, these lessons also put a finite lifespan to the software as we start to discover basic mistakes that we didn’t know we were making until we got a little smarter.

Before we leave the first draft behind, however, it had one final role to play. This point in software development timeline coincided with our rover wheel development’s completion. The actual six-wheeled rover chassis is still in the future, but our wheel development is mature enough for us to build a test chassis. Two wheel units were assembled and integrated into a bare-bones test chassis.

This chassis needed a brain and a controller.

To enable motor control via differential drive, we hacked together a minimal user interface for sending commands to our test chassis. Not much effort was spent on user-friendliness and its layout is very much an engineering number cruncher’s idea of an interface. (Also referred to as “bad UI.”) It was just enough to let us move the robot around and uncover some finishing issues in the wheel design, but not much more than that.

The robot moving under its own power attracted attention from other people in the work space. Naturally some asked if they could try driving the robot but one look at the interface and the response was “Um… maybe I’ll wait for a later version” and the phone was handed back.

No offense taken, it’s another vote in favor of moving on. We’ll close out the “RogerPiBot” project at this point and start a new rover control project incorporating all the lessons we’ve learned.

It was great when RoboClaw control UI project picked up help from somebody who knew what they were doing with web design. But it exposed a problem: the code is dependent on an actual RoboClaw motor controller connected to the machine. This was fine when development work focused on how to talk to the controller and hear what it has to say in return. But now that we have a parallel track working on improving the UI appearance, the RoboClaw dependency is unnecessary.

To remove this dependency, we introduced a RoboClaw API stub which could stand in for a physical RoboClaw when iterating through UI work. To do this in languages like C++, we would have to declare implementation of an interface and write a body. This makes sense when we expect all implementations of an interface to have roughly equivalent levels of functionality. For a test stub like this, though, that is not true. We only needed the small subset necessary to allow development of the specific relevant UI component. In languages like C++ this means most of the interface implementation would be tedious fillers that do nothing but raise a “Not Implemented” error.

Fortunately we are working in Python, which does not have such rigorous enforcement of interface implementations. We could implement just the methods we actually need to unblock UI development, and stop. There’s no need to recreate everything and we could leave out all superfluous “Not Implemented” declarations.

This is one arena where “duck typing” works in our favor, letting us get away with skipping all formalities of statically typed languages. There are downsides to dynamic binding but today it is a win.

Once we had a basic HTML UI for tuning RoboClaw PID parameters, we started exploring remaining surface area of RoboClaw API. In the arena of motor control, we have three categories of motion to choose from:

1. PWM or duty cycle: This is the most basic type of control, where the motor is given a particular amount of power regardless of its load. If the motor is unloaded, it turns faster. If there is load, the power level does not change so motor slows down (or stalls). Since the quadrature encoder is not involved in this mode, it is particularly useful when diagnosing problems and we want to eliminate encoder error as a potential problem. There’s also no PID turning required for this mode to work, so it is also useful when trying to verify whether a problem is caused by bad PID gains or not.
2. Velocity: In this mode, quadrature encoder activity matters. RoboClaw monitors encoder pulses and adjusts motor power to maintain the commanded velocity. If there is load of the motor, its slowdown will be apparent via encoder pulses and RoboClaw adds power to maintain commanded velocity. And conversely, when motor load is reduced and it starts speeding up, RoboClaw will see this in the encoder pulses and cut power to maintain commanded velocity. This is the mode we’ll use to control the wheel motors’ rolling travel. It requires a properly functioning encoder, at a high enough resolution, plus reasonably tuned velocity PID parameters.
3. 

   Position: In this mode, RoboClaw is told to move to a specific position and hold there. If external forces move the motor off its commanded position, RoboClaw will increase power to return to position and hold there. We will be using this mode to command motors in charge of wheel steering angle. In addition to the encoder requirement and velocity PID, there is a second set of position PID and both sets need to be tuned for a particular configuration.

Getting our bearings with RoboClaw motor control, we would first explore a tuning API from the command line then incorporate it into our HTML-based UI so we could rapidly iterate through parameter values.

The many iterations of this exploratory and tuning adventure (including all the mis-steps along the way) are publicly visible on Github.

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

Recent blog posts outlined the hardware side of SGVHAK rover project, now we’ll rewind and tell the software side. The first drop of information for the SGVHAK rover team included only information on hardware, the baseline rover software was promised and yet to come. We didn’t think too much of it until the Microsoft Windows-based Ion Studio tool failed to auto-tune the PID parameters for our rover wheel.

The effort to debug rover wheel control led to the Python API released by Ion Motion Control to communicate with Roboclaw motion control board. As a platform-independent tool, Python was always the ultimate intent since our target platform for rover brain is a Raspberry Pi. The failure of Ion Studio just advanced the timeline.

The manual PID tuning session was done entirely in the Python interactive shell calling into the Python API, from updating PID values to commanding motor motion. While flexible and effective, all the typing became very repetitive very quickly.  Now that we’re past the first PID tuning work session, we have a decent idea what APIs are most useful for this project.

We didn’t set out to design a new rover UI, originally we just wanted to ease building the machine and tuning parameters. This nuts-and-bolts goal is why investigation started with a text-based system. An advantage of a simple command line based system is that it can be used wirelessly via SSH so that we won’t have to be tethered to the robot while we tune. This is why we started by looking into Python’s curses library to create text-based displays.

It didn’t take long, though, before ambitions grew. The ultimate UI for the rover won’t be text-based, why learn a whole new text UI framework just so we’d have to learn a graphical UI framework later? That thought was just the first step. The next step looked at Qt, which is a cross-platform GUI framework we already know to work across PC, Macintosh, and Pi. But wireless networked access to a Qt GUI takes some work. Far more than it would take to put up some HTML to be accessed over the network. So… why not do that instead?

That’s how we arrived at today’s investigation: for a simple rover UI, try using HTML. This allows us to have the exact same UI over the network as well as locally. (http://localhost) We’re learning something new anyway, and learning a Python web framework is more likely to be useful for future projects than learning a text UI framework. To kick off this effort, we ask two questions:

1. What framework to use? There are a lot of different Python web frameworks running around on the internet. While learning Ruby on Rails, I came across references to its Python counterpart Django. They are both far heavier than we need for this project, though. A search for something more lightweight pointed to Flask, backed up by at least one Quora discussion.
2. Does it work with Roboclaw API? It took a little fiddling with user groups to gain access to the USB serial port, but once that was done the answer is: Yes it does.

With a successful smoke test, we’re going ahead with building a HTML-based rover UI.