OK, so even though I don’t have 16 sensors to work with (max you can use). But I still had a crazy (or maybe not) idea to make the ULTIMATE sensor robot. Pretty much here is my idea
[list]
*]Bumper Switch x4 - 2 in front 2 in rear
*]Limit Switch x2 - 1 in front 1 on rear
*]Optical Encoder -x? however many I need to keep track of my axles
*]Gyro Sensor x1 -middle of robot
*]Ultrasonic Sensor x1 - middle mounted on infinite-degrees-of-motion turret
*]Accelerometer x2 - 1 per side
*]CMUcam -x1(maybe 2) pan/tilt setup
*]Line Follower x1 - wherever
*]Light Sensor x1 - middle
[/list]
So here is the crazy part. The bumper switch will detect if it hits something and where (front/back left/right). The limit switch will act as a “cliff sensor”, if the switch is released (instead of tripped) it will stop the robot and go in the opposite direction. The optical encoder will be to help make precision autonomous turning possible. The gyro will be to detect the current position of the robot relative to the starting position. The ultrasonic sensor will be able to detect how far away and object is in order to try and be able to avoid the object, and will rotate to the “relative forward” (current forward direction the robot is moving). The relative forward will be determined by the gyro. Accelerometer will be to control the speed the robot moves at. CMUcam will be to either track a certain object/color/light and possibly to do something that will be able to get the current image and then use the Ultrasonic sensors to drive autonomously through some course (much like the DARPA Grand Challenge). The line following sensor/kit may or may not be used (can’t think of a reason to use it right now…). The light sensor will be used to sense a change in light relative to the starting light. If the condition changes, it will slow the robt down for a few seconds, and then (hopefully) re-calibrate the different optical sensors, which right now is only the CMUcam.
SO, any ideas to add to this? Or can you think of a way to implement some of these ideas (especially the on-the-fly recalibration of the CMUcam)?
sounds pretty cool, but neither do i have the right sensors. i have all of the vex sencsors, and one CMU cam, but i dont know how to use it. good luck to anyone that can incorporate at least 10 sensors into a single robot.
Looks like you have a lot of redundancy with the sensors. Maybe you only use shaft encoders or accelerometers since they both do the same job. Coding for this robot would not be fun and you could run into problems with data management.
I have actually put together a similar robot with most of the named sensors on a squarebot. This was mainly to be used as a test bed for developing code for competition vex bots. I have a CMU cam but did not install it. Instead I installed a wireless low light camera. I sometimes use this robot for making presentations to recruit new teams and it makes for fun challenge to drive it around corners or into other rooms by just looking at a screen. We have used just Vex sensors and most likely will not utilize all of them at one time. So far the only sensors installed are:
2 Limit Switches (used as whiskers)
2 Optical Encoders
2 Ultrasonic Sensors (fixed vertically on both front corners)
3 Line Following sensors
I would like to incorporate a combination gyro/accelerometer but will hold off on that until a later date.
Anyway, the other reason for putting on all these sensors was to begin the development of an off season game we are designing which will be all autonomous. No operator control at all.
We have tested easyC Pro with all of the following sensors on a single base bot.
CMU Cam
Quad Encoders
Vex Optical Sensor
FRC Gear Tooth Sensors
FRC Kit Gyro
FRC Accelerormeter
Vex Ultrasonic Sensor
Optical Vex Encoder
Bump Sensor
I think it is possible, but I think you will run into many problems with this. I wouldn’t expect for you to be able to try to program it within a couple days. This little project will be strenious, good luck. I think that you have too many sensors b/c you have sensors to keep away from a wall or whatever and you have many sensors to reverse or what have you when they hit something. What I am trying to say is that half of the sensors will be useless because you will be trying to avoid walls, yet you have sensors to come in contact with walls. If you don’t hit a wall, then those sensors will not be needed, unless you are just trying to prove a point that you can put that many sensors that are oporational on a robot. In that case, go on ahead.
It would mainly be a test bed for bunch different ideas I have. Help me gain experience in “real” programming. And just a fun little side project… I just need the sensors now… lol 
You don’t have the sensors!?
:eek:
Programming VEX…ha…ha…ha
Programming is the fun part of VEX. Building can be too. The thing with programming is watching your robot execute some auto code and knowing that you told it to do that. Kinda makes you feel like you could conquer the world…
Programming for our team is a hassle. We despise it. We are switching to MLAB next year b/c we have had so many problems with easy C. Easy C is our enemy.
FYI gamerfreek Mplab is not easier to use than easyC. Yes you can do a lot more in it than in easyC but it is also a lot more advanced. You need to know C in order to use it. I’d stick with easyC. What problems were you having?
Trust me, our team knows that Easy C is suopposed to be easier, but all the classes for these kinds of programming are Mplabs, not C.
I predict that after having used both, most people will say that the benefits of ordinary C outweigh the costs, and that therefore, ordinary C nets out to being easier than EasyC for most non-beginner / non-trivial programs.
Remember, a programmer isn’t a beginner for their entire life.
Once you get past the initial hump of decoding all of the crazy acronyms (the #DEFINEs) and wrap your head around the timeline that, in the sample code I have seen, is commented only moderately well (in my opinion it should be commented better); then I predict ordinary C will feel very liberating to someone who has grown tired of the EasyC training wheels.
You won’t have to know “all” of C to write reasonably sophisticated programs, and you will get to use any decent editor that you care to choose. This summer I hope to get around to finally digesting all of those awful acronyms and never looking back (except to help other folks).
Blake
I was just going off of my teams experience. We tried Mplab and ended up going back to easyC since Mplab wasn’t being nice to us. We had problems with the FVC Mplab template and didn’t want to risk getting DQed for code errors.
Also maybe our M/C was bad but it didn’t seem to like switching from the easyC mastercode to Mplab master code and back.