Go to Post Like fishing, some may get away as you are reeling them in, but never letting out enough line to get the big ones at the bottom is just disappointing. - Eric O [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
  #31   Spotlight this post!  
Unread 20-02-2003, 11:12
EbonySeraphim EbonySeraphim is offline
Registered User
#0623
 
Join Date: Jan 2003
Location: Vienna, Virginia
Posts: 37
EbonySeraphim is an unknown quantity at this point
Send a message via AIM to EbonySeraphim
rbayer: I have a feeling I'm getting on your bad side because I seem arrogant. I am trying to create a stir and want to find out why some teams are doing the things they are doing. From this discussion, I have gained some valuable information, and am thinking a little harder about our team's autonomous code.

I know it isn't the loop that takes the resources, its remembering what happend over the last X amount of seconds that would take a bit of memory. For that matter, our autonomous code uses 2 bytes right now too.

As for the line tracking code. Is it really that complicated to have two sensors looking down on the carpet, one on the left and right, when one goes off - say the right, that means your robot needs to turn to the right(right motor speed slower or left faster)? Of course it needs to go fowards otherwise(no sensors triggered) I know that would have a serious flaw if the wire mesh causes the sensors to go off, but I haven't been able to test on a working drive train.

About what Jeff W said - if you notice I didn't reply to him. If his robot is heavy enough to not really slip when it hits another robot, then most likely his dead reckoning code will be reliable. And I don't know whats best for every team. I just want to know why teams are doing this and that. I felt the best way to get that out was by pointing out what might be wrong with it and have them tell me why it wouldn't be an issue, or maybe they did overlook what I brought up. I know you must be an accomplished programmer based on the RoboEmu that you wrote.(i think you wrote) If I were to parallel what I mean to application programming. What I meant is that, in program, you don't always want to have to test for every condition. Its better to think through the problem in a way that will solve itself while processing the data. If you check this and that condition, things just get too complicated, and usually certain stimuli fall into the same condition as something else not intended. Don't get me wrong, there are some clear cases that many if's are needed.
__________________
Ogun's Laughter is No Joke!!!
  #32   Spotlight this post!  
Unread 20-02-2003, 11:19
EbonySeraphim EbonySeraphim is offline
Registered User
#0623
 
Join Date: Jan 2003
Location: Vienna, Virginia
Posts: 37
EbonySeraphim is an unknown quantity at this point
Send a message via AIM to EbonySeraphim
Maybe I'm crossing some line by doing this. But I have an honest suggestion to a line of code I saw in another thread:

*(unsigned int *)((int)out+i*sizeof(unsigned int))=result; //have fun figuring out this one

Why dont you just overload the [] operator? In fact, if my assumption that, 'out' is of type (unsigned int *) you can just go head and use the [] operator with the variable 'i' in it.

This post is directed towards rbayer in case no one could tell.
__________________
Ogun's Laughter is No Joke!!!
  #33   Spotlight this post!  
Unread 20-02-2003, 16:38
rbayer's Avatar Unsung FIRST Hero
rbayer rbayer is offline
Blood, Sweat, and Code
no team (Teamless Orphan)
 
Join Date: Mar 2002
Rookie Year: 2001
Location: Minnetonka, MN
Posts: 1,087
rbayer is a glorious beacon of lightrbayer is a glorious beacon of lightrbayer is a glorious beacon of lightrbayer is a glorious beacon of lightrbayer is a glorious beacon of light
Send a message via AIM to rbayer
Quote:
Originally posted by EbonySeraphim
What I meant is that, in program, you don't always want to have to test for every condition. Its better to think through the problem in a way that will solve itself while processing the data. If you check this and that condition, things just get too complicated, and usually certain stimuli fall into the same condition as something else not intended. Don't get me wrong, there are some clear cases that many if's are needed.
The same thing is true of your line following code, I would assume. Something like the following is the way I would do it, but I'm sure other people are doing it other ways:

if rc_sw1=rc_sw2 then PWM1=254 : PWM2=254 : goto endTracking
if rc_sw1=1 then PWM1=0 : PWM2=254 : goto endTracking
PWM1=254
PWM2=0
endTracking:

Here's the guts of my dead-reckoning (I don't remember the actual numbers):

counter=counter+1+delta_t
SELECT counter
CASE 0 to 100
'do something
CASE 101 to 200
'do something else
CASE ELSE
'do yet another thing
ENDSELECT

Could you please explain what you mean by "its remembering what happend over the last X amount of seconds that would take a bit of memory" as I'm not quite sure why you need to "remember" anything if you are just using a normal counter.

Anyways, I sent you a PM about that line of code and my (late-night)reasoning behind it.

--Rob
__________________
New C-based RoboEmu2 (code simulator) available at: http://www.robbayer.com/software.php
  #34   Spotlight this post!  
Unread 20-02-2003, 21:53
EbonySeraphim EbonySeraphim is offline
Registered User
#0623
 
Join Date: Jan 2003
Location: Vienna, Virginia
Posts: 37
EbonySeraphim is an unknown quantity at this point
Send a message via AIM to EbonySeraphim
With a few more conditions, yeah, that is how my autonomous code looks like. Of course we haven't considered what the wire mesh ramp will do.

As for that autonomous code. What you have seems to be the simple answer. Why say "do this for 2 seconds." Why not have it do something for X amount of ticks which through, testing, we know is about 2 seconds. I was worried about what other teams were doing with timers. I really don't think its neccessary to have your robot do something for exactly X seconds.

About the memory. Knowing what happened in the past few seconds would be neccessary if you wanted to try to fix an problem like being up the wire mesh ramp with sensors going haywire. The program needs to have significant "messed up" data before deciding its on the ramp and ignoring the sensors. Or it would be neccessary for those who want to examine the amount of current drawn for the motors. One input value wouldn't be representative of the bigger condition.

About the line of code:
I would private message you the response back, but I don't know how to use it. For any pointer data types(except void), the [] operator is always available to you. You don't even have to overload it. I'm sure thats true of both C and C++.
__________________
Ogun's Laughter is No Joke!!!
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
autonomous mode problem on field Chris_C Programming 17 26-03-2003 19:11
Autonomous Code From Experience EbonySeraphim Programming 7 14-03-2003 21:56
Autonomous code tutorial miketwalker Programming 2 23-02-2003 12:28
Autonomous code PBoss Programming 7 14-01-2003 15:29
Autonomous Code Adrian Wong Robotics Education and Curriculum 1 18-11-2002 22:34


All times are GMT -5. The time now is 16:53.

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