Hello,
The current sensor classes allow the configuration of an update frequency, causing sensor values to be automatically retrieved by the Serializer.NET framework at the frequency specified. This is a great feature and allows the sensor value to be read with no delay when queried by a higher level algorithm. The downside to this feature, however, occurs when lots of sensors are being updated. This feature might produce progressively less deterministic sensor update frequencies, as more and more sensors must be polled.
I would like to request that the option of disabling this feature with an update frequency of 0, be added at some future date. I am assuming that in so doing, that only when I query the Value property in the sensor object, will the appropriate command be issued to obtain the most current value of the sensor. This is particularly important in algorithms where the precise age of the sensor value must be known. I would expect that this would cause the use of the Value property to block until the command response was received from the Serializer board, instead of the immediate return which is possible when using an update frequency above 0.
It would also be nice if this update frequency of 0 prevented the creation of any background polling threads, until the sensor value was actually queried using the Value property. This is important when running the serializer on power constrained devices that need to sleep when the robot is idle. Running threads prevent the CE kernel from entering it's low power state.
James Y. WilsonSeralizer.NET Fan
James Y. Wilson http://www.learningce.com Fortudine Vincimus!
Hey Jim,
This is an excellent point! :) Fortunately, every component in the library which inherits from the IQueryableComponent class (all sensors) has a boolean 'Enabled' property. All you have to do is set it's value to 'true' for the object to be queried at the specified frequency, and 'false' to turn they querying off. :)
That's it!
As you pointed out, there are two halves to the library. One half (the background) is performing periodic (based on specific update frequencies) communication with the Serializer to query sensor values. Once it retrieves those values, it updates the value of property for that object. Thus, for a GP2D12 object connected to Analog Pin 1 updated every 100msec, a command such as 'sensor 1' is sent to the serializer every 100msec. Once the value is retrieved, the actual sensor voltage is converted to a distance, and stored in the GP2D12.Distance property.
The other half of the library is basically the Serializer object interfaces, which allow higher level .NET applications to immediately read the value of the property. Thus, higher level apps don't incur the round trip delay to query the sensor value.
Thus, when you set the Enable property above to false for a specific sensor, all commands for that sensor to query it's value on the Serializer ceases.
Okay, setting the Enabled property to false sounds like it might give me the determinism I am after. Just to clarify then, when I call the Value property with the Enabled property set to false, it will cause the appropriate command to be generated and sent to the Serializer. My call to Value will then block until the command response is received. No background polling or thread creation will occur as a result of this call.
Is this correct?
Thanks!
Jim,
When you set the 'Enabled' property to false for an object (e.g. GP2D12), all sensor queries for that object will cease to be sent to the Serializer. Thus, when you query the value of a property from your .NET app, such as a 'Distance' property, you will get the last reading recorded to that property. Your call to read the property won't block. Also, no background threads (responsible for updating the value of the property in the background) will be created for that object, while the Enabled property is set to false.
Once you set the Enabled property back to True, a command to query the value of that object is enqueued in an internal queue (using a Thread pool thread), and once enqueued, that thread dies, and another dedicated thread will handle dequeing the command, sending it down to the Serializer, reading the response, and updating the value of the property to which is belongs. This enqueuing of commands/requests happens at the specified UpdateFrequency property.
Does that make sense?
Yes, this make sense, though it is not what I was hoping for.
What I need is absolute control over when the commands are sent, so that I can be sure of the point in time when the reading was received. This is easier for my application code to control when a large number of sensor objects are in use, than letting the values be updated automatically.
So using the approach you describe above would require that I enable the sensor, check it's value, and then disable the sensor when I am done. It would be simpler if there was a blocking function that queues the command and waits for a response. Doing it this way I can be sure that the difference between the time of the query of the sensor value and the actual result is minimized. This allows a much more deterministic synchronization of a sensor value with the point in time at which my navigation algorithm is interested in the particular sensor value. I would rather incur the overhead of the round trip time for a sensor query, then the chatter of serial traffic for sensor values I am not yet interested in, that could potentially delay the retrieval of values that I am interested in.