View unanswered posts | View active topics It is currently Wed Oct 22, 2014 9:58 am






Reply to topic  [ 11 posts ] 
[SOLVED] SMUX - Latency with Touch/Light sensors 
Author Message
Rookie

Joined: Mon Feb 21, 2011 3:40 pm
Posts: 15
Post [SOLVED] SMUX - Latency with Touch/Light sensors
Answer found here, but in summary, it can't be helped. Smux lags when it's changing a sensor's type, in this case "Active" and "Inactive". See link for more details.

Hello everyone, I'm having some problems with the Sensor Multiplexer.

To jump to the chase, when I add a function using LSsetActive & LSsetInactive, my tick-time(time it takes to go through the while loop, in tele-op) jumps from around 3-5ms to 75-85ms, and adding two touch sensors in that functions, jumps it to ~100ms, sometimes going as far as ~300ms for a second or so. Is this normal?

Here's the function(s);

Code:
//mTt is muxTouchThreshold, set at 100

//mTSv is defined as muxTouchSensorValue
bool muxTouchSensorValue(tMUXSensor _muxTouch, int thresh)  {
return (HTSMUXreadAnalogue(_muxTouch) > thresh) ? true : false;}

//bCompare compares two bools, returns a number depending if the first, second, both, or neither is true
int bCompare(bool _t1, bool _t2) {
   if(_t1 && _t2) return 3;
   else if(_t1 && !_t2) return 1;
   else if(!_t1 && _t2) return 2;
   else return 0;
}

//mTouch1 is muxTouch1, mTouch2, is muxTouch2, mLight is muxLight
void extra() {
   bool touche[2] = {mTSv(mTouch1, mTt), mTSv(mTouch2, mTt)};
   int doLight = bCompare(touche[0],touche[1]);
   
   if(doLight != 0) LSsetActive(mLight);
   else mLs0(mLight);
}



Thanks in advance!


Last edited by Michael120 on Wed Apr 17, 2013 8:04 am, edited 2 times in total.



Sat Apr 06, 2013 2:12 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3225
Location: Rotterdam, The Netherlands
Post Re: SMUX - Latency with Touch/Light sensors
Michael,

I am going to have see more code than just that snippet, I'm afraid. If you could make a small program that can replicate this issue, that would be great.

= Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Sat Apr 06, 2013 3:46 pm
Profile WWW
Rookie

Joined: Mon Feb 21, 2011 3:40 pm
Posts: 15
Post Re: SMUX - Latency with Touch/Light sensors
Sorry for the late response, totally forgot about this topic until I ran tele-op again.

That is the only code doing anything with smux, besides one other function checking if a single touch is pressed. I'll try to re-create it in a new program soon.


Wed Apr 10, 2013 7:42 pm
Profile
Rookie

Joined: Mon Feb 21, 2011 3:40 pm
Posts: 15
Post Re: SMUX - Latency with Touch/Light sensors
Hmm, your right, I re-created the program, and am getting a tick-time of 0-1ms.

Could it be I have too many functions, i.e. hogging up my ram, and am "writing to disk"(if the NXT does that)?

Is there a function to check how much RAM I'm using/is left?


Fri Apr 12, 2013 4:05 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3225
Location: Rotterdam, The Netherlands
Post Re: SMUX - Latency with Touch/Light sensors
Do you have code that writes to the flash? That is a very time consuming operation. I wouldn't worry about consuming too much memory, the compiler doesn't allow for dynamically allocated memory, so everything has been declared at compile time. If it fits at compile time, it will fit just fine at run time :)

Who knows what it was caused by, if you have multiple tasks, you might be causing deadlocks without even knowing it. My advice: avoid tasks like the bubonic plague.

= Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Fri Apr 12, 2013 4:30 pm
Profile WWW
Rookie

Joined: Mon Feb 21, 2011 3:40 pm
Posts: 15
Post Re: SMUX - Latency with Touch/Light sensors
Hahah, yes, I remember one FTC team telling me to put every individual motor into it's own function. While it's not a bad idea (in theory), making each check if the motor goes out of bounds, the way RobotC does functions...I'm not sure if it's worth it. :S

Anyways, I have three tasks, and none of them write to flash.

The first one is Main, and it goes through a while loop controlling the driving, other motors, servos, and an "extra" function that does the extra things(that can fit in the main task)(that was the one hogging it, and using the light/touch smux sensors).

Second is a Debug function, doing nothing but assigning values to global variables, so I can see them in the "Global Variables" section.

Third is an "excess_extra" task, that does things(like more while-loops) while the main task is still running.

Also, there's the Joystick tasks from the JoystickDriver.c, and there's a Gyro task from a gyro driver I found deep within the RobotC example files(works gloriously, by the way).


I'll try messing around with some stuff and pin-point it, but I have a bad feeling it's not what it seems to be...

EDIT: In your SMUX drivers...what happens if you try to read two values at the same time, in different tasks? Would it time-out?

EDIT 2:

Very strange, this is my only code;

Code:
#pragma config(Sensor, S4,     HTSMUX,         sensorI2CCustom)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

#include "drivers/hitechnic-sensormux.h"
#include "drivers/lego-light.h"

const tMUXSensor mLight = msensor_S4_2;

task main()
{
   while(true) {
      ClearTimer(T1);

      LSsetActive(mLight);

      nxtDisplayCenteredTextLine(2, "TickTime: %dms", time1[T1]);
   }
}


And I'm getting ~65ms every tick. I'll see if updating the drivers works...

Edit 3:
Thats a negative, the sourceforge link is giving me a 500 error. Will try tomorrow. :/


Fri Apr 12, 2013 7:00 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3225
Location: Rotterdam, The Netherlands
Post Re: SMUX - Latency with Touch/Light sensors
Michael120 wrote:
EDIT: In your SMUX drivers...what happens if you try to read two values at the same time, in different tasks? Would it time-out?

Unpredictable behaviour. Always read your sensors from a single task. It's like having multiple people shouting in your ear, telling you what to do and it's all different.

= Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Sat Apr 13, 2013 12:49 am
Profile WWW
Rookie

Joined: Mon Feb 21, 2011 3:40 pm
Posts: 15
Post Re: SMUX - Latency with Touch/Light sensors
Nothing changed...still getting ~63 ms of lag from that program. Can anyone else confirm?

Changing the SMUX's battery didn't work, neither did switching the port or unplugging everything else. :/

Code is two posts above...

Edit: Changing to "sensorI2CCustomFastSkipStates" speeds it up to ~54.5 ms a tick, but thats still not good enough. :/


Tue Apr 16, 2013 5:45 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3225
Location: Rotterdam, The Netherlands
Post Re: SMUX - Latency with Touch/Light sensors
Don't use that sensor type, the mux can't handle that speed. I'll take a look at the code and see if I can find anything.

= Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Wed Apr 17, 2013 3:44 am
Profile WWW
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3225
Location: Rotterdam, The Netherlands
Post Re: SMUX - Latency with Touch/Light sensors
Ok, I have figured out why this is happening. It had been a while since I wrote this driver but here it goes:
When you modify the configuration of a mux sensor, the mux needs to be put into HTSMUX_STAT_HALT. This is something that takes 50ms + the time it takes to do the I2C operations. After it is done modifying the channel settings, it will put the channel back into HTSMUX_STAT_NORMAL and the new configuration becomes active. The HTSMUX_STAT_NORMAL is when the MUX can poll things again. So basically your constant reconfiguration of the port is causing these long delays. I cannot change how this behaves, as the MUX simply requires the 50ms between changing modes and was never designed with such a rapid mode change in mind.

Regards,
Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Wed Apr 17, 2013 4:55 am
Profile WWW
Rookie

Joined: Mon Feb 21, 2011 3:40 pm
Posts: 15
Post Re: SMUX - Latency with Touch/Light sensors
Oh, so it can't be changed...I see. Well, thanks for the help! Looks like I'll have to find something else to use for a signal...

Thanks again!


Wed Apr 17, 2013 8:01 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 11 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.