Sensors & Controllers Library

[Matt]

New readers can catch up here (http://www.trossenrobotics.com/tutorials/TRS4.aspx).

I have a dream. This dream is of a Sensor & Controller Library (SCL) that knows how to communicate with all kinds of hardware without any one company needing to be in charge of managing it all. This, a little bearded man in the dream told me, "Is how you will forever keep the TRS away from proprietary demons."

In this dream I envisioned a library that at run time would check in a folder for XML config files that had all the instructions necessary to communicate with all the bridgeware used in the robot project. Any company that came along and wanted to sell new hardware to robot builders only needed to create their own XML config file to be plopped into that start up folder. They would know how to make said config file because there was a standards body that released all those specs right along with managing the TROM. This made everyone in the valley happy because the system maintained itself and no one company had to do all the work so that all the elves and fairys could concentrate on building the robot parts they liked most.

Okay, in all seriousness, this is how I imagine the perfect SCL to work. It avoids so many pitfalls and it creates such a beautifully open system. Exactly how to build it is over my head so I put the challenge to you brilliant people. How would we build it?

[Adrenalynn]

They would also, quite possibly, need to create their own devices drivers too, correct? This n-tier abstraction you're proposing would really insulate the a tier above the hardware manufacturers, right?

I'm just trying to grok your thoughts here.


* A hardware manufacturer makes an integrated gyro, inclinometer, and accelerometer.
* Said manufacturer creates a device driver.
* The driver layer spits out an XML configuration file like [pseudo-xml for understanding]:

<PositionRef : 1> ; this device provides position references
<FVector : 1> ; this devices gives us force-vectors
<Bitmap : 0> ; This device doesn't generate bitmaps. Buy a camera

[...]

<PositionRange : X=+-180, Y=+-180, Z=+-180, Pitch=+-90, Yaw=+-90, Roll=+-90>
<PositionFormat : XXXX.XX, YYYY.YY, ZZZZ.ZZ, [...]>
<FVectorRange : 0.00, 3.00> ; expressed in g's, more likely expressed in uVolts if we don't have drivers
<FVectorFormat : [...]>

* Then the application layer (which is where we'll bury the renderer and such for the moment) picks up that standard Schema that we've proposed, and ingests it.

Is that about the size of what you're visualizing?

[LinuxGuy]

In this dream I envisioned a library that at run time would check in a folder for XML config files that had all the instructions necessary to communicate with all the bridgeware used in the robot project.
OK, I see kind of how this could work. This assumes for now that the library has routines to handle any known sensor unit. A sensor unit is something like an ultrasonic sensor (with different interfaces being different sensor units), IR ranging sensor, accelerometer (X, Y, Z axis being separate sensor units), gyros, compass, bump sensors, etc.

Any number of sensor units may be combined into a sensor module, such as an IMU, two or three axis accelerometers, etc. Various driver definition files (DDF) would define the parameters of each sensor unit as well as how sensor units are combined into various sensor modules, such as IMUs, accelerometers, etc.

Am I close?

Any company that came along and wanted to sell new hardware to robot builders only needed to create their own XML config file to be plopped into that start up folder. They would know how to make said config file because there was a standards body that released all those specs right along with managing the TROM.
I think it's workable. :veryhappy: I always write my sensor code as components I can easily use anywhere I need them.

Okay, in all seriousness, this is how I imagine the perfect SCL to work. It avoids so many pitfalls and it creates such a beautifully open system. Exactly how to build it is over my head so I put the challenge to you brilliant people. How would we build it?
Well, I have a starting vision of how it could be built. Let's see what everyone else thinks. :veryhappy:

8-Dale

[Matt]

They would also, quite possibly, need to create their own devices drivers too, correct? This n-tier abstraction you're proposing would really insulate the a tier above the hardware manufacturers, right?

Correct, the device drivers would still be there. The XML file "exposes" or gives a map to the SCL on how to talk to the device drivers. Your example XML is on target with what I am envisioning. I am used to a world that has APIs (Phidgets/Serializer/home made serial port wrappers) which the code talks to so I don't know if there needs to be an API layer or if we are essentially replacing that?

What has to be avoided is a standards body thinking it should be defining what pieces of data any device has. That is for the manufacture to decide and expose in their XML. The XML says, hey, I have these calls that have these names and that deliver this stuff. The open standard specs for the SCL simply tell manufactures how to go about doing that. I wish I had a real world example to point to!


* Then the application layer (which is where we'll bury the renderer and such for the moment) picks up that standard Schema that we've proposed, and ingests it.


No code or other tool talks directly to the SCL, any change you wish to make to the state of the robot is made to a variable in the object model and the other tools do their job from there (IE: the rendering tool & the SCL)

[Matt]

Another point of explanation I should add. The information about what hardware is connected for a robot is stored in the TROM config file. At run time two things happen:

1) The TROM loads in the XML config file for the bot and creates a live instance.
2) The SCL reads through the TROM instance and "finds" all references to the sensors and controllers it should expect to be talking to. Then it creates those objects.

For example: I could have a bot that has a Phidget 8/8/8 hooked up with 4 range sensors. The object for each range sensor would have the following:
<Controller_Name=Phidget 8/8/8>
<Controller_Serial=1234>
<Controller_Port=3>

The SCL would find these 4 sensors all mentioning the 8/8/8 with the same serial # and it would know it needs to make 1 Phidget 8/8/8 object to interact with. If it finds two of them mentioned with two unique serial #s then it sets up two and so on. The info for what objects to create at run time are in the TROM XML config file. The info for how to create those objects is stored over in the SCL folder holding the manufactures config files. The info for when the exact moment is to flip the worlds best grilled cheese sandwich over at it's pinnacle of toastiness is stored in my head.

[LinuxGuy]

Another point of explanation I should add. The information about what hardware is connected for a robot is stored in the TROM config file. At run time two things happen:

1) The TROM loads in the XML config file for the bot and creates a live instance.
2) The SCL reads through the TROM instance and "finds" all references to the sensors and controllers it should expect to be talking to. Then it creates those objects.
Shouldn't the higher level object (Interface 8/8/8) just have pointers to instances of sensor objects that are interfaced to it? This can be many different combinations. For instance 2-axis and 3-axis accelerometer objects would require 2 and 3 analog input objects, respectively. Sharp IR sensors require 1 analog input per sensor object. My building block sort of approach to a sensor library would handle this very well. :veryhappy: If an interface object or sensor object has no serial number, it would need to be assigned one. This allows easy tracking of not only what type of sensor is connected, but also the parameter set for a specific sensor object. Each sensor object can be connected to a specific interface object port by serial number. The interface object ports would be serialized as well as the interface object itself and the sensor objects attached to the ports. This is a layered approach as you can see, and I think it fits beautifully with the TROM.

If it finds two of them mentioned with two unique serial #s then it sets up two and so on. The info for what objects to create at run time are in the TROM XML config file. The info for how to create those objects is stored over in the SCL folder holding the manufactures config files.
This also fits excellently with my layered approach to the SCL. It's just a matter of what everyone can agree on implementing. You only deal with the SCL at as low a level as is necessary.

The info for when the exact moment is to flip the worlds best grilled cheese sandwich over at it's pinnacle of toastiness is stored in my head.
I like layers. Cakes have layers. I don't eat onions!

8-Dale

[metaform3d]

What I find to be more useful at this stage of design is to have some concrete examples of what we'd like to be able to do rather than focusing on all those tempting implementation details. For example:

1) When I attach a sensor I'd like to be able to access its state in the way that is most convenient to my application. If it's a range sensor, for example, I should be able to poll it for the current distance; I should be able to get it to send me events on certain range triggers; I should be able to ask for background priority confirmations of my range approximations.

2) I want to be able to configure a range sensor from other components. Perhaps I have an 8/8/8 interface board attached and I have an analog sonar sensor. I should be able to treat that as a specialized range sensor type with all the above capabilities.

3) I want to be able to swap out sensors without having to rewrite my logic. If the analog sensor isn't good enough I want to be able to replace it with some different technology but not have to rewrite the code to have my alarm trigger when a wall approaches at more than 1 m/s.

[Sienna]

Personally, I don't see 'polling' of sensors so much as 'pushing' their updates to the object model.

The object model should be a (near) real time representation of the robot to me.

This is where that 'publish and subscribe' concept comes in. Basically, under a pub/sub architecture, you have things that 'publish' data (e.g., sensors), and things that need to use ('subscribe to')that data (e.g., mapping algorithms, object model, renderer). There is another component not mentioned, but that is the component that manages all the subscriptions. Think of it like a repeater. When a component comes up, it says to the manager "Hey, I would like to register myself to receive all the messages that come in of a 'distance' type". The manager adds that component to a list. Then, when a message comes in, say it is a 'distance' message from a sensor, the manager goes through its 'distance' list, and copies that message to everyone who has expresses interest.

I know a lot of software uses paradigms like this, but I do not know any toolkit offhand that would solve it for us. We can discuss further if people are interested.

[Alex]

The object model should be a (near) real time representation of the robot to me.

This is where that 'publish and subscribe' concept comes in. Basically, under a pub/sub architecture, you have things that 'publish' data (e.g., sensors), and things that need to use ('subscribe to')that data (e.g., mapping algorithms, object model, renderer).This is very similar to what I initially had in mind Sienna, but I didn't know enough about the topic to really put it into words as well as you did. I would love to see this discussion take place if you could explain the concept a bit more in depth. Start a new thread about it though.

[LinuxGuy]

I am used to a world that has APIs (Phidgets/Serializer/home made serial port wrappers) which the code talks to so I don't know if there needs to be an API layer or if we are essentially replacing that?
Oh, I believe we are talking about an API layer for sure, but the API will exist at different levels and provide increasing levels of details.
What has to be avoided is a standards body thinking it should be defining what pieces of data any device has.
How are you defining what a 'device' is?

That is for the manufacture to decide and expose in their XML. The XML says, hey, I have these calls that have these names and that deliver this stuff. The open standard specs for the SCL simply tell manufactures how to go about doing that. I wish I had a real world example to point to!
Which XML are you talking about? Is the SCL a set of XML that defines sensors, or is it a set of C++ classes that define sensor that are instantiated within the API and/or user's software? I've been working under the assumption (possibly incorrect) that the SCL is where the sensor classes reside, and these are used to create the Object part of TROM. Please clarify.

No code or other tool talks directly to the SCL, any change you wish to make to the state of the robot is made to a variable in the object model and the other tools do their job from there (IE: the rendering tool & the SCL)
This sounds like the SCL is a set of classes that define the Objects.

8-Dale

[Alex]

Which XML are you talking about? Is the SCL a set of XML that defines sensors, or is it a set of C++ classes that define sensor that are instantiated within the API and/or user's software? I've been working under the assumption (possibly incorrect) that the SCL is where the sensor classes reside, and these are used to create the Object part of TROM. Please clarify.

Let me try to clarify what Matt's talking about from a developer's perspective:)

At the bare bones level we have the physical hardware (for this example, I'm going to say an 8/8/8 Interface Kit (http://www.trossenrobotics.com/store/p/5341-InterfaceKit-8-8-8.aspx) I'm hoping you all know how to (or at least the concept of) interact with one of these). The next layer is the device driver itself that talks directly to the 8/8/8.

After that, and this is where the TRS comes in, we would have an XML file that would come from the manufacturer (in this case Phidgets) which defines all of the barebones communications for the device driver, not the source for the device driver, but the methods, events, etc. that the device driver uses in order to communicate with the 8/8/8.

Now, this is where the SCL comes in, the SCL is responsible for creating the physical objects of each 8/8/8 Interace Kit used in your robotic application (number of 8/8/8's are defined in the TROM).

When you define your, let's call it... structure of robot for simplicities sake, using the TROM, you will be defining just how many 8/8/8's you will be using in your application. Once you define how many 8/8/8's you will have connected, it's the job of the SCL to read from the TROM to know just how many 8/8/8 Inteface kits it needs to create:)

One more piece of work that needs to be done is the translation between TROM messages/events/etc. and the objects created, and this is what we as a community need to figure out after we nail down what communication protcol we are going to use (http://forums.trossenrobotics.com/showthread.php?t=1686).

[LinuxGuy]

After that, and this is where the TRS comes in, we would have an XML file that would come from the manufacturer (in this case Phidgets) which defines all of the barebones communications for the device driver, not the source for the device driver, but the methods, events, etc. that the device driver uses in order to communicate with the 8/8/8.
This is where I start getting lost, probably because I don't know anything about how XML works. It would be useful to see an XML example of what you are talking about here. I need to find some good XML tutorials on the web.

Now, this is where the SCL comes in, the SCL is responsible for creating the physical objects of each 8/8/8 Interace Kit used in your robotic application (number of 8/8/8's are defined in the TROM).
API calls should be doing all the creation of objects by creating instances of a class defined in the SCL. The SCL should contain the classes that define the sensor and/or controller objects of a robot.

When you define your, let's call it... structure of robot for simplicities sake, using the TROM, you will be defining just how many 8/8/8's you will be using in your application. Once you define how many 8/8/8's you will have connected, it's the job of the SCL to read from the TROM to know just how many 8/8/8 Inteface kits it needs to create:)
I am totally lost here. :confused: This just doesn't make sense to me. The API should be reading from the TROM and then making calls to create instances of objects defined by classes in the SCL. The model should define the attributes of the robot, what sensors it has available, what controllers it has, and how each object can be interacted with. Something tells me I am really not understanding as much about TROM as I thought.

8-Dale

[JonHylands]

This is where I start getting lost, probably because I don't know anything about how XML works. It would be useful to see an XML example of what you are talking about here. I need to find some good XML tutorials on the web.

XML in this case is just a text file - you can think of it like a configuration file (like say an interfaces file), but XML is a little richer in that you can have hierarchical structure inside the file.

I used something similar in the robot controller I built back in 2005-6 for RoboMagellan (http://www.huv.com/roboMagellan/), except I used straight text files and wrote a simple parser.

I had device files, like this one:

ProductInformation
VendorName Garmin
ProductName Geko 201
Interface Serial
Protocol Rs232
BaudRate 4800
Parity none
DataBits 8
StopBits 1
ComPort 2
ReadWrite read
DataFormat line

PushCommand getSentence
command Integer8 '$'
responderName String 'gps'

Response getSentence
sentence StringLine


for each device that was attached, and then a "robot" file that describes which devices are on the robot:

###################################
#
# MicroRover
#
# This is the definition file for MicroRover,
# an autonomous ground vehicle.
#

VendorName HUV
ProductName MicroRover

###################################
#
# MicroRover uses a gumstix for the autonomous controller,
# and has two RS-232 serial devices:
#

Device devices\MasterPIC.txt
Device devices\GarminGekoGPSDevice.txt

###################################
#
# Sensors
#

Sensor
class AvGpsSensor
name gps
device Geko 201

Sensor
class AvMasterPicSensor
name master
device MasterPIC

Sensor
class AvCompassSensor
name compass
device MasterPIC

Sensor
class AvRotationEncoderPairSensor
name encoder
device MasterPIC

Sensor
class AvRangeFinderPairSensor
name turrent
device MasterPIC

Sensor
class AvRangeFinderPairSensor
name fixedRange
device MasterPIC

###################################
#
# Actuators
#

Actuator
class AvGHM07MotorActuator
name leftMotor
device MasterPIC
command SetLeftSpeed

Actuator
class AvGHM07MotorActuator
name rightMotor
device MasterPIC
command SetRightSpeed

Actuator
class AvServoActuator
name turrent
device MasterPIC
command SetTurrentAngle


So, when you built a robot object, you would specify the robot file, and it would read that in, parse it, and create sensors and actuators as required. Each device had the interface protocol defined, and thus you could add a sensor or actuator and use it in the mission without changing a single line of code.

- Jon

[LinuxGuy]

XML in this case is just a text file - you can think of it like a configuration file (like say an interfaces file), but XML is a little richer in that you can have hierarchical structure inside the file.

I used something similar in the robot controller I built back in 2005-6 for RoboMagellan (http://www.huv.com/roboMagellan/), except I used straight text files and wrote a simple parser.
I understand the concept, but am getting lost in how it relates to and where it is positioned with respect to TROM. At present, I believe the XML is part of the Model and defines the structure of the robot, its sensors, its controllers, and the interaction between them. However, I may be way off base here,

8-Dale

[Matt]

[quote=Alex;8747]
The SCL should contain the classes that define the sensor and/or controller objects of a robot.


Here's one thing I think you are hanging up on, there are two areas with XML. Yes, there is the XML config file for the TROM to load in. But at the moment we are talking about different XML files provided by the manufactures to be used to create all the "little" controller and sensor objects. This XML is completely separate than the one being used to load up the TROM.

What I am proposing at the moment is seeing if we can figure out a way that we don't have hundreds of individual classes for each piece of hardware out there. Instead the SCL has a "dynamic master class" that reads from the XML files and creates the objects. The XML files define the objects thus removing the need for all the individual classes.

You are pretty on target if you just make the mental leap that the objects are defined by the XML files instead of prewritten classes. Alex has told me in the past that this isn't possible. But Alex likes to lie to me :) I'd like to see if the whole community thinks so or if there are ideas on how to pull this off.

If it can't be done this way, then the manufactures have to provide those actual classes. (We as a community would write them ourselves to start with, but as the world begins to see how genius we are they will jump on board :) )

[LinuxGuy]

Matt, I think your quoting is wrong. I said what you have quoted by Alex, which is what you are replying to. :happy:

Here's one thing I think you are hanging up on, there are two areas with XML. Yes, there is the XML config file for the TROM to load in. But at the moment we are talking about different XML files provided by the manufactures to be used to create all the "little" controller and sensor objects. This XML is completely separate than the one being used to load up the TROM.
OK, so the manufacturers provide XML that defines their particular hardware. I am guessing this would contain definitions of what controllers and sensors their hardware has. Would this XML then be used to build the model of the manufacturer's hardware device? There has to be some connection between this XML and the SCL. I still see the SCL as being the set of lower elvel classes that are used to instantiate the Objects that are used to interface to the actual hardware. I do not see the SCL as actually doing anything in and of itself though.

What I am proposing at the moment is seeing if we can figure out a way that we don't have hundreds of individual classes for each piece of hardware out there. Instead the SCL has a "dynamic master class" that reads from the XML files and creates the objects. The XML files define the objects thus removing the need for all the individual classes.
This is the part I really get lost on. If the SCL is really just a library, it does not do anything by itself unless something instantiates a defined class to create an Object and operates on or with that Object to access and interface with hardware and/or other resources.

You are pretty on target if you just make the mental leap that the objects are defined by the XML files instead of prewritten classes. Alex has told me in the past that this isn't possible. But Alex likes to lie to me :) I'd like to see if the whole community thinks so or if there are ideas on how to pull this off.
I just don't get this, but it's most likely because I really don't have a good understanding of XML. My head may just be too full of other stuff like OGRE and CORBA (or other protocol we might choose), which are the pieces I need to concentrate on most right now.

If it can't be done this way, then the manufactures have to provide those actual classes. (We as a community would write them ourselves to start with, but as the world begins to see how genius we are they will jump on board :) )
I see the manufacturer's XML as defining their hardware interfaces, which would tell TROM which classes in the SCL need to be instantiated to interface it and what methods may be used to configure, control, read from, write to it. We should have classes that define only the basic sensors, controllers, and actuators a robot may have, subject to expansion to add more of any of these types at anytime.

8-Dale

[JonHylands]

What I am proposing at the moment is seeing if we can figure out a way that we don't have hundreds of individual classes for each piece of hardware out there. Instead the SCL has a "dynamic master class" that reads from the XML files and creates the objects. The XML files define the objects thus removing the need for all the individual classes.


What you're talking about is building a pluggable device class. The XML file defines everything about the device, and we take this meta-information, save it in this generic device object, and suddenly we have a very specific object (of a generic class) that represents a very specific actuator/sensor.

I didn't go that far with my model, but it would certainly be possible to do it. The real trick is you have to be able to talk to a lot of different devices, that may have completely different interfacing concepts (analog sensor versus PWM motor versus I2C serial device versus servo). What I did was define the physical interface (serial, analog, etc) as a class with specific subclasses, and the protocol (RS-232, I2C, SPI) as a class with specific subclasses. That way, each device object had, in addition to the device-specific information, an interface and a protocol.

- Jon

[housefull]

What I find to be more useful at this stage of design is to have some concrete examples of what we'd like to be able to do rather than focusing on all those tempting implementation details. For example:

1) When I attach a sensor I'd like to be able to access its state in the way that is most convenient to my application. If it's a range sensor, for example, I should be able to poll it for the current distance; I should be able to get it to send me events on certain range triggers; I should be able to ask for background priority confirmations of my range approximations.

2) I want to be able to configure a range sensor from other components. Perhaps I have an 8/8/8 interface board attached and I have an analog sonar sensor. I should be able to treat that as a specialized range sensor type with all the above capabilities.

3) I want to be able to swap out sensors without having to rewrite my logic. If the analog sensor isn't good enough I want to be able to replace it with some different technology but not have to rewrite the code to have my alarm trigger when a wall approaches at more than 1 m/s.
Personally, I don't see 'polling' of sensors so much as 'pushing' their updates to the object model.

The object model should be a (near) real time representation of the robot to me.

This is where that 'publish and subscribe' concept comes in. Basically, under a pub/sub architecture, you have things that 'publish' data (e.g., sensors), and things that need to use ('subscribe to')that data (e.g., mapping algorithms, object model, renderer). There is another component not mentioned, but that is the component that manages all the subscriptions. Think of it like a repeater. When a component comes up, it says to the manager "Hey, I would like to register myself to receive all the messages that come in of a 'distance' type". The manager adds that component to a list. Then, when a message comes in, say it is a 'distance' message from a sensor, the manager goes through its 'distance' list, and copies that message to everyone who has expresses interest.

I know a lot of software uses paradigms like this, but I do not know any toolkit offhand that would solve it for us. We can discuss further if people are interested.