[79FT]: Building Things

Bellcrank and Idler

Bending and twisting virtual metal


On: May 22, 2014
In: [Skybolt] Wings
Tags: CAD, lower wings, control system, ailerons

It's almost 5 am and Im finally done with the bellcrank alignment! Phew.

By the way, sheet metal stuff in Solid Works is amazing! You give it the bend lines, radii, and a couple more parameters; and it automatically creates both the bent item; as well as the flat pattern. Print the pattern, glue, and start bending -- it will show you which line, how many degrees, and in which direction to bend. Ill post one of those final drawings later, when I get around to printing them and bending some actual metal :).

Anyway...

The night started quite jolly with me whipping out the idler arm with it's bracket. Looks pretty neat, eh?

Aileron Idler Arm and Bracket

Aileron Idler Arm and Bracket

And then, back to the bellcrank hell. I had it modeled back in the days, and the "jog" bend 1/2 inches down made. Here's how busy the sketch with all the radii and holes looks BTW; pre-bending.

Bellcrank layout

Bellcrank layout

Anyway, with all the sheet metal awesomeness SolidWorks doesn't know how to twist. You can twist a model by using deformation, but at that point all kinds of shenanigans begin to happen. For example, all faces of the model stop being planar faces (meaning nothing can be sketched on them, and sketch is how you start defining a feature (part of the model)); for some reason I wasn't able to put a reference point into the center of one of the holes, etc. (I ended up drawing that point finally by projecting that hole's centerline onto one of the faces; that did work for whatever the weird reason Solid Works gods must have).

Bellcrank, bent and twisted

Bellcrank, bent and twisted

And after fiddling with it for about an hour, I was finally able to position everything. The plans don't specify where the bracket should be, so my educated and logical (yes, mr. Spock?) guess was that it should be so that the aileron pushrod connecting bellcrank to the alieron hinge is aligned and straight in the "aileron neutral" position. So I used the aileron hinge center as the reference; squared the bellcrank and aligned it that way. Note the blue line (that's actually a plane bisecting the aileron hinge), and the Point1 (that's that wretched point on the twisted surface that took me so long to figure out). That's what I used for alignment.

Bellcrank mated and aligned with aileron hinge

Bellcrank mated and aligned with aileron hinge

Coming up, putting in the idler, all the pushrods, and checking clearances with rib truss throughout the full range of motion. I strongly suspect that I will need the control stick's model on the fuse to do that, since that's what the other end of that pushrod attaches to. Oh man... gotta love those dependencies. That just means that I will have to do that model earlier than planned. Oh well. I like Solid Works anyways...

Tomorrow's the Shop Day! Gotta clean and put that compressor together.

OK 5:11 AM; time to go get some sleep :)


I had a fighter pilot’s breakfast - two aspirin, a cup of coffee and a puke.


Up ↑

Aileron-To-Rib - Alignment

Fixed mis-alignment in ailerons


On: May 21, 2014
In: [Skybolt] Wings
Tags: CAD, lower wings, ailerons

Today, got only about an hour and a half for CADing. Re-opened my Lower Wing model, 50% thru or so, and started remembering things and checking things around.

I was right at a point when I hung the ailerons on the wings, and this time was re-checking the alignment again, only to find that they were off! Looked like they were lower than the rest of the wing ribs, by about 1/16th. Clearly visible on the screenshot below.

Black lines are aileron outline, orange lines are wing ribs

Black lines are aileron outline, orange lines are wing ribs

Started digging around and re-checking the hinges, holes, etc, with plans. The 'spar' side hinges are the most complex ones, and they were fine.. When checking the aileron assembly though, noticed this, which struck me as odd (and a bit illogical):

Aileron hinge sticking a bit 'above' the spar

Aileron hinge sticking a bit 'above' the spar

Notice it sticking up? 3/32nds! Close to 1/16th. Arguably, there will be the filler there, but it still seems illogical (yes, mr Spock? :) ).

Anyways, moving the spar attach holes on the hinge up by 1/16ths (plans call for 3/8ths between the top of the hinge and the top hole center), so 5/16ths it is. That moved the whole aileron up on the hinge, and therefore, relative to the wing, and voila - a perfect match!

Match!

Match!

Yay! A perfect match.

Now, I know that in reality I will be drilling holes in spars in place based on the pilots in the hinges (or the other way around, hinges based on holes in spars (damn.. Im yet to decide.. :) ); but I'd rather start 'clean'.


Better to be on the ground wishing to be in the air than in the air wishing to be on the ground.


Up ↑

B-Log, The Nerd's Builder's Log

How I went about b-logging


On: May 20, 2014
In: [Misc] B Log
Tags: tools, software, website

Note: this article was updated in 2018 to reflect changes I did in version 2 of B-Log. I want to have a single article to link to in case people are interested...

Notes on the update are here.

The Problem

... was that I needed something to organize my builder's log. Being a software engineer by trade, I didn't want to go old school with paper logs and pictures, and whatever-random-collection-of-stuff-on-a-computer I could do. I wanted something that's easy to add entries to, calculates everything automatically, and allows me to publish it on the Web. Plus, I find it pleasant to view HTML as opposed to .doc, .pdf, or whatever.

Being a nerd, I just had to make it as nice for myself as I could...

The KitLog Pro

Many-a-builder is using this apparently successful piece of work. Apparently, as of writing this, they have over 1100 logs published on their mykitlog.com.

I have played around with it quite a bit. The program is trivially simple; but I can't stand the way it's architected.

  • Windows only
  • Uses Access database for storage (sic!!)
  • Only three pictures per entry (really???)

Oh, the Access databases. Basically, what this means to me as a user is if it ever .. erm.. decides to stop working, I will loose all my data. "Revert to a backup", you say.. Yes, but if the problem is that I can't add my N+1st record because the DB just corrupted itself, no backup will help -- I'm stuck.

On top of that if, god forbid, KitLog ever goes out of business, I am stuck with the data that I can't export w/o some serious reverse engineering.

No thank you. :)

The Early Attempts

So, I was toying around with other stuff.

BlogSpot

Really cool (probably, second best to WordPress) blogging platform. Plus, links very nicely with Picasa, making image inserts a breeze.

The problem? How do I track time spent?

Also, the "going-out-of-business" problem was still there...

Moving on...

A CMS (Drupal or Joomla or whatever) + custom plugins

Now, that was better. Those are open source, good content entry and organization tools, and I can export it all out of a MySQL DB should I need to.

But, they require a server (which means either I'm running a server, or require hosting). And frankly, I believed that there must be a better way...

Sphinx

Close, but no cigar. Sphinx is the documentation framework used by Python and many others (including the company I work for).

It takes a bunch of ReST files as input (more on that later), and runs them through a converter, producing whatever you want (there are writers for html, txt, doc, pdf, and so on). The parser and converter is called docutils.

The problem with Sphinx is that it's geared towards writing documentation, and frankly, felt a bit too heavy to me for writing a builder's log.

While googling about yet-another-thingie-I-wanted-to-figure-out-about-Sphinx, I stumbled upon an article that talked about static site generators. There lied the Holy Grail....

Mutilation of the Pelican

The Pelican. I fell in love with this thing almost immediately. Here's what it does:

  • Takes a directory with a bunch of ReST, Markdown, or ASCIIDOC
  • Parses all those files into internal state, obtaining metadata from both files and paths (ie, if you organize your files in category/<date>/name way, you can tell it to properly parse that path and populate the metadata)
  • Uses Jinja templates for generating a bunch of HTML output
  • Allows plugins and custom templates
  • Is all Python!

I did the initial version in 2014 (the date of this article). Then, I've spent about a week tearing it to pieces and figuring out how it works, and adding a few plugins to add things that I needed for the B-Log that it didn't have. I added time tracking, changed layout, got a Bootstrap-based template and modified it, etc.

In 2018, I fixed some suff and added a few more things.

You be the judge of results :).

Here's what I've done, in the end:

  • I'm writing text in ReST, so I've added the custom directive to it allowing for 'figures'. Problem is, ReST image directive produces HTML that wasn't much useful to present images the way I wanted them. Instead of modifying core Pelican code, I elected to add a custom 'Figure' directive. This is done as a Pelican plugin. This plugin also automatically adds thumbnails for images. This is the figure_process plugin. It also requires the image_copy plugin.
  • Another plugin I've written is image_copy. It enables sane handling of images placed next to the entries (pages and articles). Back when I started in 2014, Pelican wanted you to separate images and text (and it's internal mechanism of not separating them was broken back then). Pelican guys might've fixed this in the last 3 years, but hey, my setup worked for me - and I kept it.
  • And most importantly, the plugin that allows the bulk of functionality - the b_log plugin. It does a lot of stuff:
    • Generates the project structure ("Project / Section" concept with multiple projects)
    • Enables a special metadata tag to track time in an article
    • Loads and parses logfiles that don't have articles associated with entries
    • Calculates totals
    • Creates internal data structures for theme templates to use
    • Renders log pages
  • Then came theming. Pelican is geared towards bloggers, so I had to tweak a lot of things to be better suited for B-Logging (build logging, remember? :) ). In the process, I've switched to Bootstrap, since it makes it very easy to organize content on a webpage. I added theme templates to produce the build logs with totals, etc, etc. Also integrated FancyBox - a really cool JavaScript image overlay.
  • I added a couple of extras for myself - like silly QuOTD messages at the bottom of each entry - but that's not strictly related to B-Logging...

I like the end-result. I enjoyed hacking at it, and this was the first time I touched Python (so had to learn that on the way). Pretty neat (though I still prefer Perl (now, why do you need lists and tuples and sets again? :) ).

The only drawback is that it's regenerating everything every time. You can easily see how that might become a problem when you get a lot of entries, but I'm feeling like I'm ways away. 30 pages take about a second. I think I will need a lot of records before this becomes a problem; and at that point I will rewrite the whole damn thing to cache stuff.. probably :)

The code is here. The repo includes my theme, plugins, some tools, and sample content. It requires Python (I used 3.6 and did not test anything else), Pelican (which is checked into the repo in pelican/, along with it's dependencies), and Pillow (pip install pillow). Oh yeah, and pelicanconf.py's PATH_METADATA will likely require tweaking of slashes on Windows.

Read the config file (pelicanconf.py); and read thru Pelican docs to get the idea. sample-content/ contains my sample generated content that I was testing with. content-gen/ contains the simple Perl script that generates as much sample content as you want.

How it Works

To me as an end-user, it looks like this.

My source files are organized in directories like so:

/project-one/section-one/

        2001-01-01-entry-one/
                    entry-one.rst
                    picture.jpg

        section-one-log.log

/project-one/section-two/

        2001-01-02-entry-two/
                    entry-two.rst
                    picture.jpg

        section-two-log.log

/project-two/section-one/

        2002-01-01-entry-one/
                    entry-one.rst
                    picture.jpg

/project-two/section-two/

        2002-01-02-entry-two/
                    entry-two.rst
                    picture.jpg

and so on. Note the text *.log files - those are just log entries without the articles. They are optional, as you can see in Project Two.

Text log files look like this:

2011-01-01 | Some Summary Here       | 1.02
2011-01-02 | Some Other Summary Here | 2.02

Note the separator - that's configurable :).

There can be as many log files in a "Project/Section" as one wishes, they will all be parsed, and all entries will be properly sorted by date.

There can be entire sections without articles - but a project must have at least one article to be properly displayed. Yeah, you got to at least declare your intentions :).

This directory structure will get parsed into two Projects (Project One and Project Two) with their separate logs. Each project will get it's own menu on the left. To display the menus, B_LOG_PROJECTS_MENU config var should list them.

If there was any time logged in a project (either in article entries, log files, or both), that project's menu will get an extra "Log" entry, which will neatly display all log entries, and some totals.

There are a few special directories I use, pages (configurable in PAGE_PATHS) for static pages (ie, About section of this site is a static page), and blog, for blog entries (they don't show up under any projects).

If I want a new article-type entry, I just add a directory in the project/section path, and start writing the article in my favorite text editor (VIM!!). If I decide to log time, I just use my special logged metadata entry at the top of the article. I drop images into article's directory, and use my figure ReST directive to reference them.

If I just need to log some time without polluting the Internet too much with useless text, I add it to an appropriate .log file, or create a new one.

If I don't want to log time, I don't have to - I can just post an entry into the project w/o time logged.

After I'm done, I run Pelican, which generates the full website (html, images, everything!) into an output directory. Voila! I can stop right there, and I will have a fully working local version of my log, since it's all static HTML, but we want this online, don't we? So, the only thing left is...

Hosting

This was another revelation. Apparently, GitHub hosts static pages! 'Uploading a site' is a git push, and it transfers only deltas, so no fiddling with FTP, rsync, or whatever! They allow custom domain names instead of username.github.io, all you need is to set your A records in your DNS to point to their servers. It's awesome!

And So,

I am very happy with this so far. I have all my logs in practically plain text format, parser for which is open source and available. I have it nicely organized, and I can back it up as I please (to GitHub, anyone? :) ). I can re-write the programs that parse and produce final .html. I can extend the generator and change the theme to produce a printable version of the log, styled for paper rather than web. The list goes on!


Sorry folks for the hard landing. It wasn't the pilot's fault, and it wasn't the plane's fault. It was the asphalt.



Powered by B-Log, which is based on Pelican, heavily plugged and themed.

© Copyright "79FT". All rights reserved. Feel free to cite, but link back to the pages cited.

This website only shows how I did things in my various projects. These pages are for information and personal entertainment only and not to be construed as the only way, or even the perceived correct way of doing things. You are responsible for your own safety and techniques.