|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
||||
|
||||
|
Using and Coding an ultrasonic sensor
Has anyone ever tried to use an ultrasonic sensor on your FIRST robot? I am trying to get my team to use more sensors in our autonomous program; we have used dead reckoning almost every year and I think it is time for us to move to the next level of autonomous programming. I think that ultrasonic might be a good method of navigating around a FIRST playing field...what do you think? I was thinking of using a sensor such as this one . Can you recommend a better one? How do you write the code for a sensor like this?
Thank you so much for helping!! |
|
#2
|
||||
|
||||
|
Re: Using and Coding an ultrasonic sensor
Just to add to Jaine's question, is there any way that these sensors may be programmed in such a manner that they will not react to other robots on the field but rather, just the playing field itself?
|
|
#3
|
||||
|
||||
|
Re: Using and Coding an ultrasonic sensor
Quote:
The sensor you listed here wouldn't have been allowed this year (I don't think any of the approved suppliers carry it). Hopefully the rules will be relaxed next year, but you never know. I don't have experience with any of these sensors, however we did investigate the use of them for our robot this year. Depending on what the rules are next year with regards to infrared emitters on the robot, there's some IR rangefinder devices that I believe are much cheaper than these ultrasonic ones. Writing code for proximity sensors depends a lot on the sensor in question. Many of the IR prox sensors just output an analog voltage (hook it up to an analog input on the RC and just read the value! Pretty convenient!) The sensor you selected above appears to work a little differently and would be harder to work with. Basically you hook the output of that sensor up to a digital input on the RC, and after you tell it to measure distance, it will send a high signal to the digital input for a length of time that is proportional to the distance to the target. This means you need a good way to accurately measure time. So, you need to set up one of the timers on the processor to run at a known rate, then you probably want to hook the sensor up to an interrupt line and trigger the interrupt on both the rising edge and falling edge (I believe the RC supports this, but it's been a while since I looked at it). Then you just start the timer when you get the rising edge interrupt and stop it when you get the falling edge (and don't forget to account for rollover). Obviously it'd be a lot easier to try to find a sensor that just gives you an analog output ![]() Quote:
|
|
#4
|
|||||
|
|||||
|
Re: Using and Coding an ultrasonic sensor
I think the best way to use a rangefinder would be in conjunction with other methods of navigation. For example, one could use wheel rotations or maybe an Inertial Nav system to guide the robot to a specific area and then make fine tuned movements based on ultra sonic input.
That's what I'd do anyway... |
|
#5
|
|||
|
|||
|
Re: Using and Coding an ultrasonic sensor
We're starting to use an ultrasonic sensor on one of our research robots. This sensor would have been illegal last year; however, with the digikey ultrasonic sensors being discontinued, there may be no options for this type of sensor unless the rules are changed. (HINT. HINT.)
The company which makes this sensor is senscomp (formerly polaroid) and can be found at www.senscomp.com. They have a variety of options. But, one option is to output an analog value proportional to the distance from your robot. The range is 6" to 10' (off the top of my head). The sensing angle is a 15 degree cone. As for deciding whether an object is another robot or part of the playing field... if it moves without any intervention from you, it's probably a robot. If it stays put, it's either playing field, dead robot, or movable playing field artifact. I'm not sure how much use mapping would be or using a pre-stored map to help navigate. It's too easy to get knocked off course, run into an impediment, experience sensor failures, set up in a non-aligned initial position, etc. Using odometry and GPS is probably a dead end if the task relies on complex interaction with the playing field. |
|
#6
|
||||
|
||||
|
Re: Using and Coding an ultrasonic sensor
Quote:
Last edited by Adam Y. : 05-08-2004 at 13:46. |
|
#7
|
|||
|
|||
|
Re: Using and Coding an ultrasonic sensor
The sensor mentioned here was used in the Frontiers Robotics summer program at WPI. We chose it mostly because of the cost and the chance to illustrate some advanced programming issues like interrupts and timers.
Another ultrasonic sensor is available from DigiKey and does provide an easier interface - it outputs an analog value proportional to the distance measured: http://dkc3.digikey.com/PDF/T042/1310.pdf the 387-1000-ND. It is true that using ultrasonics on a robot is subject to "interference" from other robots and objects that get in the way. We used ultrasonics in the team 190 robot to autonomously detect the stairs, then the upper platform where we were assured that there would be no obstacles or other robots interfering. As was mentioned, you need to integrate the information from other sensors to provide a better picture of what's going on around the robot. We used wheel encoders for precise distance measurement and gyros for pitch and turn information in addition to the ultrasonic rangefinder. Between all of these sensors we were able to successfully hang autonomously in most matches. |
|
#8
|
|||||
|
|||||
|
Re: Using and Coding an ultrasonic sensor
I encourage everyone to think about using the summer/fall to improve the sensing capabilities of their robots. Some of us have a vision of the future that includes full utilization of all three elements of the "sensing-mobility-manipulation" pyramid. Those who can see their way to learning about these technologies will probably find it a worthwhile pursuit.
When you have integrated a few sensors on your robot, you may want some exercises to better understand what you can do with them. I would like to suggest this reference as a starting place to look for a few ideas. -dave |
|
#9
|
||||
|
||||
|
Re: Using and Coding an ultrasonic sensor
Quote:
Also the infared emitters have a maximum distance of three feet. The ultrasonic emitter has a rating of 3 meters. Infared sensors don't detect anything transparent to infared light. Ultrasonic sensors have a hard time detecting fuzzy things. Both sensors have a hard time detecting things at a steep angle due to the fact that the signal gets bounced in the wrong direction. You can ask me anything about sensors. Im pretty knowledgable about them. |
|
#10
|
|||
|
|||
|
Re: Using and Coding an ultrasonic sensor
Quote:
|
|
#11
|
||||
|
||||
|
Re: Using and Coding an ultrasonic sensor
Quote:
|
|
#12
|
|||||
|
|||||
|
Re: Using and Coding an ultrasonic sensor
Quote:
During recent utilization of the spectrometer the device attempted to execute a number of standard operations, with anomalous results. When the sensor payload software attempted to turn on the payload FPGA, the FPGA failed to power on before the FPGA Power On Timer timed out. Subsequently, the payload software issued a MTES image command. The MTES image command failed due to an MTES interface timeout. Further MTES image commands failed similarly, and generated several more instances of the FPGA Power On Timer timeout EVR. A fault EVR was then generated due to the failure of the PMA azimuth actuator to move. However, since there is a hardware level handshake between MTES and PMA, this is likely to be a secondary failure due to the failure of the FPGA to power on during the original attempt. Initial analysis of the anomaly indicates it is likely due to an insufficient interval between the MTES_ABORT_IMAGE command from e3383 and the subsequent MTES_IMAGE command from p3576. If the timing is "just right", the pyld software can be put into a state such that all subsequent attempts to power the FPGA will fail. Only a reboot clears the condition. We are currently attempting to recreate the anomaly on the spare backup robot to better understand the condition. In the interim, use of the APXS and other spectrometers, as well as the PMA, is precluded until the anomaly is resolved. Since you have urged that we can “ask you anything about sensors,” we would welcome any advice you might offer… -dave (sorry, but I just couldn’t resist when you left yourself open with a line line that… ) |
|
#13
|
||||
|
||||
|
Re: Using and Coding an ultrasonic sensor
Comon Dave, clearly you ran your robot into a wall, stalled the motors, and burned a CIM... Anyone could tell you that...
BTW, is/was this a problem with one of the Mars rovers? |
|
#14
|
||||
|
||||
|
Re: Using and Coding an ultrasonic sensor
Quote:
![]() |
|
#15
|
||||
|
||||
|
Re: Using and Coding an ultrasonic sensor
Quote:
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|