Fusion 360 Lines Created Via API Are Not Limited To Sketch Plane

Cube on Sketch

Today’s performance tip helps avoid creating unnecessary planes and sketches when creating objects using the Fusion 360 API. First, some background: when sketching lines in Fusion 360 must be done in the context of a sketch object. This sketch object is in turn created to be aligned with a plane. It may be one of the default planes that intersect the origin (XZ plane, XY plane, or YZ plane) or a construction plane.

When sketching with the interactive UI, the user’s sketch entities are constrained to the plane of the sketch. For example, if a sketch was created on the XY plane, then all sketch entities would have a Z coordinate of zero. This makes sense to keep the data organized and easy to understand by the human looking at a 2D computer monitor.

When creating entities with the API, though, they are apparently not constrained. The first clue came from looking at the SketchLines.addByTwoPoints API – its two parameters are Point3D objects. A little experimentation confirmed the API would gladly accept 3D coordinates that lie outside the sketch plane. The example screenshot on this page is the result of drawing an one-centimeter cube on a sketch aligned to the XY plane. Only four of the eight corners (and four of the 12 edges) lie on the plane, but the API happily accepted all the information for a 3D cube.

This is very useful when creating geometries via code. Humans need to see points on a sketch stay in a plane for them to be workable on a 2D monitor screen, otherwise things get too confusing. But code doesn’t care about appearance on a screen. So go ahead – let code create complex 3D entities on a single sketch. Skipping the unnecessary planes and sketches will generate fewer API objects. Reducing object management overhead and allowing faster performance.

Accelerate Fusion 360 API Object Creation With DirectDesignType


Exploring the capabilities of the Fusion 360 API will involve experiments creating objects via script. Since it’s all code, it’s easy to repeat a process many times, a natural allure of using scripts to automate repetitive tasks. The downside is that Fusion 360 (as of time of writing) has problems resulting in slow response.

The sample code below creates an array of small cylinders one at a time. (This is not the most efficient method to create an array of cylinders but merely an illustration of the problem.) The size of the array can be adjusted by changing the value of arraySize before running the script. For a 4×4 array, the results are almost instantaneous. On a modern Core i5, slowdowns can be observed in an 8×8 array. The first few cylinders are fast, but as additional cylinders appear, each new cylinder takes longer than the last.

Fusion 360 performs a lot of bookkeeping overhead to track these operations. While the majority are outside our control, we do have control over the most expensive overhead: the timeline. It is useful when we are working with hand-created designs, but unnecessary for script – if we want to change anything, we’d update the script and run it again. In the user interface, we can click on the gear in the lower right hand side and select “Do not capture Design History”. To do the same thing in script, we can set the type of the design object to DirectDesignType. (Uncomment line in sample code below.)

This mitigates but does not solve the problem. While it is now practical to generate far larger number of objects, there is still a noticeable slowdown as the object counts go up. According to this forum post, this issue has been logged as a defect for the development team. Perhaps a future release of Fusion 360 will create the last object as quickly as it created the first.

import adsk.core, adsk.fusion, adsk.cam, traceback

arraySize = 8 # Will extrude arraySize^2 objects

def run(context):
  ui = None
    app = adsk.core.Application.get()
    ui = app.userInterface


    # adsk.fusion.Design.cast(app.activeProduct).designType = adsk.fusion.DesignTypes.DirectDesignType # Uncomment to turn off tracking timeline

    rootComp = adsk.fusion.Design.cast(app.activeProduct).rootComponent
    sketch = rootComp.sketches.add(rootComp.xYConstructionPlane)
    extrudeDistance = adsk.core.ValueInput.createByReal(1)

    rangeX = range(1-arraySize, arraySize, 2)
    rangeY = range(1-arraySize, arraySize, 2)

    for nowX in rangeX:
      for nowY in rangeY:
          adsk.core.Point3D.create(nowX, nowY, 0), 0.5)



  if ui:

This code is also available on Github.

Fusion 360 Script Engine Uses Python Version 3

One of the differences between Python 2 and 3 was changing print from a statement to a function. This means a Python beginner like myself immediately runs into the breaking change trying to print “Hello World!” to the console. (print "Hello World!" versus print("Hello World!")) It sets the tone pretty clearly up front: when working with Python, developers need to know which version they’re writing for.

Which is why I was very puzzled when I searched for this information in the Autodesk documentation and came up empty-handed. The most obvious place in my mind would be the “Python Specific Issues” page of the user’s manual, but it wasn’t mentioned there. Searching various other combinations of terms – on and off Autodesk’s web site – failed to find a straightforward answer. Given the relatively young age of Fusion 360’s Python scripting support, I would expect them to use Python 3 but I wanted confirmation.

Well, if I can’t find it in documentation, there’s always looking at the code itself. And a tiny baby step beyond the simple boilerplate script generated by Fusion 360. It’s not quite printing “Hello World” but it’s almost that simple.

First I imported the Python sys module for querying system parameters.

import sys

Then I changed the boilerplate message box output string to include the version number.

ui.messageBox("We're running on Python " + str(sys.version_info.major), "Version detection")

Executing the script confirms the scripting engine is running Python 3.


Once the web search engines index this post, people who have this question in the future will know the answer just by reading the title of this post on the search results. They won’t even need to click on the link to read this page.

(This really simple bit of code is almost not worth committing to Github… but it’s a slow day so it was pushed up to be publicly available.)

Fusion 360 Scripting: Learning Resources Overview

fusion-360-logo31I don’t know how much Autodesk expects their Fusion 360 users to write their own custom scripts, but Autodesk have certainly made enough information available free online for anybody to give it a try. Broadly, they are divided into three categories:

  1. Why“: the Fusion 360 API User’s Manual describes the overall concepts of how the API is designed and laid out. It is written to be the starting point before the programmer dives into actual code.
  2. What“: the Fusion 360 API Reference Manual documents the specific nuts and bolts of how a script communicates with Fusion 360. This is where developers go to find the small but important details necessary to write good Fusion 360 code.
  3. How“: Autodesk provides sample code so we can see some already-written scripts and get a feel of how they work. Some people may prefer to start with the code before (or possibly ‘instead of’) going to the concepts described in the user’s manual. But every learner will need to cross-reference the sample code against the reference manual to understand everything a sample does.

I appreciated the foundation laid out by the user’s manual. It left me feeling confident that I could march into the scripts and be properly oriented to understand what I’m seeing and how to find answers when I need them. Whether this confidence is misplaced or not is too early to tell at the moment.

One thing that I found interesting: Autodesk provides sample code of different styles across multiple venues. There’s a fairly large set of samples alongside the manuals on Autodesk’s own help website, but there is in addition a Github account “AutodeskFusion360” where script code is published. Some are samples, some are hackathon projects, and some are scripts that they’re released to solve some problems that customers have raised in the forums.

Together they cover a pretty wide spectrum of code to learn from, from simplified educational code snippets to complete scripts intended to run on user workstations.

Windows Subsystem Returns for Linux

One of the newest features in Windows 10 is the “Windows Subsystem for Linux” (WSL) allowing a limited set of Linux binaries to run on the latest 64-bit edition of Windows 10. It may be a sign of open-source friendliness by the new Microsoft CEO but for trivia’s sake: it is not a new concept.

The lineage for Windows 10 traces all the way back to Windows NT, built-in the early 1990s as a heavier-duty operating system (or according to some, “a real operating system”) to move upscale relative to the existing DOS-based Windows (“not a real operating system”). As consumer-level hardware grew more capable, the old DOS core was phased out and the NT kernel took over. Windows 2000 was the modest start, followed by the successful Windows XP.

But back when Windows NT launched, it was intended to capture the business, enterprise, and government markets with higher margins than the consumer market. At the time, one requirement to compete for government contracts was support for POSIX, a IEEE-defined subset of Unix. The software architects for Windows NT built a modular design that supported multiple subsystems. In addition to the home-grown Microsoft Win32 and the POSIX subsystem to meet government requirement, there is also a subsystem for IBM OS/2 to compete in enterprises that had invested in OS/2.

History showed those subsystem were barely, if anything, more than lip service. They were not used much and gradually faded away in later evolution of the NT lineage.

But now, the concept returns.

Microsoft has a healthy and profitable market in desktop software development with Windows, but is only a marginal player in the web + cloud world. The people writing code there are more likely to be using a Linux workstation or a Macintosh with its FreeBSD-based MacOS. In an attempt to make Windows more relevant to this world, they need to provide access to the already entrenched tools.

So just like before, Microsoft is building a Linux subsystem for business competitive reasons. But unlike the POSIX subsystem, they couldn’t get away with just lip service to satisfy a checklist. It will actually need to be useful to gain meaningful traction.

The method of installation is a little odd – the supported Linux distributions are listed on the Microsoft Windows app store. But once we get past this square peg jammed in a round hole, it works well enough.

Ubuntu in app store

WSL is not a virtual machine or even a container. The Linux executables were not recompiled for Windows, they’re the exact same binaries. And they’re not isolated – they run side by side with the rest of Windows and has access to the same file system.

Personally, I’m using WSL so I can use the same git source control commands that I’ve learned while working in Ubuntu. I know Github has a Windows GUI and associated command-line toolkit, but I expect running the Ubuntu git via WSL would work better with git outside of Github. (Bitbucket, Heroku, etc.)

This is a good start. I hope WSL has a real life ahead to help Windows play well with others, and not fade away like its predecessors.

First OSH Park Order Arrived

My first KiCad project was sent to OSH Park almost two weeks ago, and my digital design is now back in my hands in physical form. It is really quite exciting to hold in my hands a circuit board I designed. Three copies of it, in fact, as per usual OSH Park practice.

The first order of business is to check for simple mistakes. I pulled out my multimeter to verify that I have good connection between all the VCC pins to the VCC plane, and similarly all the ground pins are connected to the ground plane. Then I brought up my design in KiCad and checked continuity for the pins I designated. I don’t know if I exhaustively checked them all, but a large portion were verified.

Once I’m satisfied my design has been faithfully produced by KiCad, it was time to pull out the soldering iron. I thought I’d do some incremental tests – solder a subset of components to verify the subset of LEDs light up correctly – but I was eager to see it all light up so I went ahead and populated the whole board. The legs of the 2N2222A transistors in their TO-92 package were closer together than I’m used to in my soldering projects, but other than that challenge it was all simple and straightforward soldering.

Populated LED board

And finally, the moment of truth. I was working in Tux-Lab and a bunch of nearby guys gathered around to see me power up the board for the first time.

<drum roll>

It’s alive! The test pattern already programmed into the PIC started cycling through the LED display. This success is a great confidence-builder. I had fully expected to find problems with the board that I would have to fix in KiCad and send back to OSH Park for another set of circuit boards to be produced. The only problem I encountered was the PICkit 3 does not fit nicely alongside the power connector. I could make it work by making them wedge together at an angle. Neither were happy with it but it should be relatively rare to have the programmer attached.

Well, I guess break time from PIC software is over – I no longer have an excuse to play with other projects. The task of writing my I²C driver routine for this display is back on the to-do list.

Placed First OSH Park Order

After several revisions – including several PCB layouts that were restarted from scratch – I’ve learned a lot about using KiCad.  I don’t know for sure it’s all going to work, but I feel confident enough to make the first revision of my board. If it comes back and the board doesn’t work, I’ll have new lessons to learn. Or if it does, I celebrate!

Off to OSH park!

They have a very KiCad-friendly pipeline that accepts the PCB data file directly, no file conversion or data export necessary. I was worried about file format compatibility since I am running the latest nightly build and OSH Park only officially supports the most recent stable build. Some people have reported issues, but in my case it seemed to have gone through successfully.

The OSH Park verification screen is a great confidence builder. They took my file and generated these images for me to look over. This is awesome! I can clearly tell that it is my design and it generally looks fine. The resolution is a little lower than I would have liked. It is starting to be difficult to make out individual traces on my board, it would obviously be impossible to do so on a large complex board. But I assume detailed checks are not the point, we just need to verify we haven’t uploaded the wrong board and that nothing’s fundamentally broken in OSH Park’s interpretation of it.

OSH Park Verify

Upon checkout I was surprised that two Teensy boards were available as add-ons to my purchase. I don’t know why the circuit board fabrication shop is selling their own edition of the Teensy board, but since I had been thinking about buying one to play with anyway, it was an easy impulse buy to add a Teensy LC to the basket.

And now I wait. The board should arrive in two weeks and I won’t know what I need to fix in KiCad until I get the board and put it to (in)action. This puts a hold on the PIC micro controller hardware side of the project, and I can turn my attention to something else for a while.

(The work described in this blog post are publicly available on Github.)

Refining the LTC-4627JR Driver Board

I am lucky to have some local people who have worked with KiCad and were willing to help a beginner. I’ve asked for tips before I started, but much of them didn’t make sense until I had a run with my own project. Now I can go back and ask the questions again, and with some firsthand experience to anchor the concepts, the answers make much more sense.

I learned that there were flaws in my schematic. I had connected my PIC micro controller output pin directly to the base of a 2N2222 transistor. I shouldn’t directly expose the 2N2222 to the full voltage and current from the PIC. It is not an immediately catastrophic condition – I got my bread board prototype up and running without them – but in their absence the transistors end up burning much more power than necessary and likely reduces their lifespan. So the schematic receives five additional resistors, one for each transistor.

I also neglected a pull-up resistor recommended for the Vpp pin in the PICkit 3 manual. Again, my bread board seems to run OK without it, but it’s better to follow spec.

These six additional resistors complicate the PCB layout. Fortunately, I received some useful tips here as well. I chose one design pattern to practice: separate the front and back layers into vertical and horizontal traces. This requires copious use of vias to connect these individual segments into a full connection. I had been concerned that every via is a connection and a potential source of failure, but I’ve been reassured that’s not a concern. When the horizontal/vertical division, wire traces can cross paths in a safe manner because the directions keep those traces isolated.

I also learned the concept of a fill zone, which makes it easier to distribute the voltage input and ground to all the components on the chip. Instead of running individual narrow traces that might not be able to handle the full power, they are distributed across all the spare surface area I can reach. I use my front copper layer to distribute power, and the back copper layer became the ground layer.

The downside is that, by breaking horizontal and vertical onto their individual layers, it because much more difficult to visually follow the logic of a board. A situation not helped by the fill zones, which obscure other layers so I have to look at the front and back separately.



The upside of this approach is that it makes layout much easier to do. And despite the visual appearance, the net result is actually simpler despite being broken up across the two layers. Before learning these techniques my trace count was in the 180-200 range. Now it sits at 164 and this is after adding six resistors to the circuit complexity.

These are quite satisfying steps forward.

(The work described in this blog post are publicly available on Github.)

A Beginner Learns PCB Routing is Hard

Drawing up the circuit diagram/schematic was a new thing, but I got through it with minimal headaches and was feeling pretty good about using KiCad. After I was done with the first draft, I moved on to route all the connections to be placed on the printed circuit board (PCB). Doing this, I get firsthand experience that wire routing is a hard problem.

The first few connections were easy, but then it got progressively more difficult as I struggled to find a route for the later connections. The center of the board inevitably became a traffic jam and I started having to go around the jam. Every track that go around the outside perimeter of the PCB is a surrender that I couldn’t find a better way.

In addition to the traces going around the outside perimeter, another way to quantify my frustration with my circuit is the number of tracks in the KiCad PCB file. This is a number easily readable in the text format save file.

Fortunately, it doesn’t cost anything to learn by doing, redoing, and repeat.

The first attempt was a hopeless mess and I had to abort before I could connect everything. Here is version 2, where everything is actually connected with almost 200 tracks and multiple traces that go around the perimeter in a last-ditch effort.

LTC-4627JR I2C PCB v2

Version 3 changed the layout of the components in an attempt to make routing simpler. Moved the LEDs to the top, etc. It felt cleaner but is still quite a mess. I managed to avoid long traces that went around the left and right perimeters, but I still needed several at the bottom perimeter. And the track count didn’t improve by much – still just under 200.

PCB Route v3

Version 4 had the same basic layout as version 3 but I’ve learned to recognize a few signs of upcoming problems and could work to avoid them. The result had a further reduction in tracks, almost a 10% cut down to under 180. Plus I needed even fewer perimeter rescue paths.


The English language has the colloquialism “Paint yourself into a corner” and this is a very similar thing – it’s very easy to route yourself into a situation with no way out. I wish I could condense the lessons I learned into a summary here, but so far it’s just a lot of trial-and-error. Try something until I run into an obstacle, then try to figure out how to get out of this mess.

At this point the only words of wisdom I could offer is – dive in and try. It won’t work, but you’ll learn. Try and try again until you get good enough to get to a point where everything is connected, however inelegant it might be, and keep iterating to improve from there.

(The work described in this blog post are publicly available on Github.)

KiCad Circuit Diagram Schematic Editor (Eeschema) Amateur Hour

The KiCad Getting Started guide only covers the basics, but it’s enough to let the user embark on exploratory adventures to learn the rest of the tool piece by piece. I know I don’t have the knowledge and experience to do a good job at circuit design, but I’m a believer that such knowledge and experience is built up by learning from mistakes. So: let’s dive right in and try to implement the circuit board for my LTC-4627JR driver project and see what we learn.

The circuit diagram portion was relatively straightforward. Most of the lessons in the Getting Started guide applies, up to and including how to build a custom component for my schematic because the LTC-4627JR was not in the KiCad standard library. Somebody had built a library of components that included the LTC-4627JR, and made it available on Github. But this is a learning exercise and I wanted to learn how to do it myself.

The PIC16F18345 was not actually in the KiCad library, but a sibling part PIC16F18344 was available with a 20-pin DIP footprint, which is what I want right now. However, the eventual goal is to go to the surface mount version of the part and I hope I’ll be able to find another substitute with the same 20-pin SMD footprint.

There was no specific KiCad part for the 2N2222 transistor, but there are generic NPN transistors and I think that’s good enough. I was puzzled by the large number of options until I figured out they were different combination of a transistor’s pins. The three pins were labelled in order of pin number. So the variant tagged “BEC” has the base on pin 1, emitter on pin 2, and collector on pin 3. The “BCE” variant has the latter two pin swapped, etc. Looking at my 2N2222, I decided to use the EBC variant because that’s the order I see in the Wikipedia article.

The resistors were straightforward, as were the two I/O headers on the board. A four-pin connector for power, ground, and the 2 I²C wires. The five-pin connector is for the PICkit 3 to perform in-circuit programming.

From looking over schematics in the past, I got the distinct feeling of a stylistic convention for laying things out. Much like there are conventions for software source code. But a gut feel is not enough – I needed help from somebody to concretely spell out the rules. A web search for “circuit diagram conventions” pointed me to this article on Electronics StackExchange.

Armed with the list of conventions and a few hours to bump my head in KiCad, I got a passable basic schematic.

LTC-4627 I2C schematic

(The work described in this blog post are publicly available on Github.)

Notes on KiCad “Getting Started” Guide

To get started learning KiCad, I tried the obvious thing first: Go to the KiCad web site, click on “Documentation”, and click on “Getting Started”. This beginner’s tutorial walked me through drawing the circuit diagram schematic and then turning that abstract design into something that can be fabricated on a circuit board.

Because circuit board design is a fairly esoteric field, a tool like KiCad also has lots of terminology that’s a little tough for a beginner to digest. Thankfully the getting started guide helps put a lot of things in the context of the basic design process, so I could see words and phrases used in context and try to derive their meaning that way.

A lot of areas in KiCad were not covered in the tutorial, but that is to be expected. I just wanted the bare bones to start and I can explore other venues later.

The downside of learning a piece of software in active development is that it is still changing, throwing the tutorial out of date. Some menus were moved, though thankfully the keyboard shortcuts seem to have stayed consistent. Some parts of the software hasn’t only been moved, their icons had been changed. The tutorial occasionally gave instruction as “Click on the button with this icon” so when the icon changed, the beginner is lost.

(Workaround: Keep reading the tutorial to get a feel of what the next step is, what menu might pop up, etc. Then mouse-over each of the icons on the page and look for names that sound like they might be related to the activity.)

There were many of those minor annoyances, and there was one major annoyance. The guide had a section on how to generate a Bill of Materials (BOM)  using a plug-in module. The plug-in module was not installed at the location the guide stated. I went hunting on the KiCad Github repository to find the file, and once I downloaded it, it didn’t work with a bunch of error messages I had no hope of understanding.

Fortunately, BOM generation is not yet a priority for my usage. And I got far enough to draw a simple schematic and turn that into a simple circuit board design.

That’s good enough for a start.

KiCAD Tutorial


Tutorial circuit board

New Adventure in Circuit Board Design with KiCad and OSH Park

There are several things I can work on for my PIC-controlled LED practice exercise. The software is far from done, with lots of features I still want to implement. But I’m turning my focus to the hardware for the moment. Now that I’ve built a few iterations of my circuit on the prototyping breadboard, I have some confidence it’ll work for whatever software I write. So I’m going to look into translating the simple design into an actual circuit board.

When I started learning electronics many years ago this was a daunting step that I never took. Back then making my own circuit board meant buying sheets of copper-clad circuit boards. I would then need the ability to drill precise holes in this board for the component pins and I would need to etch my circuit into the copper layer. Either via precise mechanical removal or a chemical etching processes. This DIY fabrication was required because it was not economical for commercial circuit board manufacturers to do low-volume production for hobbyists.

Thankfully, the internet has enabled a solution. We now have circuit board fabricators who batch up many little projects from around the world into low volume production runs. The local electronics hobbyists speak well of OSH Park, who bills by the square inch and each order gets three copies of the circuit board. There’s enough demand for these services that OSH Park has competitors, both domestic and overseas, but I’m happy to start with the known quantity that has worked for people I’ve talked to.

The downside for this economical service is time: because of the job batching pipeline, it takes around two weeks from order submission to parts in my hand. Since I have more time than money to devote on these learning projects, I’m happy to accept this trade-off. It also means I should start the first iteration of my circuit board now: once I send the order, I will have two weeks to polish my software. (Or get distracted by other projects.)

kicad_logo_smallWhat I need to do to start this process is to translate my breadboard circuit design into something OSH Park can fabricate. This also used to be a huge barrier: industrial-level circuit board design software carried industrial-level price tags. Fortunately there’s a free open-source option in KiCad, whose development received a significant boost from CERN. It’s still considered beta software in active development but the current builds are good enough for me to get started.

It’s time to learn KiCad!

MPLAB Xpress vs. MPLAB X: Git Source Control

MPLab Xpress IDE LogoI loved the promise of MPLAB Xpress that someday I can do all my PIC development in the cloud. Even in today’s limited form, as long as I stay within certain boundaries I was able to work on PIC programming on a Raspberry Pi! But one downside of keeping the project sources up on Microchip’s servers is that they don’t currently offer any kind of source code version control. I understand why they might not prioritize it for the hobbyist crowd getting started in PIC programming, but version control is something I’ve grown used to having in my software development toolbox. And I occasionally miss being able to review and rewind certain things, even in the relatively simple beginner’s PIC projects that I’ve worked on to date.

MPLAB X logoSo after I inadvertently damaged my MPLAB Xpress Evaluation Board, I decided to graduate to using PIC chips directly without an evaluation board. This meant programming the chip using a PICkit 3 instead of the USB storage-based programmer on the evaluation board. And lastly – it also means leaving the web browser-based MPLAB Xpress and moving over to the NetBeans-based MPLAB X IDE installed and executed locally. One result is that the project files are now on my computer, which means I can bring git into the picture!

Obviously git can handle the C source files that I will be working with. What’s less obvious are the other data files in a MPLAB X project. What is worth tracking in version control, and what are easily regenerated as needed? Such information are usually described in a .gitignore file, but Github’s .gitignore collection does not include one for working in MPLAB X.

Fortunately, the MPLAB community has assembled one and it looks OK to me at first glance. I first dipped my toes using a project that was already complete, pushing it up to Github for archiving the sources. It also allowed me to test that all critical information is preserved, by deleting the directory and “git clone” anew to verify MPLAB X is happy with everything and didn’t complain about files missing from the project.

The second trial run incorporated git from the start, tracking changes along the way so I could see what was boilerplate generated by the tools and separate them from the (quite trivial) code I actually wrote. This test is also successful.

And now, trial run number three: take all the 7-segment LED control code I’ve been working on in MPLAB Xpress and translating them into a MPLAB X project in a way that tracks all the individual tasks along the way.

ROS Tutorial: Logging and Diagnostics

rosorg-logo1One of the primary motivations behind the Robot Operating System is helping robot creators avoid reinvent the wheel for every project. From my history of hobbyist robots, where I did build the software stack from the ground up every time, I was very happy to see the logging and diagnostics tools built into ROS.

No robot ever does everything right the first time. When things go wrong, the builder needs to figure out why. When the software stack is written from scratch, it means all the debugging tools will need to be written as well. Which means constantly asking the question: Should we build the tool? Will building it tell us what we need? Will it help solve the problem at hand? In end, will the work be worth the time investment?

When the robot system components are integrated in a ROS graph, that question goes away because ROS has the tools already at hand. There is a visualization tool (rqt_graph) to see which components are talking to each other. There is a tool that can record the messages and play them back. (rosbag) So on and so forth. The robot builder won’t have to reinvent any of these wheels.

These tools certainly looks promising and sounds great on paper, but I won’t know for sure until I build a project and try using these tools to debug my problem. I have high hopes but I’m also no stranger to things looking better on paper than in reality.

Final amusing note: The general ROS configuration diagnostic app is named WTF. (roswtf) I’m sure there’s a G-rated name for this thing (“Where’s The Failure” tool?) but we know the truth…




ROS Tutorial: C++ vs. Python Comparison

rosorg-logo1When it came to walking through writing actual code to build nodes in a ROS (Robot Operating System) network, the tutorial offered the reader the option to write the nodes in either C++ or in Python. I went through it in Python the first time around, then for curiosity’s sake, I looked over the C++ version for comparison.

The first glance was horrifying: Where the Python ‘talker’ sample was a small code listing with 20 lines of code, the C++ counterpart was sprawled over 100 lines of code. But a second glance quickly dispelled the impression: most of the lines in the C++ sample are comments explaining what’s going on. Comments are good! When counting the actual executable lines of code, the two samples are roughly similar in size, which surprised me as I expected the C++ version to have a lot more overhead as typical of a lower-level language.

A little reading of the comments and the tutorial page found the explanation: a lot of the tedious book-keeping that raw C++ programs have to contend with have been taken care of by Boost code libraries. This is how the C++ version of the demo ended up almost as concise as the Python version.

I still intend to continue my ROS education in Python, because I still think that’s an interesting way for me to train my Python programming muscles. But it’s nice to know that if I should ever need to do ROS coding in C++, I can get help to keep the complexities under control.

Historically I’ve been skeptical of C++ libraries – they are really wonderful when things work as designed, but when things go wrong things the code quickly become very difficult to debug. This may or may not be true for C++ code using Boost libraries, I’ll find out if I go there.

One trivial detail: the Python ‘talker’ sent out the current time but the C++ version just sent out a counted integer. Looking at the documentation of the ROS libraries, it looks like the time utility used by the Python version has a straightforward counterpart in the C++ library. Why wasn’t it used in the C++ tutorial to match the Python tutorial? It may just be simple oversight, but I wonder if there’s a more interesting story behind the scenes.

Getting Started on ROS: C++ or Python?

rosorg-logo1One of the items on my longtime to-do list is to investigate at least one of the publicly available robotics frameworks. Every robot project I’ve participated in so far has been a ground-up affair, everything built from scratch. At my simple hobbyist level I haven’t experienced a whole lot of tedious repetition across robots, but I definitely got far enough to see it looming on the horizon. My last robot (many years ago) was built around a very compact PC laptop as its brain, which made the project very powerful but also very expensive for its day. Today, I can get that kind of power in an inexpensive Raspberry Pi. Which happens to be one of the platforms supported by the Robot Operating System. So this is where I’m going to start.

I’m barely into the beginner tutorials but I see enough to appreciate what they have, and also to start having questions. I like the fact modules communicate over commodity network transports (TCP or UDP) and the master negotiation procedures are built around XML-RPC. It does add overhead but it’s the kind of overhead that allows a great deal of flexibility. But it is also a vulnerable security exposure. I haven’t seen anything talking about best practices to deal with rogue nodes on a ROS network but I hope that is coming up soon.

When the tutorial starts talking about writing code to create ROS nodes, it offers an option for the reader: write in C++, or write in Python? The prudent thing for me to do is to stick to C++, a language I know, while I learn ROS. If I go with Python I’ll be learning the programming language on top of learning the ROS framework.

Today I’m in a ‘chasing shiny objects’ kind of mood, so I’ll start down the Python path. Whether this turns out to be a wise or foolish choice is yet to be seen. Either way, it’ll be documented in upcoming posts!


Plastic Bottle Upcycling with TrussFab

Image from TrussFab.

A perpetual limitation of 3D printing is the print volume of the 3D printer. Any creations larger than that volume must necessarily consist of multiple pieces joined together in some way. My Luggable PC project is built from 3D printed pieces (each piece limited in size by the print volume) mounted on a skeleton of aluminum extrusions.

Aluminum extrusions are quite economical for the precision and flexibility they offer, but such capabilities aren’t always necessary for a project. Less expensive construction materials are available offering varying levels of construction flexibility, strength, and precision depending on the specific requirements of the project.

For the researchers behind TrussFab, they chose to utilize the ubiquitous plastic beverage bottle as structural component. Mass produced to exact specifications, the overall size is predictable and topped by a bottle cap mechanism necessarily precise to seal the contents of the bottle. And best of all, empty bottles that have successfully served their primary mission of beverage delivery are easily available at quantity.

These bottles are very strong in specific ways but quite weak in others. TrussFab leverages their strength and avoids their weakness by building them into truss structures. The software calculates the geometry required at the joints of the trusses and generates STL files for them to be 3D printed. The results are human-scale structures with the arbitrary shape flexibility of 3D printing made possible within the (relatively) tiny volume of a 3D printer.

Presented recently at ACM CHI’17 (Association for Computing Machinery, conference for Computer-Human Interaction 2017) the biggest frustration with TrussFab is that the software is not yet generally available for hobbyists to play with. In the meantime, their project page has links to a few generated structures on Thingiverse and a YouTube video.


Building with Acrylic: Thickness Variation

Thickness failIn the previous post, the laser cutter kerf was successfully compensated, admittedly in a way that left plenty of room for improvement in the future. This post will look at a different challenge of building with acrylic: variation in thickness of acrylic sheets. So far experience showed different sheets of “6 mm” acrylic can actually be anywhere from 5.31 mm to 6.03 mm.

Since most laser-cut acrylic projects are 2D in nature, any variation in acrylic sheet thickness usually goes completely unnoticed. But when building 3D structures out of multiple interlocking pieces, the thickness dimension has a significant impact.

Fortunately for us, while thickness can vary across different sheets, the thickness is relatively consistent within a single sheet. There may be some variation from one corner of a 4′ x 8′ sheet of acrylic to another, but once cut into smaller pieces that can fit in a laser cutter, the thickness can be reasonably treated as constant.

This allows us to treat thickness as a parameter in a Fusion 360 CAD file. Any slots cut for acrylic pieces will need to reference the parameter. So that when it comes time to generate the cutting profile, the thickness parameter can be updated with the thickness of the actual sheet of acrylic, and Fusion 360 will automatically recompute all the slot widths to match.

Which brings us to the attached picture illustrating human error: the assembly on the left is built up to the proper dimensions. In contrast the assembly on the right was too thin. I made the mistake of measuring on one sheet and cutting on a different sheet that turned out to be 0.29 mm thinner. 0.29 mm is a small difference, but when the assembly is built by stacking seven pieces together, it results in a significant dimensional error of over 2 mm.

Building With Acrylic: Kerf Compensation

After learning my 3D printer’s inability to hold dimensional tolerance, I went back to practicing building with acrylic. Laser cutter kerf may be annoying but it is at least consistent. Now that I know my choice is between a consistent kerf or an inconsistent extrusion width, I choose to deal with consistency.

A bit of Google confirms laser cutter kerf compensation is a fairly common problem people have sought to deal with. What’s less common are actual practicable solutions for designing 3D structures intended to be built up from laser-cut pieces of acrylic. While 2D work on a laser cutter is common, construction for 3D structures appears to be less so.

A laser cutter workflow usually ends in a series of vector graphics commands. Common formats are DXF, DWG, SVG, and PDF. All are good for describing lines, but they only describe where to cut. They don’t contain information on which side of the line is the desired output. So while it is possible for an automated script to offset all lines, it doesn’t know which direction is “inside” vs “outside” in order to perform the proper offset for kerf compensation calculation.

The CAD software (Fusion 360) knows this information, so I thought it’s an obvious place for such mechanism to exist. Google knew of people who have devised some very clever workarounds to make it happen, but not an actual feature in the CAD software itself. Before I started using other people’s workarounds, I thought I’d try to do it manually first, adding to the kerf amount to the dimensions of individual components to CAD.

The result was very encouraging, the laser cut pieces came out at the desired dimensions and pieces fit together with their edges well aligned. This validated my manual process but added mystery. What I did was tedious for a human, simple for a computer, but for some reason the software doesn’t do it. Perhaps I will find out why as I continue learning about laser-cut acrylic construction.

Successful kerf



Unity exploration on hold

After an intense few weeks with Unity, I’ve decided to put it on hold and come back to it later. The biggest problem is that, even though it can output to web browsers via WebGL, it is extreme overkill for projects that can be easily handled via Plain Jane HTML.

As an Unity exercise, I pulled art and assets from the old game Star Control 2. This was possible because (1) the creators of the game released the code in 2002, and (2) I’m no longer working at Microsoft. I was aware of the code release when it occurred, but my employment as a Microsoft developer at the time meant I could not look at anything released under GPL. Even that of an old game with zero relation to the work I’m paid to do.

Since it was a simple 2D game, bringing the assets to life using Unity severely underutilized Unity capabilities. That isn’t a problem, the part that gave me pause is that the end product is a lot heavier-weight than I thought it would be: Even when there’s only a few 2D sprites animating with some text overlay, it is a larger download with correspondingly slower startup than I wanted to see.

Given what I see so far, Unity is the wrong tool for this job. Now I have a decision to make. Option #1: Keep digging in on an old favorite, and work on SC2 code using some other framework, or Option #2: Find a project that plays more to Unity’s (many) strengths.

Option #1 goes to the past, option #2 goes to the future. (Specifically VR…. Unity is great for exploring VR development.)

Today, I find that I’ve caught the old SC2 fever again, so I’m going with #1. I’ll come back to Unity/VR/other explorations later.