Putting robotics at your service™

Free shipping on orders over $200

Take in 4 Ultrasonic Sensors signal, but laggy movement ?

Print view Share :
Previous topicNext topic

Page 1 of 1 [ 11 posts ]

User avatar
Novice ( offline )
Posts: 55
Posted: 2010-09-24 00:15 
The code below is my code to read signal for 4 Ultrasonic Sensors.

The code below works fine reading the signal, however the robot moves in a really laggy way, such that it moves for half a second, stop, move for another half a second, stop again, and move until it finishes its cycle.

Code:
   low p4
   pulsout p4, 5
   input p4
   pulsin p4, 0, toolong, 40000, wdist4
   wdist4 = wdist4 / 148   ;convert for inches
   serout s_out, i9600, ["Distance4: ", sdec wdist4, 13, 10]      ;display result in terminal
   toolong:
   
   low p5
   pulsout p5, 5
   input p5
   pulsin p5, 0, toolong1, 40000, wdist5
   wdist5 = wdist5 / 148   ;convert for inches
   serout s_out, i9600, ["Distance5: ", sdec wdist5]
   toolong1: 
   
   low p6
   pulsout p6, 5
   input p6
   pulsin p6, 0, toolong2, 40000, wdist6
   wdist6 = wdist6 / 148   ;convert for inches
   serout s_out, i9600, ["Distance6: ", sdec wdist6]
   toolong2:
   
             low p7
   pulsout p7, 5
   input p7
   pulsin p7, 0, toolong3, 40000, wdist7
   wdist7 = wdist7 / 148   ;convert for inches
   serout s_out, i9600, ["Distance7: ", sdec wdist7, 13]
   toolong3:


If I were to take no signal or only 1 signal , such that
Code:
   low p4
   pulsout p4, 5
   input p4
   pulsin p4, 0, toolong, 40000, wdist4
   wdist4 = wdist4 / 148   ;convert for inches
   serout s_out, i9600, ["Distance4: ", sdec wdist4, 13, 10]      ;display result in terminal
   toolong:


then the movement will be smoother.

May I ask what can I do with the program, while taking in all 4 signals from the Ultrasonic Sensors, and also at the same time not causing the movement to be 'laggy' ?


User avatar
Guru ( offline )
Posts: 4122
Posted: 2010-09-24 13:38 
You have all four ranging routines in-line, before getting back to moving the 'bot. I'd make a generalized subroutine that ranges only one sonar each time it is called. That way, there's not a long break between ranging and giving the 'bot commands to move.

Hum, I wonder if that will give me problems. I will be mounting 6 SRF08 sensors on MicroMoose. I2C, maybe they take less time to read.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


User avatar
Novice ( offline )
Posts: 59
Posted: 2010-09-24 18:05 
Not sure if this is applicable to your situation. I have an Arduino microcontroller that outputs data to an LCD display, but as it's hardware serial port is occupied with controlling servo's I use a software serial library instead. With this I found times where the program would pause between servo movements, as software serial can't perform other actions whilst sending data.

If this is indeed the problem you are experiencing then just as a test you can try commenting out all serout commands. If that solves it then to output messages again I'd suggest you try and send data as infrequently as possible, and/or increase the baud rate used.

I performed these actions and this solved the problem for me. Maybe this will work for you too.

-1

_________________
BSc Artificial Intelligence & Robotics | PhD in progress
[b]Project Infuser Progress|[/b]
http://www.lynxmotion.net/viewtopic.php?f=20&t=8225
Hardware - [color=#00BF00]95% Complete[/color] |
Software - [color=#FF9F00]40% Complete[/color]


User avatar
Novice ( offline )
Posts: 55
Posted: 2010-09-25 08:19 
Zodius wrote:
Not sure if this is applicable to your situation. I have an Arduino microcontroller that outputs data to an LCD display, but as it's hardware serial port is occupied with controlling servo's I use a software serial library instead. With this I found times where the program would pause between servo movements, as software serial can't perform other actions whilst sending data.

If this is indeed the problem you are experiencing then just as a test you can try commenting out all serout commands. If that solves it then to output messages again I'd suggest you try and send data as infrequently as possible, and/or increase the baud rate used.

I performed these actions and this solved the problem for me. Maybe this will work for you too.

-1


Hi that is indeed what I have done, i commented out the serout commands, that did not solve the problem.
I increased the baud rate, that did not solve, increasing the baud rate just increases the movements of the leg.


User avatar
Novice ( offline )
Posts: 55
Posted: 2010-09-25 08:21 
KM6VV wrote:
You have all four ranging routines in-line, before getting back to moving the 'bot. I'd make a generalized subroutine that ranges only one sonar each time it is called. That way, there's not a long break between ranging and giving the 'bot commands to move.

Hum, I wonder if that will give me problems. I will be mounting 6 SRF08 sensors on MicroMoose. I2C, maybe they take less time to read.

Alan KM6VV


Hi I do not really understand what you are saying when you say 'four ranging routines in-line'.
'make a generalized subroutine that ranges only one sonar each time it is called'.

Sorry but can you elaborate a little further ? :oops:


User avatar
Guru ( offline )
Posts: 4908
Posted: 2010-09-25 10:25 
I think he is saying that you should take all of your inline code for reading the 4 sensors and create a function for it. Maybe something like:
Code:
bWhichPin var byte
wDist var word
ReadSensor[bWhichPin]:
   low bWhichPin
   pulsout bWhichPin, 5
   input bWhichPin
   pulsin bWhichPin, 0, toolong, 40000, wDdist
   wDist = wDist / 148   ;convert for inches
   serout s_out, i9600, ["Distance", dec bWhichPin, ": ", sdec wDist, 13, 10]      ;display result in terminal
   toolong:
   return wDist

Note I did this on the fly did not compile or like so may be problems...

To make the code work like before you would simply put in code like:
Code:
gosub ReadSensor[4],wdist4
gosub ReadSensor[5], wdist5
gosub ReadSensor[6], wdist6
gosub ReadSensor[7], wdist7


But that would not gain you much... So instead you could setup the code to only read one of these sensors per loop. Maybe something like:
Code:
...
bPin var byte
awDist var word(4)     ; use an array instead individual variables to make it easier...
bpin = 4   ; initialize which pin you are going to read...   You may want to read all of the sensors once before you get to main
Main:   ; assumes this is where you loop up to...
   gosub ReadSensor[bpin], awDist(bpin-4)   ; array is zero biased so subtract 4 to get to first element...
   bpin = bpin + 1
   if bPin > 7 then
      bpin = 4
   endif
...

So each time through the loop it only reads one sensor. T

here may be some other far more complicated ways to do this, which unless you are familiar with assembly language or the like may be overkill. Things like try to setup the sensors on IO pins that can capture when the transition's of the pulses happen... But unless you wish to really spend a lot of time figuring it out, I would probably avoid...


User avatar
Guru ( offline )
Posts: 4122
Posted: 2010-09-25 13:46 
That's got it Kurt. only one ranger read per main cycle, and a mechanism to rotate through them.

I hope the I2C overhead is not that much! But I think the SRF08 modules basically "range" on their own, and only a "read" is needed.

I guess I'll find out in a few weeks. I've got the remaining sensors coming in next week.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


User avatar
Guru ( offline )
Posts: 4908
Posted: 2010-09-25 16:00 
KM6VV wrote:
I hope the I2C overhead is not that much! But I think the SRF08 modules basically "range" on their own, and only a "read" is needed.

I guess I'll find out in a few weeks. I've got the remaining sensors coming in next week.

The nice thing with the SRF08 and I2C is that you can do several different strategies. That is you can go to all 4 tell them to do their pulse and then come back later to get the results...

Kurt


User avatar
Guru ( offline )
Posts: 4122
Posted: 2010-09-25 16:56 
I had a sensor coded in C for Loki. But in that code I had to write the driver, using the built-in port. For AtomBasicPro (ARC-32), I believe I can use a built-in I2C function.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


User avatar
Novice ( offline )
Posts: 55
Posted: 2010-09-27 23:33 
Great ! Reading one sensor per cycle is working ! It is not moving in such 'laggy' movement now.

However is there a way to increase the speed of reading per cycle ? Or it really depends on the chip that we can't change ?


User avatar
Guru ( offline )
Posts: 4122
Posted: 2010-09-28 14:43 
Glad you got it working faster!

I doubt if there is much that can be done. The older sensors required more "hand holding". I2C might be faster, but I haven't compared.

You might investigate "firing" all four at one time (more current required), and then reading them in quick succession. I don't know if that can be done with Basic.

In the I2C versions, the parameters for return timeout can be modified, and the readings obtained faster. I don't know about your model, I rather doubt it.

Alan KM6VV

munchu87 wrote:
Great ! Reading one sensor per cycle is working ! It is not moving in such 'laggy' movement now.

However is there a way to increase the speed of reading per cycle ? Or it really depends on the chip that we can't change ?

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


 

All times are UTC - 5 hours [ DST ]. It is currently 2014-09-30 17:54
Feedback Form
Feedback Form