Bootstrap

Roger Cheng

Basic Motor Test for SGVHAK Rover

Our first opportunity to deploy the new Bootstrap-based touch-friendly HTML UI was a basic but critical motor test. A RoboClaw motor controller utilizes encoder feedback to know what the motor is doing. Based on this feedback, logic within the controller adjusts its electrical output to deliver either a commanded velocity or a commanded position. For any of that to work, an encoder must be installed properly. Our rover’s travelling wheel motors incorporated a pair of LED+photo diode units as optical quadrature encoders. Since we have a pair of sensors, there are two possible ways to wire them to RoboClaw input: one of which is correct and other is backwards.

To verify wiring, we need a basic motor test that will instruct RoboClaw to drive its motor at some power level, which is something it can do without encoder input. Then the test will query for encoder count and verify positive motor motion increments encoder count. If positive motion decrements encoder count, we’ll need to swap some wires.

Which wires need swapping? That depends on which way our motor is turning. We want positive motor rotation to correspond to forward rover motion, which means the left and right sides of the rover will be wired in mirror image. For rover’s right side wheels, positive motion will be clockwise (when viewed from rover’s right) and rover left wheels will be counter-clockwise. This desire to see the wheel motion in context of rover chassis is why we wanted this motor test to be usable on board the rover itself via the Raspberry Pi touchscreen.

If positive motor motion is rotating in the direction we want, and we need to swap wires, then we swap the encoder wires to maintain motor direction. If we need to swap wires and our motor is spinning in the wrong direction, we leave the encoder wires alone and swap our motor control wires instead. If the direction is wrong, and encoder is in sync, we’ll need to swap both sets of wires.

Basic Motor Test

HTML UI work described in this post began with this commit visible on Github.

Roger Cheng

Make RoboClaw HTML Control UI Scale Across Different Screen Types with Bootstrap

The basic HTML UI we were using to learn how to work with a RoboClaw motion controller was bare-bones web 1.0 in style. This worked very well when it only had to let us experiment to understand the controller while it’s sitting on a test stand next to the development workstation computer.

Once we got ready to move beyond tethered desktop computer scenarios, though, we had a problem. We had two touchscreen scenarios: one for UI directly on the robot via the Raspberry Pi Foundation touchscreen, the second scenario is remote control using a cell phone or tablet’s web browser.

Because the UI content was written in bare HTML, it does not scale to touchscreen devices the way we expect all modern web sites to do. In order to make this happen, we had to bring our HTML from the relative stone ages to conform to current practices.

Fortunately, this project received help from someone who has recently completed training on web design and development. [Amy] volunteered to jump in and make the controller HTML presentable and usable on touchscreen devices. Thanks to the open source nature of the web, most of the hard work has already been done by others and we just need to pull in one of the many freely available libraries to help build an UI that can respond to changes in the web browser environment.

For this experiment, [Amy] pulled in Bootstrap then began retrofitting the control test UI so Bootstrap can perform its magic across the different types of screens.

 

Link in Bootstrap

Roger Cheng

Let the App… Materialize!

materializecsslogoAfter I got the Google sign-in working well enough for my Rails practice web app, the first order of business was to build the basic skeleton. This was a great practice exercise to take the pieces I learned in the Ruby on Rails Tutorial sample app and build something of my own design.

The initial pass implemented basic functionality but it didn’t look very appealing. I had focused on the Rails server-side code and left the client-side code simple plain HTML that would have been state-of-the-art in… maybe 1992?

Let’s make it look like something that belongs in 2017.

The Rails tutorial sample app used Bootstrap to improve the appearance and functionality of the client-side interface. I decided to take this opportunity to learn something new instead of doing the same thing. Since I’m using Google Sign-In in this app, I decided to adopt Google’s design concepts to my client-side appearance as well.

Web being the web, I knew I wouldn’t have to start from scratch. I knew about Google’s own Material Lite and thought that would be a good candidate before I learned it had been retired in favor of its successor, Material Components for the web. One of the touted advantages was improved integration with different web platforms. Sadly Rails was not among the platforms with examples ready-to-go.

I looked around for an existing project to help Rails projects adapt Google’s design language, and that’s when I found Materialize: A library that shares many usage patterns with Bootstrap. The style sheets are even written using SASS, native to default Rails apps, making for easy integration. Somebody has done that work and published it as Ruby gem materialize-sass, so all I had to do was add a single line to use Materialize in my app.

Of course I still had to put in the effort to revise all the view files in my web app to pick up Materialize styling and features. That took a few days, and the reward for this effort is a practice web app which no longer look so amateurish.

Roger Cheng

Peek under the hood of Bootstrap

After completing Codecademy’s “Make a Website” lesson, I decided to go explore a side track to look under the hood of the Bootstrap framework used in the lesson. I’m not going to dive deep (yet), but I wanted to break it down into a short list of names I expect to encounter again as I explore.

The actual run-time components of Bootstrap appears to be two Cascading Style Sheet (CSS) files and one JavaScript (JS) file. One of the two CSS files is an optional theme. This confirms that Bootstrap has no client-side requirements, just a web browser that can understand standard CSS & JS files.

On the developer side, things get more interesting.

Grunt is the build system used by the Bootstrap project to build the project code, the documentation files, and run the unit tests.

It’s not clear if the JavaScript files are worked on directly, but the CSS is definitely not. It is done with Less and compiled to CSS. Some parts in the documentation listed “Less/Sass” implying Sass is a similar thing. Maybe look into this later.

Once the product is rebuilt, the JavaScript code is automatically reviewed by JSHint. Then tests are executed in the PhantomJS headless JavaScript runtime orchestrated by QUnit testing framework for JavaScript.

The product documentation pages were generated by Jekyall. Don’t know what the input for Jekyall would look like, but the output is static HTML pages. It claims to be the engine behind GitHub pages, so I know I’ll run into this again when I explore GitHub.

Several package managers were listed. Looks like NPM is required for actually working on Bootstrap itself, though it can also be used for projects consuming Bootstrap. Bower and Composer are two other package managers that seem to apply only to Bootstrap consumers.

That’s the first cut. Some things are still fuzzy, and some things I thought were clear may actually be wrong. We’ll see!

Roger Cheng

Codecademy “Make a Website” notes

I’ve just completed the “Make a Website” lesson on Codecademy, because it made sense to start at the beginning and (re)learn the fundamentals. I knew some simple HTML going in so I had expected part of it to be review and part of it to be new material.

The review part was expected: the lesson went over basic concepts of HTML tags and their hierarchical structure, then went into fine-tuning appearance via CSS.

But the new material was a surprise. After the CSS unit completed teaching about backgrounds and borders and spacing, it promised the next unit is about content and page layout. I thought “OK, good, now we’re getting into stuff I don’t know.”

The next unit began by introducing the Bootstrap framework to manage page layout. It was still an informative and fun interactive lesson, but I was left disappointed by the departure from HTML fundamentals.

It felt incomplete, like a math class that skipped doing addition with pencil and paper and instead going straight to using a calculator. Yeah, I’m probably not going to do it by hand ever again, but I wanted a lesson to teach me how to do it at least once. I would have preferred the lesson to go a bit into doing HTML layout the hard way, then say “Now that you know how to do it the hard way, let’s do it the easy way with Bootstrap.” Doing it both ways would give me a better feel of how HTML layout works and how Bootstrap makes it easier.

The Codecademy lesson worked as advertised, I’ll just have to fill this hole in my knowledge with something else.