View unanswered posts | View active topics It is currently Mon Sep 01, 2014 10:19 pm






Reply to topic  [ 18 posts ]  Go to page Previous  1, 2
Last minute problems with sonar 
Author Message
Rookie

Joined: Wed Feb 18, 2009 4:06 pm
Posts: 12
Post Re: Last minute problems with sonar
BTW. I just noticed something else in your code. You put a 50 msec wait at the end of your loop, which was not in mine. What happens if you read the sonar too fast? What kind of values come back?

Also, I put in 8 bits because I couldn't use the precision. I assumed 10 bits would be slower then 8 bits?

Peter


Mon Mar 02, 2009 4:57 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3209
Location: Rotterdam, The Netherlands
Post Re: Last minute problems with sonar
pbesen wrote:
Thanks,

I actually have a day job, so I won't be able to get to this until this evening.

Will report results in ~5-6 hours.

Peter

It's a shame when work gets in the way of robotics, isn't it?

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]


Mon Mar 02, 2009 4:59 pm
Profile WWW
Novice

Joined: Fri Oct 24, 2008 8:58 am
Posts: 87
Post Re: Last minute problems with sonar
Quote:
You put a 50 msec wait at the end of your loop, which was not in mine. What happens if you read the sonar too fast?


As I understand it, the internal RobotC drivers update the SensorValue array when they actually get a new value, not when you read from the array (I think its just a normal array not some magical code like in other places of RobotC). So no I doubt you'd get any weird values from reading it faster.

I did get the ~1004 values with your original #pragma section (sorry I failed to mention that I replicated your issue and then fixed it)

I always put some sleep delay in loops so I ensure other parts of the program get time to run. Since I can't see their code and there is very little documentation, I don't trust their preemptive multitasking when everything is running full bore. I always make sure loops either sleep or give up the rest of the time slot.

In this case you're writing an actual control loop so I recommend setting a specific loop time rather than it being based on the amount of code in the control loop. Running the code as fast as it can is probably counterproductive and difficult to fine tune. You need to give the motors and robot inertia time to respond.

Mostly the 50msec delay was so long just to point out that the sonar values won't change any faster than that so if you're trying to drive based on them you have to realize there will be some "lag" that you have to take into account.

In your case, you are just stopping at a limit. You should be able to tune the stopping point pretty well since the robot will be going about the same speed every time it hits that threshold.

I'd set your loop delay time based on making the line detector work well and not so much the sonar. The motor controllers are updated every 20msec by default I believe. This is also pretty good rate for the the HTPB (although it can handle much faster ... see xander's blog http://mightor.wordpress.com/2008/10/25/taking-i2c-to-the-max-on-the-nxt/).

good luck.


Mon Mar 02, 2009 5:23 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 18 posts ]  Go to page Previous  1, 2

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.