Go to Post PS: Sorry for derailing this thread even further. - Molten [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 24-04-2007, 08:29
Roger Roger is offline
Registered User
FRC #1153
 
Join Date: Jan 2006
Rookie Year: 1900
Location: Walpole MA
Posts: 685
Roger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond repute
Re: Default code question

I can flesh out CyberWolf_22's answer with a more long-winded answer. He snuck in while I was still typing. (Young whipper-snapper! ) His answer I assume is correct as it does work on the robot. One thing I've learned is to know what does or does not need fixing.

There are some twists in the code which should be cleaned up, and actually Kevin Watson (of kevin.org) suggested removing Default_Routine() because of conflicts and using a modified version to use with his code. I'll assume you at least understand the C commands.

Code:
p1_x = 255 - p1_y;
p1_y = 255 - pwm05;
Why x and y is switching? Dunno. My guess is when this code was written the joystick controls were different. I rewrote this so x was x and y was y. You can test it on your own robot by switching it back. The "255 -" part just reverses the number from 0~255, to 255~0. Again, you can test this. Nothing like real-life testing to prove things.

Why pwm05? This is the sneaky part. Look above where all the pwm's get mapped from various joystick controls. pwm05 is set to p1_x. If you use

Code:
p1_x = 255 - p1_y;
p1_y = 255 - p1_x;
then p1_y will actually be set to 255 - ( 255 - p1_y ), not what is intended. The programmer just sneaked the number from another variable.

Why they mapped out all the pwms like that probably goes back to the dark ages of this code. There is a lot of code in Default_Routine() that is, well, default code, in case you didn't customize it for your own use. I commented most of it out and just used a simplified version of the above.

The second part,

Code:
pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127);
pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127);
is one of those things you just have to trust. What, you thought I knew the answer? Like your senior programming friend, I know it works so why try to fix it?

Well, actually, back in January I did have to figure it out, and you can do the same. I made a simple spreadsheet that plugged in a range of p1_x and p1_y. Sometimes you just have to do the math. All I know is that it mixes the forward-backward of the joystick with the left-right to get how much power the two left and two right motors get.

Limit_Mix() is just a fancy function to limit the range of numbers to 0~255. The adding of 2000 just makes it easier for C variables, shifting the number line to a positive vaule, and is subtracted out when returned.

One thing that spreadsheet did show me was the secret of reversing the motors on one side, which is why I made it. If your robot is a "standard" built one with four motors, two on left and two on right, then two of your motors are backwards. That is, they spin in the opposite direction to the other side's motors to make the robot go forward. In past years we've (meaning the robot builders -- they don't want me building things!) just reversed the wires on those two motors. Red to black instead of red to red, which is a big no-no. This year they decided it was a programming problem (funny how it always ends up a programming problem), and I knew there was a simple solution. I did the spreadsheet to test out different combinations and the answer is:

Code:
pwm13 = pwm14 = Limit_Mix( 2000 + p1_y + p1_x - 127);
pwm15 = pwm16 = Limit_Mix( 2000 + (256 - p1_y) - (256 - p1_x) +127);
Andy, you have the programmer's mindset, posting your question at 1:24 AM -- the best programming is done after midnight!

Roger.
  #2   Spotlight this post!  
Unread 24-04-2007, 23:11
Jake M Jake M is offline
void* Jake;
FRC #1178 (DURT)
Team Role: Programmer
 
Join Date: Jan 2006
Rookie Year: 2005
Location: Missouri
Posts: 118
Jake M has a spectacular aura aboutJake M has a spectacular aura about
Re: Default code question

The two equations that combine the X and Y values look confusing because they're simplified for space. There's actually some theory behind it. The un-simplified version looks like this.

Code:
pwm13 = pwm14 = Limit_Mix(2000 + (p1_y - 127) + (p1_x - 127) + 127);
pwm15 = pwm16 = Limit_Mix(2000 + (p1_y - 127) - (p1_x - 127) + 127);
Make more sense? There's three basic steps.

1: subtract 127 from the joystick values, so that the range is -127 to 127, rather than 0 to 254.

2: The theory behind the equation is that as Y changes, the motor outputs increase or decrease with each other. As X changes, the motor outputs become farther apart. Think about it. If Y increases, increase the output to both motors, to make them go forward. If X increases (left turn) you put one wheel forward, and the other in reverse. Thus, the basic idea of step 2 is that one wheel is Y + X, and the other is Y - X.

3: Add 127 to the final result, to make the range 0 to 254 once again.

And as for the one reversed motor, we usually just wire it in reverse, rather than make the code more complicated. For one, our main programming mentor would (bleep) about it if the code wasn't exactly perfect, and it makes it that much easier to understand months later.
__________________
Code:
void function(void)
 {
  function();
 }
  #3   Spotlight this post!  
Unread 25-04-2007, 07:44
Roger Roger is offline
Registered User
FRC #1153
 
Join Date: Jan 2006
Rookie Year: 1900
Location: Walpole MA
Posts: 685
Roger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond reputeRoger has a reputation beyond repute
Re: Default code question

Thanks for the explaination, Jake. I probably would of figured it out eventually, and may try again to work it out in my mind.

Quote:
Originally Posted by Jake M
And as for the one reversed motor, we usually just wire it in reverse, rather than make the code more complicated. For one, our main programming mentor would (bleep) about it if the code wasn't exactly perfect, and it makes it that much easier to understand months later.
We did that for several years, just reverse the wires, but like what the hot dog commercial says, we have to answer to a higher standard, that of FIRST safety rules. Or at least that's what our shop says. Even if it isn't in the book, I agree with them. Red to Red, Black to Black. This year I watched the inspectors do their thing and (like inspectors everywhere) you never know what will catch their eye.

Besides, that's what comments are for. Months later? Try years. Or just an hour later.

Code:
   //Put modified joystick numbers into the four motors
   //The (256- ) part reverses one side's motors so no reverse wiring is needed!

   pwm13 = pwm14 = Limit_Mix(2000 +        p1_yNew  +        p1_xNew  - 127);
   pwm15 = pwm16 = Limit_Mix(2000 + (256 - p1_yNew) - (256 - p1_xNew) + 127);
It's unbalanced, but so are the original motor positions. I don't disagree with your programming mentor; robots are perfectionists. But life and robots are full of quirks, and that you gotta live with.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
2007 IFI default code question Japper Programming 4 22-01-2007 23:23
problems using gyro/adc code with camera default code tanstaafl Programming 7 22-01-2006 23:09
Question about Solenoid and default code waialua359 Control System 4 21-01-2006 18:21
navigate and default code newbie question alan koch Programming 2 17-02-2004 22:25
Rookie Programmer has question about the default code DanL Programming 3 26-01-2002 19:59


All times are GMT -5. The time now is 23:50.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi