Best way to detect a bot

Technical Electrical
1

I was wonder what sensors everyone has used in the past to detect other bots. It would be great for auton if our bot could detect the crashed bot infront of it and not add to the pile (I’m not trying to offned anyone, but accidents always happen). I don’t want to use the camera because of the high overhead. Here are some thought I had.
Heat signurtes of other bots (not sure if the are high enough, though)
Electric or magnetic field sensors
Transducer array
Vibration meter (see if there are vibrations different from my own)
Would like an infared or radio reaper, but that is illegal
Could we use the gaming adapter to sense the strength of other bot’s adapters and use that to tell when we are close?

I just want to see how others have done it.

2

I think an ultrasonic sensor combined with dead reckoning and pre-programmed knowledge of the field would do the trick. However, you don’t want to get too cautious: if a game piece falls in front of you, you don’t want to waste your time driving around it (unless they are heavy). I know there were robots (specifically lap bots) that could drive around traffic in autonomous mode last year.

Another idea I’ve had in the past was a microphone or microphone array, but being passive sensors, they would not work to detect a robot that has crashed and is just sitting there stalling its motors. They’d be more effective as a defensive autonomous mode, hunting out opposing robots and bumping them.

Other less-active options are to have a bunch of routes or delays that you can select from before the match to give maximum flexibility. If your alliance partners can only take a certain route, then delaying for a few seconds before starting your own autonomous might give them time to get out of the way. This can be achieved with banks of switches and potentiometers on the side of your robot, allowing for the run-time selection of varied modes.

3

One of my pipedreams is to use one of Cypress’s PSoCs as a capacitive sensor to detect robots. They claim they can detect a person at a distance of one foot using a stub of wire, but I bet you could optimize further and get some interesting results.

4

In my order of preference,
Radar, camera, ultrasonic. Magnetic sensors will be confused by rebar in the floor of most competition sites, heat will not have built up to a detectable level during auton, RF levels at such short distances will likely not give adequate collision avoidance.

5

Don’t forget touch sensors… they aren’t as exciting, but they ARE simple, cheap and reliable. Consider, for instance, the HexBug.

Jason

6

I didn’t want to use touch sensors because you have to actually touch the bot to know if one is triggered. That cap idea sounds very interesting. I like plyaing with radios, so I know how much difference a foot from the radio improves reception. Give me an hour or two, and I can probably have a schmatic up.

7

IR sensors played a huge role in the most satisfying FRC match I’ve ever had the pleasure of participating in. I’ve even got the video to prove it!

In autonomous mode of this match we (the robot with the red bumpers) picked up another robot with those Sharp IR distance sensors. I’m pretty sure that’s the exact model we used on that robot. Either way, I’ve used a few of the models and in my experience they work equally well. They were statically mounted, we turned the robot. We’ve experimented with mounting them on servos, but as always, we run out of time. A word of caution though, IR sensors will not see polycarbonate (Lexan) unless they are pointing directly at it (the “beam” is perpendicular to the Lexan). They also are not very reliable at seeing particularly shiny things (think polished diamond plate commonly found on FRC field). Those are our experiences anyways!

We’ve experimented with the MaxSonar sensors. Those also work well.

8

Who said you’ll WANT to avoid other robots in auto mode this year?:yikes: (Look at, say, 2006, 2007, 2004, 2003…)

9

Hey! I have experience here! :slight_smile:

Our 2008 (international rockwell automation award winning (couldn’t help it)) control system had this feature until the sensors caught fire at the Midwest regional. It worked great, but we never replaced the sensors.

I took it a little further than just stopping though. Our control system allowed for distance/bearing waypoints and arc commands, so the distance data from an array of 2 ultrasonic sensors on the front of the robot (after being washed through a continuous averager and rejection filter to get rid of individual sample point noise characteristic of vibrating ultrasonic sensors) was used as a ‘floating’ waypoint. This allowed the lower level acceleration/deceleration/velocity control layer to handle a smooth deceleration to a stop at a specified minimum distance from an object ahead (I had it at 36" since the sensor might be looking at something inside the robot ahead). The cool (unexpected) bonus? If the object approached the robot… the robot backed up to hold it’s distance. And, though it never occured in competition, since the waypoint handling layer sat where it was in the control structure, the robot could keep track of it’s position and reverse-interpolate an arc if that was the command it was currently executing.

Great feature to add. I highly suggest you add at least a little bang bang control loop to hold distance from an object as you approach… since then you can badge your robot as having adaptive cruise control! (ooooh! :] )

-q

p.s. to get back on topic, use ultrasonic sensors :o

10

First off, someone told me last year that IR, Ultrasonic, and radio sensors were illegal because they emit waves (first year for me, so I believed him). Secondly, I got a sensor book for Christmas and it had a schmatic similiar to this one.
Notes (This was the first time I used this program)

The transistor is a MPF102 FET
The loop antena is actuall just a plate or wire
The volt meter is an amp meter

The electroscope is designed to sense changes in the electric field around the object. If a robot got closer, the field would change, right?

electromscope.png
electromscope.png800×600 2.59 KB



electromscope.png
electromscope.png800×600 2.59 KB

11

While that circuit will detect changes in the EM field, it may not do what you want.

First, the number of windings in the antenna, length of the antenna, and the values of the RC circuit (coupling) behind the antenna will affect the efficiency of the antenna and center frequency.

The other issue you’ll face is filtering out the changing EM from your own machine. Your motors (Being closer to your antenna than any other robots motors) will greatly affect (possibly even completely washout) your ability to see another robots EM field.

12

What if I used an shielded antena? What I mean is what if the antena was shielded in the direction of my own motors. Also, I could take measuements before hand and figure out what level the EM is at when all motors on the bot ar running and use the code to filter them out.

13

Something tells me that the changing EM of the other robots will make that worthless. I don’t know much about this, but if the changing EM from your own motors is enough to wash out the antenna, then you aren’t going to be able to judge distance to other robots for the same reasons. The robot may be stopped, or the motors might be spinning at full power giving different EM readings regardless of where the other robot actually is.

14

I guess you guys are right. It still sounds like a cool idea, though. I guess I will stick to ultrasonics and IR like everyone else.

15

The only way I know that would shield your antenna (without interfering with its function) is to put a Faraday (sp?) cage around your motors which would affect their efficiency.

Also, Mr Freeman is correct that while you may be able to detect another robot by its EM emissions, judging its distance by field strength is probably not going to be effective/possible.

16

You don’t now, right?

Though we’ll find out what sensors are (not) legal for 2009 in a very few days…

17

Although it is not possible this year (and thus moderately unhelpful to you right now), the new control system has the capability for robot-to-robot communication.

So, you could get data from another robot (say GPS data, for example), and use that to navigate around the other robot. If you were really clever and had excellent programmers, you could also program in a sort of a map of the field too, and map out robots, obstacles, and such to make your autonomous mode even more robust and adaptable.

However, for the time being, you are pretty much stuck with IR, Ultrasonic, and Touch.

Someone mentioned sound- I personally don’t think that this is a terribly great idea, as competitions tend to be quite noisy, and you would be picking up a lot of background noise, not to mention your own robots’ noise.
One way you COULD make this work would be to detect very high frequencies (outside of any range you would get inside the field at the competition), and have two pre-made frequency emitters to give to your allies. However, I can’t recall the legality of noise emitters at competitions, so make sure to check first.

EDIT: Something else I just thought of that would definitely not work in FIRST, but would be pretty cool- Dark Knight style “seeing” via cell phones, and mapping out where your bot is

18

Folks,

Shielding sensors/antennae from ambient signals created by your own bot is possible.

Determining a constellation of bot signature characteristics that most FIRST bots are likely to exhibit is possible.

Detecting robot generated noise (em or acoustic) within the ambient noise of an arena is possible.

Using vision systems to track multiple moving objects and estimate which are the nearby robots is possible.

Computing estimates of these signals’ sources’ trajectories is possible.

Satellite receivers, deep space probe receivers, sonars and radars, FM radios, ham radios etc. all extract weak signals from relatively harsh noise fields. Some of these also estimate directions and ranges to the sources.

Doing these things on a FIRST bot is possible.

So, if you are really motivated - I say go for it. But you (and a friend or two you infect with your enthusiasm) really, really need to be motivated.

My hunch is that during this build season you would have enough time to do research that would give you a sense of how big the project will need to be ($ and labor hours), and to do some very simple proof-of-concept tests on one or two candidate sensors and computing platforms. Maybe you would stick some parts on this season’s bot to collect real world data.

Between now and next season you could probably develop something that would work well enough to be proud of it. Then you build a copy, equip the 2010 bot with it, publish results, and enjoy seeing the system work on the field.

Regardless of how well it works, you also get to enjoy telling the judges, other teams, and employers/schools about the mountains of math, software, and cross-disciplinary systems engineering you, your team covered along the way (students and mentors (you might need to connect with a specialist or two for this project)). You all will have exactly accomplished more than one of FIRST’s primary objectives.

This project is do-able, but it is not a “quicky” if you start from scratch. However, paying the price of success in honest effort, and being able to plan and guide a non-trivial project from start to finish are both very valuable skills to learn and practice using.

Again, if you are serious and motivated for the long haul, then I say “Go for it!” You eat an elephant one bite at a time. This is a hippo. Eating it will take you several “bites”, but it can be eaten.

Blake
PS: I’ll bet that I can connect you with some signal processing experts (filtering out noise, sampling correctly, detecting correlated signals, estimating ranges and bearings) and some guidance-and-control experts (deciding how to autonomously use the sensor/processor outputs to decide how to drive your bot toward a goal) if you can’t tap into an existing network of mentors here on CD or in your team’s circle of contacts.

19

I’m not sure how a faraday cage will affect a motors efficiency - that’s a new one for me. Can you help me understand?

Um…caught fire? :eek:

20

To my understanding the closer a Faraday cage is to a motor, the more it interferes (disrupts?) with the EM field driving the motor (creating a return to ground through the faraday cage).

… or maybe I’m just misremembering my inductance field dynamics.