To combat this problem, I began learning to program the Arduino using a library of code written in occam-pi called Plumbing. This allowed programs trying to handle multiple things at the same time to have only a few lines of code.

As the summer ended, I began trying to wire my own circuits and branching off to write my own programs with Plumbing. I am having trouble getting the motor in my circuit to turn on, and that is what I will continue working on this week.

This semester I will be leading eight intrepid students in an exploration of interface design and development at Allegheny College. Your open source project (or a small part of a larger project) could benefit greatly from these students, if you’re interested.

HOW YOU CAN HELP

I want developers/managers from “projects” that have a GUI. I say “projects” because you might be the lead on, say, a network settings dialog box that is part of Fedora. You need to be of the mindset that your GUI could always be better, but you never seem to have the time to sit down and do heuristic evaluations, sit users and do interaction testing, and so on. If we work with you, you also have to commit to being timely in responding to the students—most likely on your developer mailing lists—because we can’t wait for two weeks to go by in a 14-week semester while we’re waiting to hear back from you. (I’m not talking about 5-minute response times, but if you can’t reply to email from people trying to make your project better within 24-48 hours, please don’t respond.)

Basically, we ask that your community be reasonably responsive, and we’ll be doing all the work.

WHAT WE WILL DO FOR YOU

Small teams of students will, throughout the semester, engage one or more of these projects as budding interface designers. They have no prior experience in this regard, but will be engaging material on lo-fi prototyping, usability, the psychology of interface design, and so on. We will be discussing this material (which we will try and do in as open a manner as possible) and directly applying what we learn to the interfaces that are part of your project.

The students will work within your community, using your tools (mailing lists, wikis, etc.). I do not expect them to implement their designs, although some of them may be capable of doing so, and they might even do it. This, however, will not be a requirement of the course. (Not everyone in the course is capable.) If their work is good, and you like what you see, we only ask that you give their efforts serious consideration for implementation… we’re working with you because we don’t want to be doing interface design and testing in the abstract, but instead we want to add value to real projects through our efforts.

SOUND GOOD TO YOU?

Introductory splash screen and tools window with icons

When starting a new project the user is allowed to input the size of their Canvas to work on.

The size window

Once the user inputs the size, OSFA calculates the number of sprinkles and displays the Canvas. In the preferences window, the user can select whether they would like a grid to be displayed. Each square in the grid represents one sprinkle.

The user's canvas with a grid enabled

The preferences window

The user's canvas with the grid disabled

The user may then begin drawing their diagram. There are three different tiers that a user has to work with. If a sprinkle is designated as red then it will be the raised to the highest level when the image is converted to 3D, orange is the middle level, yellow the lowest. Therefore, the following 2D drawing:

will look like a rising and falling staircase in 3D, as can be seen here:

The above image converted to 3D

In the creation of their 2D image, the user has 3 different brush sizes available to them, 1×1, 2×2, and 3×3:

The user can also create 3D shapes: hemispheres, cones, and cylinders, as well as Braille labels. In order to create a 3D shape the user selects the shape’s tool and then drags their mouse across the sprinkles they would like to be included in the shape. The selected pixels will appear gray, like so:

In the process of creating a 3D shape

Upon release of the mouse, a 2D circle will appear that encompasses all of the sprinkles that were selected. The color of the circle denotes the 3D shape that will be created: hemispheres are green, cones are blue, cylinders are purple. Here is the 2D circle that was formed after the mouse was released in the above image:

The user can add as many 3D shapes as they would like:

Here is the 3D view of the three created shapes:

Also available are the eraser and clear all tools. They both do just as their name suggests. The eraser tool may also be used with any of the three brush sizes and, when dragged, rids of any tier colors that have been placed over the selected area. If the eraser tool is selected and then a 3D shape or Braille label is selected then that object is erased. The clear all tool clears the entire canvas.

Also, a user can open an image file. It will then be sprinklized and available for the user to edit with any of the features mentioned above.

Once a user is done they can use a tool bar option to send their image data to the Blender script which will render their 3D image for viewing as well as produce the STL file necessary for printing the object.

The bad news is that the airplane still has the tendency to nose down and to the left. We did a little bit more ground testing today to rule out the presence of crippling motor noise. We didn’t notice much change of the leveling reflexes between throttle off and throttle on (1-100%). We did a little manual linkage adjustment because the trim on the radio was slightly off from the trim on the autopilot (very possibly leading to a left turn). We also doubled the amount of elevator throw that the airplane has when trying to correct an improper pitch condition.

Hopefully the weather clears up soon so that we can fly…

Ian

Once we get level flight and turns debugged our goals for the near future involve implementing our airspeed sensor and including throttle control into the auto pilot.  Getting a working GPS is on the agenda too, but that is going to involve some help from Drew to get serial working how we need it to.

It when well until we brought the plane in for its first battery change. The plane was a little nose heavy from the sensors and had a hard landing. You can see the badness that this caused in the last post. We are working on repairing it though and expect the next flight to be Monday the 26th.

Just a quick idea of how it flew… It flew great under both R/C control, as well as autonomous control. As of now we only have level flight stabilization (roll and pitch), with no yaw correction. There was only minimal oscillation about the axes when put into autonomous mode, which means that we have the sensitivity set pretty well.

The first landing didn’t go so hot… Since we had a bit more weight up front with the sensors, it seemed as though the airplane was a bit nose heavy and came down faster than usual. Flying at Robertson makes it hard to get a nice long glide slope, which allows the pilot to get the plane slowed down in time for landing. On approach, the front wheel got caught in the grass and snapped the front part of the plane off. The wing also broke in the middle where the spars join up, but broke pretty cleanly so it should be a quick fix. The first two pictures are of the broken fuselage and wing, and the third picture is of the fuselage being fixed.