Cart/Login/Help Tutorials Blog Community Contact
Become an Affiliate!



TRS Explained Part 2

Benefits of the TRS

   
 




Some of the major features and benefits with the TRS


No Box!
When we began building a robotics system for the PC our first rule of thumb was that we would not create yet another box which would trap users into something that limited their future evolvement. That meant no IDE and building open agnostic standards. It meant the system had to be easily upgradable and flexable enough to adapt with the quickly changing technologies. The Trossen Robotics System is all these things so that there is no box to become trapped in. Too many companies are providing solutions which limit what users can do and we didn't want to be another one.

Modular
The TRS and the software components used with it are completely modular just like the hardware layers. This way when hardware upgrades are made the related code module can be upgraded as well. There won't be a need to tear apart a project and rebuild it from the ground up just because new range sensors or motor controllers come out. This modular upgradablility extends to thrid party tools as well. Since third party tools plug into the system when a better rendering control or algorythm library emerge the old ones can be thrown out and replaced with ease.

Open Standard
The only way robotics will truly begin to take off is if there are standards which allow people to start sharing. In essence, allowing people to begin standing upon each other's shoulders. We created an entire robotics object model built upon an XML open standard for this purpose. Each robot has an XML configuration file associated with it which stores it's entire model. This makes the robotic code very mobile between robots and developers because the code exists independantly from the layers which are robot specific.

Third Party Plugins, Tools, and Modules
An open standards system is hugely beneficial for a community because it allows for the proliferation of third party tools to emerge. The TRS was designed to allow for companies and individuals to concentrate upon areas of interest and expertise to create add ons and tools. Imagine in a few years when there will be a dozen rendering engines available to choose from. Or a dozen algorithm libraries for every kind of DOF arm on the market. Algorithm libraries for biped and hexabot gates. Vision systems for navigation and object recognition. Motion control plug ins that can read the config file for any differential wheelbot and begin mapping a room out of the box. All these things are completely real possibilities with the TRS. Open Standards are a wonderful thing.

Developer Control
The developer is always in control. Nothing happens without the developers say so. Many systems try to be overly helpful to developers by tying layers together. At first glance this architecture seems like a helpful and intuitive way to go, but before long the dangers of architecting this way become clear. When separate layers are tied together to save time for developers limitations are being introduced into the system. When layers are tied together independence and control are lost. This is not a good way to architect a robotics system, so we didn't. For example, when a developer has a need for motion control a request is sent to the algorithm library and the library returns arrays of data which will execute the motion requested. The algorithm library does not directly make updates to the TROM or send commands out to the motors. That's not it's job. The data is returned and at the developers disposal to act upon. New data may have come in from the sensors which has changed the game plan or a developer may simply wish to analyze options or pre-store certain gates. The code a developer writes should always be in control and a developer should have the freedom to architect their robotic intelligence as they see fit without overly helpful systems getting their fingers in the way :)


Let's take a closer look at each of the TRS components in the next sections:
The TROM
The Sensor & Controller Libraries
The Algorithm Library
The Device API's
 








Request Time: 1.296875 - SID/ASID: 1039696 | pbigv2rqlv43y5fkxqnunn45 - SERVER: WEB1