Ideas

Roger Cheng

Trying New Format For New Screwdriver

When I created my WordPress account and started writing, I thought odds were pretty good that I would write a handful of entries and stop. This is the fate of most blogs! But I managed to keep a pretty good pace going for several years. I increased my tempo as I went. Starting from once a week and gradually up to a daily rhythm.

The daily posting system was good for keeping me moving forward. And to keep it from becoming a huge burden, I gave myself the goal of keeping each entry short. My target has been around 250-300 words which has been enough to communicate a single idea from beginning to end. Turning this blog into a project diary with daily entries kept myself moving forward on projects, because I keep asking myself: “Am I doing something worthwhile enough to write about?” This doesn’t always prevent me from wasting my time, but it helped tremendously. The project diary has also turned into a valuable resource for myself: whenever I want to reference back to something I’ve done before, I can search on this site and remind myself what happened.

But unsurprisingly, I would tired of keeping up a daily pace. I fell off my rhythm several months ago and while a bit of a break is expected, I haven’t been able to pick it back up again. Most recently I wrote about R2S4, my spent spool storage system project, but only for a handful of entries before another long pause.

The daily format is also a problem when I want to reference back to some part of a project but I didn’t remember exactly which part. Larger projects are spread across multiple entries, and I had to flip through each of them looking for the nugget of information I wanted. This became a huge problem on my biggest teardown project to date, the Canon MX340 multi-function inkjet. I learned a ton as I went, but that meant information is scattered so widely I ended up creating an index page just so I could find stuff. This situation is frankly ridiculous.

I have continued to tinker with various projects, but I haven’t been writing them down here. This is starting to become a problem: it’s been several months and I’ve found myself wishing I had written down some details I have since forgotten. I need to revive this project notebook.

I will try writing longer posts, but not necessarily daily. This means information on moderate sized projects (Like the follow-up to R2S4) will all be on one page instead of scattered across a half dozen daily entries, making it easier for me to find information later. And when I make progress on an existing project, I may adding to the end of an existing page instead of creating a new daily entry. This means it’ll take more effort to find updates now that they’re buried. Is such chronological information useful to keep in my project notebook? It’s been my primarily organization hierarchy for so long I won’t really know until I try going without for a while.

I will still have the scattered data/scattered timeline problem for larger projects like Canon MX340, or longer-term projects like Sawppy rover. I will have to reevaluate later. For now, I want to see if an alternative approach will help improve documenting more of my work.

Roger Cheng

Sawppy Dreams of Collaborative CAD

While putting together my presentation for the Space episode of Hangout and Nerdout, it occurred to me that I would be presenting Sawppy to an audience with a wide variety of backgrounds and would know many things I did not. Towards the end of the deck, I put in a slide asking for pointers to collaborative CAD tools. During the presentation I ended up skipping that slide because I got too excited blabbing about Sawppy and went over my 10 minute time limit. Fortunately, I had an opportunity to bring it up again during the Q&A afterwards when I was asked about user contributions.

The reality is that right now it that I don’t have an easy workflow for accepting contributions. I’ve been able to accept a few contributions in the form of edits for Sawppy assembly documentation. Two years ago, I wrote a series of blog posts about what I’d like to have in Sawppy documentation workflow. I posed my wish list to the audience of a Write the Docs LA meetup, and they were helpful in pointers to things I could investigate, but I never got as far as putting anything into practice.

And that was just for written word documentation. Accepting contributions in the form of CAD updates is a whole other ball of wax. Sawppy was designed in Onshape, a powerful web-based CAD system marketed to SolidWorks CAD professionals. I was entranced by the possibility that even $200 Chromebooks can be full power CAD workstations. Onshape has always had a free tier for makers, but that free tier is not their business focus and would occasionally disappear from Onshape website. As of this writing, Onshape free tier is back on their product list but that could change again in the future. When I started Sawppy, Onshape was a startup. They have since been acquired by PTC and free tier has a history of disappearing after startups are acquired.

Even if free Onshape tier remains available, it will always be limited to a subset of professional tier functionality. Which is unfortunate, because some of that would be useful for Sawppy to become a community-developed project. (To be clear, this is not limited to Onshape. Other products like Autodesk Fusion 360 similarly restrict their free tier capabilities.)

Sawppy dreams of a free CAD workflow with the following collaborative capabilities:

  • Tweak: Let people make minor changes without commitment of setting up and learning a full CAD workflow. For Sawppy, it would be very useful to make small adjustment to diameter of holes intended for heat-set inserts. Alex Glow brought up Thingiverse’s Customizer tool, which is an implementation of this concept but only applicable to objects designed in OpenSCAD.
  • Branch: Git style capability to create branches and merge changes back to main branch. (*)
  • Fork: GitHub style capability to let anyone fork a repository, make their changes, and create a pull request to propose merging their changes back to the original repository.
  • Diff: To evaluate those merges, we’d need to be able to visually compare the difference. CAD interchange formats like IGES and STEP use text files that would work within Git, but they are not designed to be human-readable. I would not be able to visualize the physical difference by looking at text changes in those file formats. Code-based CAD solutions like OpenSCAD are better in this regard, but it would be ideal to have a 3D view to compare changes. (*)
  • Review: Building on the previous bullet, we’d need to be able to annotate that view in order to have discussion before accepting a merge. Comments like “Why was this part lengthened?” or “Please change this fastener to M3x10mm.” This process would be analogous to a GitHub code review. Jinger Zeng brought up Wikifactory’s CAD Rooms capability, which at first glance looks very promising and worth further investigation.
  • Verify: automated software tests can be a part of verifying a pull request’s code changes. I don’t know if this concept has migrated to the professional CAD world. I would love to have automated checks to find problems without actually printing and building a rover.
    • I want to know if multiple physical parts are occupying the same space. (I think this is called “clash analysis” in professional CAD.) At a basic level it’ll check just the parts as they sit (and that alone would be valuable) but it’d also be nice to check for mechanical interference through entire range of motion of all joints.
    • Physical simulation to verify nothing has disconnected or hovering unsupported in space.
    • Mechanical simulation to verify all parts are still thick enough to support their intended loads.
    • Many more ideas! My imagination can run pretty far in this direction.
  • Document: And looping back to the earlier series about written documentation, CAD changes could require updating documentation to ensure information does not go stale and out of sync. For Sawppy documentation right now I have to remember to make updates manually. This is an error-prone process that has caused headaches for other rover builders as they read instructions that made no sense because I only remembered to update one place and forgot another. Computers should be able to help with the following tasks:
    • Update the construction BOM (Bill of Materials) to reflect CAD changes. (*)
    • Update illustrative figures in documentation by generating new CAD renderings.
    • Flag associated text for “is this still accurate” manual review to ensure they are not overlooked.

I don’t expect Onshape, Fusion 360, etc. to make this level of functionality freely available to makers. At this point my best hope is to find like-minded people who have done this kind of work in the open-source world. Failing that, I would have to learn an open-source CAD tool like FreeCAD and try to extend it. This will be a huge project far bigger than Sawppy itself!

(*) This exists in professional tier of Onshape, but not at the free tier.

Roger Cheng

Sawppy Documentation System Challenges

I want to improve the usability of Sawppy documentation. Keeping in mind some example problems I want solved I started my quest. To find a system to document and track these types of relationships, without losing too much of the advantages of my current system. This means every candidate system must meet the following challenges:

Challenge A: Easy to Contribute

When a Markdown file is hosted on GitHub, a potential contributor can click the “Edit” button to create a fork of the repository, make a quick fix, and create a pull request all via GitHub website. This presents an extremely low barrier to entry for contributors which is a feature I want to preserve. If contributors were required to install and learn some piece of documentation software, that would discourage many people from participating before we even talk about the learning curve for that software.

Challenge B: Easy to Manage

When using GitHub’s web interface to edit a Markdown file, visualizing the change is as simple as clicking over to the “Preview” tab of the editor. Sadly such ease can’t be matched by any system external to GitHub, but it would be nice to have some way to let a contributor see what the end results look like. Failing that, I must have a way to visualize the final impact of changes before I merge a pull request. It is unacceptable to not see changes until after merging into the main branch.

Challenge C: Easy to Query

The desired documentation system will take metadata written by document author and build an interactive presentation. This way rover builders can find information without being constrained by the current linear narrative. Here are some examples of questions I’ve received for Sawppy, rephrased in terms of wheel axle.

  • (Easy: positive query) I’m on the wheel hub assembly page, and it needs the wheel axle which I guess I forgot to build. Where do I need to go?
  • (Hard: negative query) My order of 8mm shafts got delayed. What can I work on now that’s not dependent on having these shafts?
  • (Both of above) How can a teacher most effectively divide up rover tasks so multiple students teams can build the rover in parallel?

Challenge D: Free

It would be nice for the system to be free as in freedom, but at the very least it must be free as in beer. Design for Sawppy is given away at no cost to rover fans everywhere, there is no profit to cover monetary expense of a commercial documentation system.

Once I laid out these challenges to the group and opened the meeting to discussion, people started offering suggestions. Some professional documentarians brought up DITA as a venue for investigation.