![]() |
Thanks for all your help...and a question
Quick question
I have the 2006 default code loaded up. If I wanted the trigger (fire) button on the 1 joystick controlling the robot movement to reduce the robots speed to 50% how would I do that. I tried: if (p1_sw_trig == 0) { pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127); pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127); } else { pwm13 = (pwm13-127)*0.5+127; pwm14 = (pwm14-127)*0.5+127; pwm15 = (pwm15-127)*0.5+127; pwm16 = (pwm16-127)*0.5+127; } but when the trigger was pressed nothing moved on teh robot! Any help? |
Re: Thanks for all your help...and a question
i dont know what u ment to do...
Dom you want the robot to move at 50% of its speed when u press the trigger and thats it? or do u also move the joystics Y farward? |
Re: Thanks for all your help...and a question
Basically; I want the joysticks to be waay less sensitive when i press the button. I basically want the speed to be halved at every point when the joystick moves.
|
Re: Thanks for all your help...and a question
oh i get it...
i havent toucked programming for a year but i can tell you what i'd do: if (p1_sw_trig == 0) && (p1_y==1) { pwm13=pwm14=pwm15=pwm16=(127+0.5*127); } else if (p1_sw_trig == 0) && (p1_y==-1) { pwm13=pwm14=pwm15=pwm16=(127-0.5*127); } |
Re: Thanks for all your help...and a question
Quote:
|
Re: Thanks for all your help...and a question
Your code never reads the joysticks if the button is pressed, so it repeatedly divides the pwm values by two until it decays to zero. That's why the robot stops moving.
Try moving the part that reads the joysticks outside the test for the button. Code:
pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127);By the way, if you plan to use timers and serial communication and encoders and other interrupt-based stuff, avoiding pwms 13-16 would be a good idea. They're generated by the user processor and can get somewhat twitchy when interrupts are happening often. Put your motor controls on pwms 1-12 if you want to keep things easy. (Note that I replaced the multiply by 0.5 with a divide by 2. Keeping everything as integers makes sure that the compiler doesn't try to do floating point calculations, which take up a lot more time and program space.) |
Re: Thanks for all your help...and a question
Question to Alan (or anyone),
I'm under the impression a >>1 instead of a /2 would work there and would (possibly?) be faster. We've tried this in some spots in code before, however, and I think it corrupts signed variables. Do you (or anyone) have any specific knowledge about the >> operator on this PIC? I was sort of hoping that it or some other operator will do a signed >> operation and carry the signed bit. |
Re: Thanks for all your help...and a question
Thanks a lot guys; Ill try this out today!
|
Re: Thanks for all your help...and a question
Quote:
|
Re: Thanks for all your help...and a question
Quote:
I was looking throug the MCC18 (Microchip's C compiler) User Guide and found this in Appendix B.4: Quote:
Good luck! |
Re: Thanks for all your help...and a question
make a function for it
[from regular code] if(p1_sw_trig){ dim_down(pwm01); } unsigned char dim_down(int input,float factor){ input-=127; input*=factor //the factor to dim down the output return input; } |
Re: Thanks for all your help...and a question
It won't work on signed integers, because in order to have fast add and subtract between positive integers most procecssors use a twos complement system.
Basically there is a sign bit, and if the bit is enabled then you reverse the 1 for a 0, so if a number is negative it is instead represented by it's not'd equivalent So -2 would be 11111110 (for an 8 bit signed char) The most significant bit is the sign bit. Now lets try adding -2 to 3: 00000011 11111110 --------- 00000001 Tada .. The extra bit overflows and is discarded... so we can use the same logic adding positive and negative numbers together ... yay! When you try to bit shift a signed int this is what may happen: 11111100 (-3) becomes 01111110 (126) You can still bit shift but the sign bit needs to be replaced... you can do this by XORing the result with 10000000 I actually don't think dividing by two using the bit shift operator really matters, most optimizing compilers should realize that an unsigned int is being divided by two and just swap that in at the assembly level. Secondly most first applications I have seen don't even come close to being computationally intensive enough to warrant such an optimization. (I don't know if this is actually what happens when using MC18 or whatever it's called) BTW: for printf I think you can just use %f to print floats |
Re: Thanks for all your help...and a question
Quote:
pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127); pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127); out of the if block, so that you get new data from the joysticks every loop. Then, if the trigger is on, you want to divide by 2, not multiply by a decimal Code:
pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127);Another way to do this would be: Code:
if (p1_sw_trig == 0) |
Re: Thanks for all your help...and a question
if(p1_sw_trig == 1)
{ pwm13=pwm14=(p1_y/2); pwm15=pwm16=(p2_y/2); } else { pwm13=pwm14=(p1_y); pwm15=pwm16=(p2_y); } isnt it as simple as that. |
Re: Thanks for all your help...and a question
Quote:
|
Re: Thanks for all your help...and a question
Quote:
although reducing speed with a button is a nice idea. i might try that out. |
Re: Thanks for all your help...and a question
just make sure to test the code with the robot up on blocks or something. just to make sure it wont do any damage
...forest |
Re: Thanks for all your help...and a question
Another way to do it would be to make a few lookup tables. We set up custom curves, so we had a large area that was slow for fine adjustments, and an area of full speed. This also makes so no calculations are needed on the fly, you just load them into the ram.
You would toss something like this (what we used) under the #include's in user_routines.c Code:
rom unsigned short int Joystick_Array[] = {0,4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,61,62,63,63,64,65,66,67,68,69,69,70,71,72,73,74,75,75,Code:
Left_Drive = Joystick_Array[p1_y];That makes so the variable "Left_Drive" and "Right_Drive" are modified pwm values, but not assigned to the pwm yet. To go with one joystick: Code:
if (p1_sw_trig == 0) |
Re: Thanks for all your help...and a question
(This is in regard to the post above mine, which I will not quote, for space considerations)
We do essentially the same thing, the only differences are, we use a slightly different equation, and our lookup table uses unsigned chars instead of short ints (although, in theory both should work, unsigned chars just take up less space). However, instead of just using ours for only our drive system, ours is used for every single joystick controlled movement on our robot. We have found that this greatly increases usability and driveability of our robot and its mechaisms by allowing fine control when necessary (like positioning the wrist for a ringer) and fast control when you need the speed (like driving across the field to a ringer). I would highly recommend at least trying exponential lookup tables, you may be amazed by the improvement such a small change can make. |
| All times are GMT -5. The time now is 23:34. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi