View unanswered posts | View active topics It is currently Tue Sep 30, 2014 3:24 pm






Reply to topic  [ 4 posts ] 
HiTechnic sensor mux 
Author Message
Rookie

Joined: Wed Jul 21, 2010 11:23 pm
Posts: 39
Post HiTechnic sensor mux
Having run out of sensor ports, we're about to add a sensor mux. A couple of questions came to mind..

1) does the possible sampling time/rate change when moving an existing Gyro sensor from a standalone port onto a mux port? In other words, will the existing code perform any differently after changing the function call(s) to access the sensor via the mux?

2) related to the above, will there be any noticeable difference/interaction if the Gyro is being accessed via one task while other mux sensors are being read in other tasks.


Wed Dec 14, 2011 5:43 pm
Profile
Expert

Joined: Thu Sep 29, 2011 11:09 pm
Posts: 184
Location: Michigan USA
Post Re: HiTechnic sensor mux
Well, there are several differences I can think of.

The sampling time will be limited by the I2C speed (if not further by the mux itself).

There is no way to have multiple transactions going on with any I2C sensor (muxs included). The safest way would be to use a mutex to control the I2C calls. This would potentially present reading time differences (for example, one read might take 5ms, and the next time it might take 6-15ms (if another task is using the I2C bus)). Basically, you couldn't rely on a constant read time.

Usually when I use a gyro, I like to integrate the values. Any inconsistencies could have a dramatic response on the final value. Things such as read times, if the NXT motors have been previously powered... can all make a difference, and need to be accounted for. I would suggest you keep the Gyro on an NXT port, or else have it the only thing accessed on the I2C bus, so that you can read it whenever (unless you will only be using one task, and never attempting to make more than one call at a time).

I haven't used ROBOTC enough to know what the FW handles, and what is left to the programmer as far as multiple I2C calls... and I don't have a HT sensor mux (as I assume you are talking about) to try stuff with.

_________________
Matt


Wed Dec 14, 2011 9:28 pm
Profile WWW
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: HiTechnic sensor mux
ronmcrae wrote:
1) does the possible sampling time/rate change when moving an existing Gyro sensor from a standalone port onto a mux port? In other words, will the existing code perform any differently after changing the function call(s) to access the sensor via the mux?

We ran the gyro through the Sensor Mux before and did not have any issue with it. The only issue is that from time to time, the students may forget to turn the power of the sensor mux on and did not realize it until autonomous failed miserably.
ronmcrae wrote:
2) related to the above, will there be any noticeable difference/interaction if the Gyro is being accessed via one task while other mux sensors are being read in other tasks.

A lot of RobotC functions are not thread-safe. In fact, I recall reading some posts about RobotC doesn't support calling a function from different tasks. Even if RobotC supports calling a function from different tasks, you still need to determine if the function is written such that it is thread-safe (e.g. no accessing global resources etc). I assume you are calling Xander's Gyro driver? If so, Xander can comment on if his Gyro driver is thread-safe.
A lot of students don't understand how to do multi-tasking programming properly anyway. That's why we have been avoiding RobotC tasks altogether. We do our own "cooperative multi-tasking" which is a lot safer and don't have all the gotcha's of preemptive multi-tasking.


Wed Dec 14, 2011 11:07 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: HiTechnic sensor mux
mattallen37 wrote:
Usually when I use a gyro, I like to integrate the values. Any inconsistencies could have a dramatic response on the final value. Things such as read times, if the NXT motors have been previously powered... can all make a difference, and need to be accounted for.

Our library has a gyro module that does integration. Our integration doesn't depend on time consistency of when the integration is called. In other words, if preemptive multi-tasking decided to call our integration function late or even skip a time slice, the integration will still integrate correctly because it reads its own timestamp and use it for the dT calculation. As long as the integration function is called frequent enough, it is sufficiently accurate.


Wed Dec 14, 2011 11:17 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 4 posts ] 

Who is online

Users browsing this forum: No registered users and 2 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

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.