|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||
|
|||
|
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. |
|
#2
|
|||
|
|||
|
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. |
|
#3
|
||||||
|
||||||
|
Quote:
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 |
|
#4
|
|||
|
|||
|
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++. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
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 |