A standardized wrapper-object for sensor objects?
John Kauffman
Posts: 653
Maybe this is all done and I am searching the fora with wrong strings.
When I buy a new sensor its object works fine but I have to spend a fair amount of time figuring out the methods and exactly what I'm getting back as results.
How practical would it be to have an object that would be a "front end" for other sensor objects? Maybe it is called a wrapper or intermediate layer or interface? Sensor object writers would have their output feed to this wrapper object which would do some standardizing. The user would learn to use the one wrapper that could be used for all sensors that meet the standard.
The standardizing I picture:
Methods standardized to .start .getValueOnce .getValueContinious .getAndDisplayToTerminal
Returns standardized to fundamental units so they can work together: meters, seconds, m/s^2
Scaling / clipping standardized so result of 512/1024 would mean middle of light sensor range same as 512/1024 would be middle of pot twist
The main thing I see as a problem is that there are so many kinds of values in sensors, from simple photoresistor ohm to GPS string. Maybe a wrapper would not handle enough variety to be worth it.
I know this is very vague; maybe it is an unworkable idea. Maybe it is essentially out there as a standard in sensor objects and I need to learn about it. It would be so great to buy a sensor that meets the Parallax Sensor Standard and use the same Parallax Sensor Standard Object that I learn once.
When I buy a new sensor its object works fine but I have to spend a fair amount of time figuring out the methods and exactly what I'm getting back as results.
How practical would it be to have an object that would be a "front end" for other sensor objects? Maybe it is called a wrapper or intermediate layer or interface? Sensor object writers would have their output feed to this wrapper object which would do some standardizing. The user would learn to use the one wrapper that could be used for all sensors that meet the standard.
The standardizing I picture:
Methods standardized to .start .getValueOnce .getValueContinious .getAndDisplayToTerminal
Returns standardized to fundamental units so they can work together: meters, seconds, m/s^2
Scaling / clipping standardized so result of 512/1024 would mean middle of light sensor range same as 512/1024 would be middle of pot twist
The main thing I see as a problem is that there are so many kinds of values in sensors, from simple photoresistor ohm to GPS string. Maybe a wrapper would not handle enough variety to be worth it.
I know this is very vague; maybe it is an unworkable idea. Maybe it is essentially out there as a standard in sensor objects and I need to learn about it. It would be so great to buy a sensor that meets the Parallax Sensor Standard and use the same Parallax Sensor Standard Object that I learn once.
Comments
I like the idea as it has the potential to make integrating the multitude of sensors, etc. more steamlined.
I am sure we could all find reasons why this might not work or be too difficult to implement or .....
For a robust 'standard' to be developed a small moderating group would be required to write standrad specifying the prefered call/return parameters, etc. and ensure each sensor object meets the 'standard'. Any volunteers?
I've started to work on this on my robot rover mbed platform. Would love to talk through this more.
Actually coming up with the templates/standard probably isn't the hard part. The question is how you encourage (or enforce) use of standards?
Part of the problem may be documentation. I'm spoiled by the doxygen setup on mbed. Again, how do you enforce standards?
The carrot should promote adoption better than the stick. Once created, objects can be designated as Plax Sensor Standard or not. I would think the documentation would be worth it - whatever is written for the wrapper would be less than documentation for 10 or 100 sensors. It might reduce the documentation needed for the devs of actual sensors.
Yes! That's precisely why I'm doing it on my mbed autonomous rover robot.
Classes of sensor is about as good as I think you can get. Otherwise you abstract them to a point that the results don't make sense for some sensor types. Too many disparate things being measured. I have been working on this for my custom robot too. As I devise a C++ class to reflect a given sensor I then look at how far I can abstract that. For instance being able to substitute an HY-SRF04 for a Ping))) sensor in code and asking either to give you range_in() makes sense. I can't imagine too much code though where it would make sense to substitute a I2C gyro for a range finder for instance so abstracting them all into some grand "Sensor" class makes little sense to me.
The difficulty always comes in though in making a standard that fits enough people's use that they don't just go off and do what they need themselves and isn't so bloated by the former effort that nobody can afford to use it on anything non-trivial.
I'll be interested to see where this goes. So far I have been working on stuff like this:
SonarSensor
-getRangeIn()
-getRangeCm()
ADCSensor
-setScale(float)
-setRange(int, int)
-getCount()
-getVolts()
IRProxSensor
-getState()
VCOSensor
-setInterval(int)
-getCount()
Idea being that I can hand lots of code an ADCSensor base class and that code can get volts and count from it knowing nothing about if it is an I2C/SPI/Parallel/SigmaDelta/RCTime etc. Any code can be handed a SonarSensor and get a range in inches or centimeters. Who cares if it's a Parallax Ping))) or an EBay China Sonar. Pick the sonar class that works with your hardware and use it.
http://forums.parallax.com/showthread.php/149231-DEMO-Succesive-Aproximation-Normalization-%28SAN%29-Filter
It's entire purpose is to normalize two data sets so that you can compare apples to apples with a standard data set range.