Software Libre e Ingenieria

Free Software and Free Hardware Designs

admin — Wed, 18 Nov 2009 16:57:16 +0000

Article original from: here

A very large number of people now accept Richard Stallman’s arguments about the social benefits of free software. I am claiming that these arguments also apply to hardware design.
Richard Stallman’s classic article Why Software Should be Free is built around three key themes concerning the harm caused by restrictions on copying, changing, and building on software:

Three different levels of material harm come from such obstruction:

Fewer people use the program.

None of the users can adapt or fix the program.

Other developers cannot learn from the program, or base new work on it.

These three themes apply equally, though in different ways, to hardware and hardware designs.
1. Fewer people use the hardware or hardware design
Stallman’s argument for software is based on the vanishing cost of reproducing software: basically it says that if fewer people can afford the software, fewer will use it.
The cost argument strictly applies to software in its executable form. It also applies in theory to designs for FPGAs or CPLDs, but in practice the relevance is small in this case since few people have programmable logic boards. It does not apply to physical hardware – yet. However, it may well apply to hardware in the future, since a proportion of hardware costs are development costs, and reducing these by increased use of shared designs should reduce overall costs.
Yet the argument still applies on other grounds than cost. The market for some types of computer hardware is limited by the fact that it cannot be used with free software, since the interface definitions are kept secret. This is the purpose of the Open Hardware Certification Program. However, this program has limitations:

* It works after the fact: first a device is produced, then a manufacturer applies for certification. Devices manufactured from free hardware designs would automatically make interfacing information available, encouraging a faster spread of open hardware.
* The amount of information that the manufacturer is required to give to achieve certification is quite limited. It was once quite common for circuit diagrams of such devices to be made available by the manufacturer. The Open Hardware Certification Program acts as a validation (even for manufacturers friendly to free software) that there is no reason to return to this state of affairs.
* The program has no impact at all on devices that cannot be used directly within a computer.

In addition to the direct limitation in number of users that with-holding of design information is starting to cause, there is also a more indirect effect based on the availability of the design rather than the physical hardware. If design information is made available, then it is possible for other manufacturers to second-source the design. Where hardware is not second-sourced it is less likely to be used. This fact has long been recognised by hardware manufacturers. Long before Sun’s current use of their ‘community source license’ for the SPARC, the SPARC specifications were made available for second-sourcing by other manufacturers. This is one of the few weapons available to manufacturers in a situation of near-monopoly. Without it, a manufacturer who dominates the market, even with an inferior product, is likely to move towards a situation of full monopoly.
2. None of the users can adapt or fix the hardware or hardware design
Clearly not all physical hardware is adaptable or fixable. A manufactured IC, for example, cannot normally have its functions altered, and certainly cannot be repaired when broken. Yet this argument is still of major importance, and applies both to board-level designs and to easily implemented hardware of other types.
`Fixing hardware’ is something that was once extremely common. Nowadays, broken hardware is commonly simply thrown away. The social and environmental costs of this are huge. Some reasons why modern hardware is not repaired are related to technological change: it is almost impossible to desolder fine-pitch surface mount designs, or repair multi-layer boards. But another reason is simple lack of information about devices. If it once again became normal for proper circuit diagrams of boards to be made available, so that even a small proportion of faults could be fixed, the savings (financial, social, and ecological) could be huge. With free hardware designs, even greater changes could become possible: `design for test’ is a common feature of closed-source hardware design; `design for repairability’ could become a common feature of free hardware design.

Being able to fix hardware is a general social need. `Adapting hardware’ is something that only electronics engineers or hobbyists are likely to want to do, but is still important. A typical example is the repeated complaint on electronics newsgroups that a device programmer cannot be made to work with a new version of device, not because it is physically incapable of doing so, but because there is not enough information available to adapt the programmer (where in this case ‘adapting’ would mean altering the firmware).

More important is the ability to adapt designs. In current practice, a hardware design belongs to the company which created it and is known by no-one outside the company (excluding the reverse-engineering industry – itself an example of the waste of energy created by the proprietary design system). Improvements to the design can therefore only be made by people within the company (in the extreme case, if the company folds the design dies with it). Free software has shown that it is possible for software to evolve steadily over the years as amendments, improvements, and bug fixes are made available from a very large range of contributors. There is no reason why the same should not be true for hardware designs. Without it, we have had phenomena like the acceptance of video players with user interfaces so unfriendly they became a joke for years.
3. Other developers cannot learn from the design, or base new work on it
It is in this area that there are the closest parallels with software, and rms’ words can be repeated almost verbatim:
Restraints on the use of existing designs tend to prevent the accumulation of knowledge that comes from building on previous designers work, making it necessary to start from scratch when developing a design. They also prevent new practitioners from studying existing designs to learn useful techniques or even how large designs can be structured – apart, of course, from those within companies who have a history of their own designs to build on, or the equipment and time to reverse-engineer the work of others.

The same restraints also obstruct education. As time has gone by, students are still likely to be familiar with and taught the use of 74 series logic devices – dating from the 1970s, and documented in the excellent Texas databooks. Many students are excellent at carrying out the small designs possible with these devices (designs completely untypical of the majority of contemporary practice). They may also be familiar with the implementation of small designs for FPGAs or ICs. They are far less likely (except in the very largest universities with commercial connections) to be familiar with the inner workings of any of the more recent devices they may actually use in their daily life – even for engineering students, these have largely become `black boxes’.
The result is a tendency to exaggerate a split between teaching and the real life use of technology, and a consequent steady decrease in interest in electronics among students. On those occasions when students are able to work on `real-life’ designs, it will be subject to commercial backing and so to NDAs and all the general restraints on disclosure of information which was once central to the function of universities.

Outside the area of education, the fact that it is not legally possible to base new designs on those created by others creates huge amounts of wasted and unnecessary effort. It has also become increasingly impractical as the time-to-market for new designs shortens. The result has been the attempt to create a market in hardware `IP’ decoupled from the market in physical hardware, a growth in fabless design houses, and in semiconductor fabs not tied to any one design company. But the growth of this market has been very slow, since all the participants want to make sure no-one gets their `IP’ for free. Problems such as: how to encrypt or otherwise ‘lock down’ of IP (since no-one fully trusts the legal system); quality (since no-one knows how to guarantee that the ‘IP’ which has not yet been shown is of a reasonable standard); and mergeability of cores from different suppliers (since there are many different proprietary standards involved), have all made the creation of a genuine IP market difficult.
This is an area where free hardware designs can flourish: no requirement for encryption; quality can be assessed freely; and just as free software has been shown to be an excellent driver for the spreading standards, so free hardware design can be expected to do the same in this field. And above all, once designs are no longer ‘closed’ the rate of development and improvement can be expected to increase, as some of the energy currently put into developing similar designs from scratch in many companies at once is transferred to developing completely new designs and improving commonly available ones.
Conclusions
All three of Richard Stallman’s original justifications for free software apply, in different forms, to free hardware design. The argument that in spite of this free hardware design is impossible for cost reasons is based on the cost of reproducing physical hardware, not on the cost of reproducing designs, and so is not directly relevant. In spite of differing over this point, the FSF is still broadly sympathetic to the development of free hardware designs. Creators of free hardware designs should return the sympathy: free software and free hardware design should stand together; they have the same roots.

A Robust Inexpensive Multi-Purpose Robotic Arm

admin — Wed, 18 Nov 2009 16:51:02 +0000

Alana Lafferty
UAP Report
UAP Advisor: Professor Rodney Brooks and Dr. Una May O’Reilly
May 20, 2005

Rigs of Rods, Open Source vehicle simulator

admin — Mon, 16 Nov 2009 21:13:37 +0000

Rigs of Rods (also known as RoR), is an Open Source truck, car, airplane and boat simulator. You can drive, fly or sail in total freedom in an open environment. What makes RoR different to most simulators is its unique soft-body physics: vehicles chassis and wheels are simulated in real-time as flexible objects, giving the simulation an extremely accurate behavior, while allowing the vehicles to be simply specified by their structural composition, as a network of interconnected nodes (forming the chassis and the wheels). Crashing into walls or terrain can permanently deform a vehicle in a realistic manner. In addition to its unique soft-body physics, RoR also features an advanced flight model based on blade element theory, allowing the accurate simulation of any airplane, base on their physical dimensions and wing airfoils. It also features an accurate buoyancy model based on elemental pressure gradients, enabling boats with complex hulls to move realistically in the swell.

RoR is highly moddable: currently there are 2073 mods for RoR.

OGRE, Object-Oriented Graphics Rendering Engine

admin — Mon, 16 Nov 2009 10:16:08 +0000

OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, flexible 3D engine written in C++ designed to make it easier and more intuitive for developers to produce applications utilising hardware-accelerated 3D graphics. The class library abstracts all the details of using the underlying system libraries like Direct3D and OpenGL and provides an interface based on world objects and other intuitive classes.

Features

Features Productivity features

Simple, easy to use OO interface designed to minimise the effort required to render 3D scenes, and to be independent of 3D implementation i.e. Direct3D/OpenGL.
Extensible example framework makes getting your application running is quick and simple
Common requirements like render state management, spatial culling, dealing with transparency are done for you automatically saving you valuable time
Clean, uncluttered design and full documentation of all engine classes
Proven, stable engine used in several commercial products

Platform & 3D API support

Direct3D and OpenGL support
Windows (all major versions), Linux and Mac OSX support
Builds on Visual C++ and Code::Blocks on Windows
Builds on gcc 3+ on Linux / Mac OSX (using XCode)

Material / Shader support

Powerful material declaration language allows you to maintain material assets outside of your code
Supports vertex and fragment programs (shaders), both low-level programs written in assembler, and high-level programs written in Cg, DirectX9 HLSL, or GLSL and provides automatic support for many commonly bound constant parameters like worldview matrices, light state information, object space eye position etc
Supports the complete range of fixed function operations such as multitexture and multipass blending, texture coordinate generation and modification, independent colour and alpha operations for non-programmable hardware or for lower cost materials
Multiple pass effects, with pass iteration if required for the closest ‘n’ lights
Support for multiple material techniques means you can design in alternative effects for a wide range of cards and OGRE automatically uses the best one supported
Material LOD support; your materials can reduce in cost as the objects using them get further away
Load textures from PNG, JPEG, TGA, BMP or DDS files, including unusual formats like 1D textures, volumetric textures, cubemaps and compressed textures (DXT/S3TC)
Textures can be provided and updated in realtime by plugins, for example a video feed
Easy to use projective texturing support

Meshes

Flexible mesh data formats accepted, separation of the concepts of vertex buffers, index buffers, vertex declarations and buffer mappings
Biquadric Bezier patches for curved surfaces
Progressive meshes (LOD), manual or automatically generated
Static geometry batcher

Animation

Sophisticated skeletal animation support
- blending of multiple animations with variable weights
- variable/multiple bone weight skinning
- software and hardware-accelerated skinning pipelines with intelligent buffer sharing
- manual bone control
- Configurable interpolation modes, accuracy vs speed tradeoffs
Flexible shape animation support
- Morph animation for legacy applications where you wish to perform simple linear blends between shape snapshots
- Pose animation for modern shape animation, allowing you to blend many poses at variable weights along a timeline, for example expression / mouth shapes to perform facial animation
- Both techniques can be implemented in hardware and software depending on hardware support
Animation of SceneNodes for camera paths and similar techniques, using spline interpolation where needed
Generic animation tracks can accept pluggable object adaptors to enable you to animate any parameter of any object over time

Scene Features

Highly customisable, flexible scene management, not tied to any single scene type. Use predefined classes for scene organisation if they suit or plug in your own subclass to gain full control over the scene organisation
Several example plugins demonstrate various ways of handling the scene specific to a particular type of layout (e.g. BSP, Octree)
Hierarchical scene graph; nodes allow objects to be attached to each other and follow each others movements, articulated structures etc
Multiple shadow rendering techniques, both modulative and additive techniques, stencil and texture based, each highly configurable and taking full advantage of any hardware acceleration available.
Scene querying features

Special Effects

Compositor system, allowing for full-screen postprocessing effects to be defined easily, via scripts if desired
Particle Systems, including easily extensible emitters, affectors and renderers (customisable through plugins). Systems can be defined in text scripts for easy tweaking. Automatic use of particle pooling for maximum performance
Support for skyboxes, skyplanes and skydomes, very easy to use
Billboarding for sprite graphics
Ribbon trails
Transparent objects automatically managed (rendering order & depth buffer settings all set up for you)

Misc features

Common resource infrastructure for memory management and loading from archives (ZIP, PK3)
Flexible plugin architecture allows engine to be extended without recompilation
‘Controllers’ allow you to easily organise derived values between objects e.g. changing the colour of a ship based on shields left
Debugging memory manager for identifying memory leaks
ReferenceAppLayer provides an example of how to combine OGRE with other libraries, for example ODE for collision & physics
XMLConverter to convert efficient runtime binary formats to/from XML for interchange or editing

Orocos, a general-purpose, free software, and modular framework for robot and machine control

admin — Mon, 16 Nov 2009 10:05:19 +0000

The Orocos Project

Smarter control in robotics & automation!

“Orocos” is the acronym of the Open Robot Control Software project. The project’s aim is to develop a general-purpose, free software, and modular framework for robot and machine control. The Orocos project supports 4 C++ libraries: the Real-Time Toolkit, the Kinematics and Dynamics Library, the Bayesian Filtering Library and the Orocos Component Library.

The Orocos Real-Time Toolkit (RTT) is not an application in itself, but it provides the infrastructure and the functionalities to build robotics applications in C++. The emphasis is on real-time, on-line interactive and component based applications.
The Orocos Components Library (OCL) provides some ready to use control components. Both Component management and Components for control and hardware access are available.
The Orocos Kinematics and Dynamics Library (KDL) is a C++ library which allows to calculate kinematic chains in real-time.
The Orocos Bayesian Filtering Library (BFL) provides an application independent framework for inference in Dynamic Bayesian Networks, i.e., recursive information processing and estimation algorithms based on Bayes’ rule, such as (Extended) Kalman Filters, Particle Filters (Sequential Monte methods), etc.

Orocos is a free software project, hence its code and documentation are released under Free Software licenses.

OpenServo, toward the creation of high quality digital servo for robotics

admin — Mon, 16 Nov 2009 09:56:17 +0000

OpenServo is an open community-based project with the goal of creating a high quality digital servo for robotics.

Some of the many features of the OpenServo include:

High performance AVR 8-bit microcontroller
Compact H-Bridge with high performance MOSFETs
Precision control over servo position and speed
I2C/TWI based interface for control and feedback
Feedback of position, speed, voltage and power
Advanced curve based motion profile support
EEPROM storage of servo configuration information
Software written in C using free development tools
I2C/TWI bootloader and GUI programmer

Open Engine Dynamics. Library for simulation of rigid bodies dynamics.

admin — Mon, 16 Nov 2009 09:50:33 +0000

ODE is an open source, high performance library for simulating rigid body dynamics. It is fully featured, stable, mature and platform independent with an easy to use C/C++ API. It has advanced joint types and integrated collision detection with friction. ODE is useful for simulating vehicles, objects in virtual reality environments and virtual creatures. It is currently used in many computer games, 3D authoring tools and simulation tools. This library is free software.

Physical Rigging, library for complex dynamics simulation and visualization.

admin — Mon, 16 Nov 2009 09:45:58 +0000

Physics libraries such as ODE provide excellent real-time simulation, embedding them in a 3D application to create a virtual reality is far from trivial. It is often prohibitively difficult to create a simulated reality that incorporates complex dynamic objects that interact with each other and the environment under physics’ constraints.
One of the major obstacles is mapping between meshes and objects supported by the physics engine.—This is what EZPhysics aims to solve.

EZPhysics API is licensed under the GNU Lesser Public License (LGPL).

The system is composed of two parts:

Editor & Simulator—Lets you interactively embed objects supported by the physics engine into 3D meshes, attach joints and constraints to the physics objects, save the “physically rigged” scenes into files, and run simulations.
API—Lets you embed the “physically rigged” meshes into your application. This involves using classes and methods for reading the editor files and manipulating the physical aspects of the objects, such as applying torques and forces to joints.

CarWorld, a small driving simulator/demo

admin — Mon, 16 Nov 2009 09:39:41 +0000

CarWorld is a small driving simulator/demo I use to test various things of interest. It was mostly developed when I was a student. It is released with the full source code under the GNU General Public License.

The rendering

The two top pictures represent an slightly older version (v0.072) but graphically similar of CarWorld as it was presented for my project. v0.072 includes an OpenGL based renderer allowing

file input and displaying of texture mapped models with interpolated surface normals, real time projected shadows (as seen in the dino lights example).
background object
on screen command line to modify visual and simulation parameters

The mechanics

based on classical mechanics
uses standard metrics (Newtons, meters, seconds…)
there are no constraints on the environment surface
variable length time increments and variable increment number means “CarWorld time” is not dependent on frame rate.
adjustable simulation specs include: metrics, mass, moment of inertia around rotation axis, suspension pre load, compression dampin

Where I am now

I am now working at OKTAL where I work on Callas/Prosper a vehicle dynamics evaluation tool and full scale driving simulator.

The rendering

The two top pictures represent an slightly older version (v0.072) but graphically similar of CarWorld as it was presented for my project. v0.072 includes an OpenGL based renderer allowing

file input and displaying of texture mapped models with interpolated surface normals, real time projected shadows (as seen in the dino lights example).
background object
on screen command line to modify visual and simulation parameters

The mechanics

based on classical mechanics
uses standard metrics (Newtons, meters, seconds…)
there are no constraints on the environment surface
variable length time increments and variable increment number means “CarWorld time” is not dependent on frame rate.
adjustable simulation specs include: metrics, mass, moment of inertia around rotation axis, suspension pre load, compression damping, rebound damping, engine torque output, air friction, surface friction.

GNUmed, free project for paperless medical practice

admin — Mon, 16 Nov 2009 09:27:34 +0000

The GNUmed project builds free, liberated open source Electronic Medical Record software to assist and improve longitudinal care. It is made available at no charge and is capable of running on GNU/Linux, Windows and Mac OS X. It is developed by a handful of medical doctors and programmers from all over the world. It can be useful to anyone documenting the health of patients including, but not limited to, doctors, physical therapists, occupational therapists …

What is GNUmed?

GnuMed is a group of practising doctors, programmers and free software enthusiasts from around the world, committed to provide a superior, free software solution for community practice. Using tried-and-true technology, GNUmed software will start out having record-keeping, but will eventually cover all aspects of medical practice, and will interface well with third-party software. Technically speaking, it tries to do things “cleanly”, but takes a pragmatic rather than purist approach. Currently, GNUmed’s data is accessed via business objects implemented in Python which provide and govern direct access to the PostgreSQL RDBMS, but GNUmed will also be able access various types of data stores such as other RDBMS or LDAP.

GNUmed cleanly separates the medical aspects (record keeping) from the administrative aspects (billing, storage) of a medical practice. Thereby it allows GNUmed to be internationalized to different jurisdictions.

Who is GNUmed for?

GNUmed is suitable for any health care provider interested in keeping a sound and comprehensive medical record. It is currently in use with GPs and physical therapists. GNUmed safely operates on networks of a few to many users, and supports secure, remote access. It does also operate on a single computer, which makes it possible to initially examine the software, and may suit doctors or nurse clinicians serving rural or disadvantaged areas with limited infrastructure.

This is done by installing a “localhost” database in your machine or server infrastructure. More Information on the Documentation.

What can GNUmed do for me today ?

As of August 2009 GNUmed can be used to do the following: