How do you use a Vex accelerometer to detect a collision? I’m concerned that the loop that reads it won’t be able to update its information fast enough to detect the spike. Do you need to read it in a separate task or how do you ascertain you can detect the collision spike?
Easy way to find out is to use writeDebugStreamLine() and print out the values. Then just save that as a file on your pc and import into excel and graph.
lmk if u need clarification on that process.
Thanks. I guess what they really want to know is do they need to monitor the accelerometer in a loop all the time and compare the readings on each loop (using RobotC) with a threshold, or is there a way to set up RobotC so that if the accelerometer ever exceeds some threshold value, then it can set a flag, etc. I think the worry is that if the loop isn’t fast enough, the code might totally miss a sudden spike.
yeah, I get what you are saying. And I applaud you for recognizing this problem of choosing a relevant sample rate. What I’m trying to suggest is play with it and graph the output, you may be surprised at what you see. I personally don’t know the answer (I can test on Monday), but you might be able to discover it. Perhaps you will discover that 100 hertz (the speed most robots run at) is enough or perhaps you will find that it isn’t.
If not, look into the implementation of some sort of interrupt system which dedicates more processor time based on an initial flag. I think there is probably a way to do this, but first I’d urge you to examine the data before doing all that work ;).
LMK what you decide to do or discover or if you have any further questions. I am curious to see what you come up with.
It may miss a sudden spike, I will try and setup a quick test and look at this tomorrow, if the spike is more than 2 or 3mS you should be able to detect it. I’ve only ever used the accelerometer as a tilt sensor but I know others have tried to use it in this way in the past.
there u have it FullMetalMentor. Jpearman himself is gonna get u the data 
I’ll be back here tomorrow for results. I’m guessing its unlikely that you’re spike is that short from any substantial collision.
Awesome. Thank you both! I don’t have one to test right now so I wanted to ask before I sunk some money into one.
Did a quick test. Here is a scope capture of hitting the accelerometer into my hand to simulate a collision (no time to actually setup a robot to look at this). It’s slower than you would think, lasts about 50mS - 100mS.
Some code I had running at the same time.
#pragma config(Sensor, in1, accel_1, sensorAccelerometer)
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//
task accel() {
int value = 0;
int old_value = 0;
while(1) {
value = SensorValue( in1 );
//writeDebugStreamLine("%d", value );
if( value < -20 && old_value >= -20 ) {
writeDebugStreamLine("Bump");
}
old_value = value;
wait1Msec(5);
}
}
task main()
{
startTask( accel );
while(1) {
wait1Msec(10);
}
}
Interesting! Okay, I’ll invest in this and see what the kids can do with it. Thanks so much!
Guys stop! This is a trick question. Accelerators don’t have eyes or cameras to see the collision with…
Indeed. IN FACT, I have never even heard of an “accelerator” in the context of a sensor or robotics. Perhaps someone ought to double check on that 
Don’t try to meme when u r the meme.
Good to know. Thanks. So @FullMetalMentor to clarify, that means that even a quick colission at 50 mS will give you approximately 5 readings when running your user code on the cortex at the standard 100 hertz rate. Its actually not much to work with but the difference is pretty substantial compared to the accelerometer’s noise so I’d say you can probably work something out. Assuming you’re bot is moving at a fairly constant speed from the get go…
I still proudly stand with my findings:)