Hi,
I stopped doing Vex for quite a while and now I’m back at it. I forgot a bit about Vex… So, my question is: How do I bring up the graphic display window? I tried the terminal window but nothing appears. Please help!
Thanks,
-FutureInventions
Pfft, I’m stupid. I find it ten seconds after posting this. 
Anyways, for anyone that wants to know, just go to the terminal window, hit “stop”, then check the box labeled “graphic display”. This only works in easy-C Pro.
lol
-FutureInventions
I do, though have another question. On the graphic display, it keeps making random lines and adding in text that shouldn’t be there! PLEASE HELP!
Thanks,
-FutureInventions
You have to be careful how much text you send it - if you over run the bandwidth you will get garbage.
Try feeding yourself with a fire hose sometime - same effect.
Try sending a little bit of stuff, if it is reliable, then add more and more until you get the garbage effect.
Also, send updates to the screen infrequently - Maybe 10 or fewer times per second - not every pass through the program loop.
Thanks! It sort of worked. I’m not getting random strings from the code, but I am getting numbers that I think are odd. I’m testing my accelerometer and I’m getting numbers in the hundred-millions. I’m not sure if this is a correct reading. I get around 200 million when it’s flat for the Z axis. it also like to give me numbers with dashes in the middle. I’m not sure if we haven’t learned this yet in school, but I don’t think that’s an integer. Do you have any other suggestions?
Thankyou so much for your help!
-FutureInventions
Print to screen’s doing the same thing! Is this a typical value for an accelerometer?
No. Can you post your code? In theory, the accelerometers are connected to Analog inputs, which have a 10-bit range, so the value should range between 0 and 1023.
In practice, my programmer plugged in a 3axis accelerometer and did print screen for all three values. If I remember correctly, X and Y readings were ~500 when held steady, and bounce up and then down and then back to 500 when moved. Easier than moving is to tilt it, and see how the gravity trades off between Z and the X and Y components.
Back to theory again, if you add the X value (offset by resting value of ~500) to a running total, the running total should be proportional to the current velocity in the X direction.
Hmmm… That’s really strange. The only things I can think of are that maybe I wasn’t supposed to save it as an integer and maybe I shouldn’t have used %d for the print to screen. Other than that, I have no idea. Here’s a picture of my code. It’s Easy-C Pro if I haven’t mentioned it yet. 
EDIT: Oh and, I’m a 7th grader so I have no idea what you’re talking about when you say “Back to theory again, if you add the X value (offset by resting value of ~500) to a running total, the running total should be proportional to the current velocity in the X direction.”. Could you explain? Also I’m just using the accelerometer to measure tilt now, so I’m using the print to screen to figure out the value I want for the counterweight to move.
You could try using something simpler than the Accel subroutines.
See if there is a “GetAnalogInput” option, and make sure the inputs you are plugged into are set to analog. I’ll check what my programmer kid did also.
In the future, if you can scout around to find ways to cut and paste code as text, it would help a lot, since that jpg was unreadable. My understanding is that the"pro" version allows direct text edits.
What is your counterweight application?
Thanks for mentioning your grade. I’ll try to scale back.
See also Kinematics - Wikipedia
- Gravity is same as Acceleration, so using Z axis as tilt should be fine, if the sensor is close enough to the point of rotation.
- Acceleration is the same as Gravity, the sensor cant have moved without accelerating, and that will add an error to the tilt sensor function.
- Calculus can be used to model the physics to relate position, velocity, acceleration.
- Position: x = position on the number line, a linear measure, like inches.
- Velocity: v = How x changes over time, a ratio, like inches/sec.
- Acceleration: a = How v changes over time, like inches/(sec * sec) = inches/sec/sec; A constant acceleration will keep you pressed back into the seat of your car a fixed depth.
- The running total I suggested is a way to integrate all the past changes in acceleration to find the velocity again.
- A running total of velocity should show the current position.
- In practice, this is reported to be difficult, see also http://en.wikipedia.org/wiki/Inertial_measurement_unit
Thanks so much for the explanation on acceleration and velocity! it really helped!
The analog input worked - sort of. I have values with a 5 in the first digit (I mean like the hundred millionth place) and the accelerometer sort of affects the values, but I see no comprehensible responses in any of the axis. The numbers in the wrong axis are affected and the only affect is that the first digit becomes a 4 instead of 5. I’ll post the code: https://vexforum.com/local_links.php?action=jump&catid=26&id=181
I don’t have Easy C Pro, so I’m unable to open your link.
Try this method of posting code:
I forgot to ask the programmer for his code, but I will emailed him tonight.
The number read from the Analog port should be an integer between 0 and 1024, not a floating point number.
If you are sending data too quickly, the screen might get corrupted, try adding a wait 1ms to your while loop to slow it down. Since you only need steady state tilt, and not accel, heck, add 500ms wait time. Print the value returned from all three analog ports X,Y,Z, and you should be able to see the tilt function exchange values between the X,Y,Z ports clearly; or at least make the leading 5 go to a 4 on Z, and the X or Y increase from < 100 to > 100.
Sorry, I couldn’t figure out how to get the code, even after MarkO’s instructions. I did add a “wait” of 500 ms even before, and it didn’t work. I checked to make sure I was storing only integers. The only thing I can think of now is that it’s the print to screen. I noticed that I get different types of values when I use different directives. I tried all of them, and not one gave me the right value. The values don’t even seem to respond to the movement anymore. I ruled out pretty much everything, unfortunately. Not sure what it is; it’s so weird!
Thanks for all your help! :)
-FutureInventions
I noticed some text strings in your BDS file, so I tried running unix command ‘strings’ on it and decoded most of the program. What I found looks like this:
void main ( void )
InitAccelerometer ( 1 ) ;
InitAccelerometer ( 2 ) ;
InitAccelerometer ( 3 ) ;
StartAccelerometer ( 1 ) ;
StartAccelerometer ( 2 ) ;
StartAccelerometer ( 3 ) ;
while ( 1 ) {
PrintFrameToGD ( 2 , 2 , 28 , 78 , 8388672 ) ;
Wait ( 500 ) ;
PrintToScreen ( "Z axis: %d%d\n" , (int)ZAxis ) ;
PrintTextToGD ( 5 , 3 , 16711680 , "Y axis: %d%d\n" , (int)YAxis ) ;
YAxis = GetAcceleration ( 3 ) ;
XAxis = GetAcceleration ( 2 ) ;
ZAxis = GetAcceleration ( 1 ) ;
PrintTextToGD ( 3 , 3 , 255 , "X axis: %d%d\n" , (int)XAxis ) ;
PrintTextToGD ( 7 , 3 , 65280 , "Z axis: %d%d\n" , (int)ZAxis ) ;
Tank4 ( 0 , 3 , 2 , 1 , 3 , 2 , 4 , 1 , 0 , 1 , 0 ) ;
}When I compare it to my EasyC for Cortex (about to expire in 9 days),
I dont understand why you have %d%d in your Prints instead of just one %d. Try this for code in the while(1) loop:
YAxis = GetAcceleration ( 3 ) ;
XAxis = GetAcceleration ( 2 ) ;
ZAxis = GetAcceleration ( 1 ) ;
PrintToScreen ( "X axis: %04d " , (int)XAxis ) ;
Wait( 100 );
PrintToScreen ( "Y axis: %04d " , (int)YAxis ) ;
Wait( 100 );
PrintToScreen ( "Z axis: %04d \n" , (int)ZAxis ) ;
Wait( 100 );
Now that there are waits, it won’t respond to movement as much, just to tilting. I still haven’t heard back from my programmer guy with the sample code that he used.
Dude, thanks SO much! I found out why there were two %ds. Somewhere I got the impression that you have to put the directive in the actual message too. That’s why I got values of so many digits! Thankyou so much!!!
That’s why I love this forum!
-FutureInventions
Copying the Source Code from EasyC doesn’t seem to work in EasyC Pro, only EasyC 1.1 and 2.x. I have reported this inconsistency, because it is a very helpful feature…