Also, FreeCAD needs a better interface, or at least better documentation. I still can't figure out how to draw a profile properly...let alone anything else it's supposed to be capable of.

I think script-based 3D will be more useful to us than model-based 3D. For example, OpenSCAD is being used a lot by the 3D printing crowd on thingiverse.com because not only can they exchange STL files, they can exchange the SCAD files themselves. That means someone can write a script that generates the specific gear they need, but instead of posting just the gear file, which will be useless to most everyone else, they can post the SCAD file and people can tweak the settings to make the gear they need without having to write the script from scratch. Script-based also allows people to build in dimension agnosticism. Since the final object is defined by independent and dependent variables, rather than by discrete points, all it takes is a single variable flip to change between imperial and metric (assuming they build that into the script). Additionally, it's important for the files to be watertight so that the CAM/CNC machines don't get confused. Constructive solid geometry, like OpenSCAD uses, ensures that. Other approaches can sometimes leave the model looking good to the human eye, but full of reversed normals and overlapping points and whatnot.

@Eukreign - Yes!!! Please do this, shoot me your e-mail in a PM and I'll send you a document that has some of my thoughts on that. Also you should e-mail the main guy at FreeCAD Juergen Riegel, he's a really nice guy and could likely help you work on your integration with FreeCAD as with time it will become quite good I'm sure.

I think managing the inputs of multiple users, potentially at the same time, will require a sort of turn-based approach. Like, the file will branch when peopel work on it and then can be "compiled" into a single, synced, file.

 

It seems like there should be sort of "views" you can switch between. Like one would be the text interface for the script, and another would be 2D views, and another would be 3D views. Maybe another one could be a "time" view where the parts start to move.

 

In terms of integrating the whole process right from the beginning, I think a script-based approach is best. So, each individual part would be modeled with instructions, like draw a box, then extrude the box, then draw a cylinder and subtract it from the box. That kind of thing. The individual parts would be assembled into a machine in the same way, like start with part#1 at this location in this orientation, then attach part#2 at this spot in this orientation. When the design of the machine is finished, it could be imported into new processes. Like, one of them would take each of the individual parts and come up with fabrication steps (additive, subtractive, etc) while another process would attempt to disassemble and reassemble all the individual parts to 1) see if anything is trapped in a place that can't be accessed and 2) create assembly instructions.

 

It would also be important to allow people to contribute different levels of detail. Like, some people figure out how to specify types of welds and grades of steel and whatnot, but most people can't. Some people can do complicated modeling, but most people can't. So there needs to be a way for some random guy to, like, define the overall spaces. The frame is this size, the cab is this size, the engine is this size, the wheels mount to the frame at this location, etc. Then he could plug in some preexisting models, like a power cube and some hydraulic motors. Then, because he can't do detailed modeling, he can just define a "hose" with beginning and ending points (the connections on the power cube and motor). Later, someone else can come through and add detail to the "hose" part like a properly modeled set of connectors and a long curving cylinder to represent the physical hose itself. Later, someone else can come through and specify what type of hose it has to be to handle the pressure/volume.

 

As for the project management process, I don't think OSE has any official process. It does seem like flexible prototyping is a core competency, so agile approaches make the most sense.

It seems like FreeCAD's "scripting", such as it is, really is nothing more than telling the program what you would have done if you'd been using the mouse. Just modeling a simple object requires a huge text file because instead of saying "draw a cube of this size at these coordinates in this orientation" you have to say "turn the program on, now move the mouse to this place, now click, now make another point, now finish the profile, now extrude it into a square..." that kind of thing. 

If you haven't used OpenSCAD yet give it a look. It's got a remarkably short learning curve. 

I figure the scripting really needs to be a process definition, like OpenSCAD, rather than an interface definition, like FreeCAD. But I might not be defining things correctly; I don't understand the code well enough to describe what's really going on.

Furthermore, given this development at FreeCAD: http://sourceforge.net/apps/mediawiki/free-cad/index.php?title=Assembly_project

It seems to make a lot of sense to just integrate tightly with FreeCAD and take advantage of the upcoming Assembly and constraints functionality. For example the Quick Connect Wheels would be a project with one part and specified attachment points (constraints). The LifeTrac will be an Assembly project which will have the LifeTrac frame and also reference the Quick Connect Wheel part, because of constraints we'll be able to actually correctly position the parts where they are supposed to go so that if you redesign the LifeTrac the Quick Connect Wheels will still show up in the correct place.

OpenSCAD will likely never have this functionality and using OpenSCAD models with FreeCAD models will always be a pain point.

FreeCAD can generate STL so there is no reason that it couldn't be used to produce CAM. A few people on #freecad have stated they use FreeCAD for making things to be 3d printed, etc.

And you can always do scripting with FreeCAD using Python.

If someone doesn't know programming and they learn OpenSCAD script their knowledge is limited but if they learn Python they can use it to model in FreeCAD and also contribute to the tool chain :-)

A simplified FreeCAD API can be created with Python to emulate OpenSCAD language. I don't think this is an issue.

FreeCAD can import STLs but then what? STL is such a limited format. You're basically importing dumb solids with no meta data, it doesn't even support giving colors to faces much less constraints for anchor points or anything else. For example if you did a part in OpenSCAD and then tried to incorporate it into a larger FreeCAD Assembly there is not enough information in the STL file to do that.

FreeCAD can be improved, I understand that's what the $400k is for in the budget: http://opensourceecology.org/wiki/Overall_Budget

DXF files are supported natively by FreeCAD (via opencascade) so no reason you couldn't use familiar tools to do part of the work, you just wouldn't get the nice integration with the PM system. I don't know how Assemblies would work though as far as editing parts in AutoCAD and then incorporating them back into FreeCAD Document and keeping the Assembly constraints for how all parts fit together...

We definitely can and should starting using existing project management tools. Scrumy is dead simple to use, don't even need to register for an account: http://scrumy.com

By starting to use Agile/SCRUM process now we'll all start to see what's missing or what we need in our own implementation of the collaborative engineering suite.

I've been playing around with FreeCAD and atfer a couple of tutorials, I think it's a good option. Of course, if we are going to compare it to solidworks, inventor or catia it's still a little back in developing...

What if we contact the developers to have some technical support? They could also have our feedback..