|
It is currently Thu Sep 02, 2010 3:19 pm
|
View unanswered posts | View active topics
|
Page 1 of 1
|
[ 10 posts ] |
|
Sensor polling interval and other background tasks
| Author |
Message |
|
mightor
Moderator
Joined: Wed Mar 05, 2008 8:14 am Posts: 1327 Location: Rotterdam, The Netherlands
|
 Sensor polling interval and other background tasks
Developers, I would like to gain some more insight into the internal workings of RobotC. There is no information to be found on how sensors are polled, at what speed and with which parameters. - Is the default speed for all Mindsensors and HiTechnic sensors Normal, Fast or Fastest or are some sensors treated differently?
- How often per second are they polled?
- Does this differ per sensor or are they all the same?
- If I have problems with a particular sensor and it turns out it is because it's polled at an unsupported port speed (Fastest instead of Normal), is there a way to turn it down a notch? I would much rather a "slower" working sensor than a high speed one that gives me skewed data.
What other tasks are there in RobotC that are not documented? There are undoubtedly some house-keeping threads, etc. What are they, what function do they have? Thanks, Xander
_________________ | Spanish Siamese twins for sale. Buy Juan get Juan free. Call now! | My Blog: I'd Rather Be Building Robots | RobotC 3rd Party Driver Suite: [Project Page] | | Do not send me PMs with questions, create a forum thread instead
|
| Wed Dec 17, 2008 11:03 am |
|
 |
|
Ford Prefect
Senior Roboticist
Joined: Sat Mar 01, 2008 12:52 pm Posts: 937 Location: a small planet in the vicinity of Beteigeuze
|
 Re: Sensor polling interval and other background tasks
it seems the developers won't like to tell you... 
_________________ Ford Prefect
Never purchase release 1.x ! (ancient programmer's wisdom) "Don't argue with idiots. They'll drag you down to their level and then beat you with experience."
|
| Sat Dec 20, 2008 5:09 am |
|
 |
|
nat1192
Rookie
Joined: Thu Oct 16, 2008 10:07 am Posts: 6 Location: Between Here and There
|
 Re: Sensor polling interval and other background tasks
If you look through the RobotC installation directory under the includes folder, there are a couple of files with various things that might have what you are looking for.
_________________
|
| Sat Dec 20, 2008 5:33 pm |
|
 |
|
mightor
Moderator
Joined: Wed Mar 05, 2008 8:14 am Posts: 1327 Location: Rotterdam, The Netherlands
|
 Re: Sensor polling interval and other background tasks
Yeah, I had a look at the TSensorTypes.h file before, but it has no concrete info on sensor speeds or polling intervals for sensors that have native RobotC drivers. Regards, Xander
_________________ | Spanish Siamese twins for sale. Buy Juan get Juan free. Call now! | My Blog: I'd Rather Be Building Robots | RobotC 3rd Party Driver Suite: [Project Page] | | Do not send me PMs with questions, create a forum thread instead
|
| Sat Dec 20, 2008 5:44 pm |
|
 |
|
Dick Swan
Creator
Joined: Fri Feb 09, 2007 9:21 am Posts: 548
|
 Re: Sensor polling interval and other background tasks
All analog sensors are polled every 3 milliseconds by the 8-bit Atmel CPU in the NXT. The code for this is hard-coded and the Atmel flash is not-upgradeable. The data from the Atmel CPU is polled by the NXT ARM CPU every two milliseconds. It is then up to the NXT firmware as to what to do with this information. THe Atmel is actually fast enough that the sensors could have been polled every millisecond but I believe LEGO chose to use 3 milliseconds for compatability with the legacy RCX system. The I2C sensors are polled on an implementation specific rate. If you "roll your own" driver, then the rate is up to you. If you choose to use one of the integrated drivers in ROBOTC then the rate is defined in the ROBOTC firmware. THe current definitions for these are below.  |  |  |  | Code: typedef enum { fmtSingleByte = 0, fmtTwoBytes = 1, fmtSonar = 2, fmtAccel = 3, } TI2CDataFormat;
typedef const struct { ubyte nInitMsgSize; ubyte nInitMsg[kMaxInitMessageBytes]; uword nInitTime; ubyte nPollFrequencyInMSec; // in milli-seconds ubyte nPollAddress; ubyte nPollSize; // 1 or 2 byte value. TI2CDataFormat nDataFormat; } TSimpleI2CConfigData;
static const TSimpleI2CConfigData nLEGOSonar = { 3, // Initialize messsage size { // Initialize messsage size and 'message' 0x02, // I2C Addresss 0x41, // Internal address 0x02, // Function => Set to continuous measurement }, 75, // Initialization/settling time before startup. 70, // Polling frequency (in milliseconds) 0x42, 1, // Poll address and number of bytes fmtSonar, // Data format };
static const TSimpleI2CConfigData nHiTechnicColor = { 2, // Initialize messsage size { // Initialize messsage size and 'message' 0x02, // I2C Addresss 0x41, // Internal address 0x00, // Function => }, 40, // Initialization/settling time before startup. 15, // Polling frequency (in milliseconds) 0x42, 4, // Poll address and number of bytes fmtSingleByte, // Data format };
static const TSimpleI2CConfigData nHiTechnicAccel = { 2, // Initialize messsage size { // Initialize messsage size and 'message' 0x02, // I2C Addresss 0x41, // Internal address 0x00, // Function => }, 40, // Initialization/settling time before startup. 20, // Polling frequency (in milliseconds) 0x42, 6, // Poll address and number of bytes fmtAccel, // Data format };
static const TSimpleI2CConfigData nHiTechnicCompass = { 2, // Initialize messsage size { // Initialize messsage size and 'message' 0x02, // I2C Addresss 0x41, // Internal address 0x00, // Function => }, 40, // Initialization/settling time before startup. 15, // Polling frequency (in milliseconds) 0x44, 2, // Poll address and number of bytes fmtTwoBytes, // Data format }; |  |  |  |  |
|
| Sun Dec 21, 2008 12:21 pm |
|
 |
|
mightor
Moderator
Joined: Wed Mar 05, 2008 8:14 am Posts: 1327 Location: Rotterdam, The Netherlands
|
 Re: Sensor polling interval and other background tasks
Thanks Dick, that sheds some light on some of the internals of RobotC.
Could you tell me what the I2C connection speed is for these sensors? Normal, Faster or Fastest?
Regards, Xander
_________________ | Spanish Siamese twins for sale. Buy Juan get Juan free. Call now! | My Blog: I'd Rather Be Building Robots | RobotC 3rd Party Driver Suite: [Project Page] | | Do not send me PMs with questions, create a forum thread instead
|
| Sun Dec 21, 2008 1:29 pm |
|
 |
|
Dick Swan
Creator
Joined: Fri Feb 09, 2007 9:21 am Posts: 548
|
 Re: Sensor polling interval and other background tasks
Right now these are all the "fastest" I2C messaging speed. With the current firmware and my sample of one sensor of each type, they all work fine with this speed. However, I have unconfirmed reports that this is not always the case. So far, it has always turned out to be a problem of using very old firmware.
However, in any case, I plan to add a new field to allow which firmware speed to use. And to make the table more customizable, even by end users so that it can be easily expanded to support easily add additions for more third party sensors.
|
| Sun Dec 21, 2008 2:00 pm |
|
 |
|
mightor
Moderator
Joined: Wed Mar 05, 2008 8:14 am Posts: 1327 Location: Rotterdam, The Netherlands
|
 Re: Sensor polling interval and other background tasks
Dick,
Is there a specific reason why those sensors are read at the Fastest speed? Neither Lego nor HiTechnic guarantee their sensors to run at that speed.
Regards, Xander
_________________ | Spanish Siamese twins for sale. Buy Juan get Juan free. Call now! | My Blog: I'd Rather Be Building Robots | RobotC 3rd Party Driver Suite: [Project Page] | | Do not send me PMs with questions, create a forum thread instead
|
| Sun Dec 21, 2008 2:38 pm |
|
 |
|
Dick Swan
Creator
Joined: Fri Feb 09, 2007 9:21 am Posts: 548
|
 Re: Sensor polling interval and other background tasks
The LEGO sonar sensor, AFIAK, is the only sensor that has an internal firmware bit-banged I2C implementation. All 3rd party devices that I have encountered have I2C hardware support and can/should operate at much higher speeds. I misopke in my earlier post as the LEGO sonar sensor firmware driver operates at a slower speed. The slower speed of the sonar sensor is because it's internal CPU cannot run fast enough to support collection of the individual bits with a single I2C byte. With hardware support within the sensor's CPU, faster rates are not only possible but quite robust. The LEGO firmware operates the I2C clock at a nominal 20 KHz clock frequency. But, if you trace the clock on an oscilloscope you'll find that the clock pulses can be quite uneven. This is due to interactions with other interrupt handlers are firmware delays in interrupt handling when there are simultaneous interrupts. You can especially notice this if you have an activity that is generating lots of other interrupts like for example USB message traffic. The ROBOTC firmware is far more robust in this nature; it processes I2C traffic at a lower interrupt level but ensures that clock pulses -- or more precisely the time between a I2C data line transition and the corresponding edge of the I2C clock -- are always at least a minimum size. I believe that this implementation, even though it uses a faster clock, is in fact more reliable than the standard LEGO firmware implementation. A faster I2C clock is not required for the "slow" sensors like the sonar sensor which is in fact only performing a measurement on a very slow (say 50 milliseconds or so) basis. However, there are several reasons where a faster clock is desired: - many of the more advanced sensors provide better accuracy when the polling is faster; like for example an acceleration sensor where you might want to integrate the acceleration values into a velocity value.
- Or a gyroscope sensor where you want to oversample to eliminate noise.
- Or a camera sensor where you want to read 10s of bytes from the device.
- Or the emerging use of multiple sensors daisy chained on one I2C bus.
There was a problem in older versions of ROBOTC firmware where both the clock line and data line were changed in the same timeslice. The two transitions were separated by only a few lines of C-code for a delay of less than a microsecond. Depending on different characteristics of wires within a (long) sensor cable or differences within the hysteris loops of I/O pins within the slave CPU the clock transition might be recognized by the slave CPU first even though it was changed last in the C-code! This bug was common to both the ROBOTC and standard NXT-G firmware although it was slightly worse in the ROBOTC firmware because of the better code-optimization of the generated firmware object code. This did cause problems with ROBOTC firmware until it was discovered and resolved. It still exists as a bug in the standard LEGO firmware. This problem occurs most frequently on longer sensor cables. It is because of the point in the above paragraph that it will be an option to use slower speed messaging for ROBOTIC's integrated firmware device drivers. I don't think it is needed.
|
| Sun Dec 21, 2008 5:55 pm |
|
 |
|
mightor
Moderator
Joined: Wed Mar 05, 2008 8:14 am Posts: 1327 Location: Rotterdam, The Netherlands
|
 Re: Sensor polling interval and other background tasks
Dick, Thanks for the info  Xander
_________________ | Spanish Siamese twins for sale. Buy Juan get Juan free. Call now! | My Blog: I'd Rather Be Building Robots | RobotC 3rd Party Driver Suite: [Project Page] | | Do not send me PMs with questions, create a forum thread instead
|
| Sun Dec 21, 2008 6:24 pm |
|
|
|
Page 1 of 1
|
[ 10 posts ] |
|
Who is online |
Users browsing this forum: No registered users and 0 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|