View Full Version : Overcomplicated Autonomous Code
EbonySeraphim
18-02-2003, 22:55
Lead Programmer on team 623 here. I haven't been a big part of the threads in this forum, but I have been watching them pretty closely. I'm not trying to sound arrogant or anything...but[there always is one] I am not seeing too many good questions being asked. I'm hearing all of this stuff about timers over and over. I know what they can be used for, but I really don't think they are a good solution to problems.
I would agree that if you get working dead reckoning code, you can get to the top of the ramp the fastest. The biggest problem is the unpredictability of the match KILLS that completely. If your robot gets hit by your alliance partner's robot on the way up, how does your robot know how much its been knocked off track? It doesn't. How does your robot know what angle it is moving at up the incline? How does the robot even know it's on the incline? How does your robot know in the beginning to turn left or right?(actually there is a simple solution to that one) Basically, I think a lot of effort is being wasted going that path, for something that could fail so easily and badly. Also, there is no garuntee that if your robot reads "this" then "that" is the case. There are many "this"s that will lead you to the same "that" case.
In Computer Science, its good to keep your code and algorithm simple. Usually, if it(the algorithm) is very basic, when you develop it, it will take care of problems that you might not even have considered while making it. If you list all of the specific cases for failure before planning what it should do, you might run yourself into a hole thinking of all of the possibilities and needs to fix it.
Also, if you're wondering why I'm even discussing this. Here in the DC Metro, we have a shipping extension because of snow, and other than that, any team can still change our program before the actual competition.
Please, feel free to argue against me on any of those points. I would love to be convinced of why timers are the most efficient way of solving the problem.
Caleb Fulton
18-02-2003, 23:27
Timers can be used as PART of the autonomous run. For example, once the robot senses that it is done tracking the line up to the top of the ramp, it will go forward for X amount of time, turn right, open a lifting mechanism after Y seconds, etc...
I can see why it would be unreliable to have the entire autonomous mode running on a timer, though
Originally posted by EbonySeraphim
How does your robot know in the beginning to turn left or right?(actually there is a simple solution to that one)
and how would you do that? I haven't got into the programming much. I do know though that the main reason that we're using dead reckoning is that we don't have the space and weight to mount the sensors (yeah I know that the sensors don't weigh much, but we're REALLY close)
AntmanIV
18-02-2003, 23:33
Neil, lead programmer of 1089.
I agree whole heartedly and think autonomous will get scrapped. if the robot gets knocked off course and veers into NASA's precious wall it will ABSOLUTELY be disabled. the chance of this happening is quite high and as it is an extremely experimental thing it will fail just as much as it will go perfectly. Just remember, "Murphy was an optimist". have fun.
~Neil
jzampier
18-02-2003, 23:51
I agree that if something goes wrong with dead reckoning code you are totally screwed, however, when it works, it works really well, and FAST, and in this competition, FAST is really important.
Also, after playing around with the optical
sensors in the kit, i decided that they weren't
useful enough to get me where i wanted to go.
I even tried hybrid dead-reckon/line follow code. Its not a code issue, its just that the movement of the robot is too jerky and imprecise to align a sensor. I'd need about 9 sensors to always have at least one on the line, which just isn't worth the 2^9 states worth of programming.
I considered using an ultrasonic range finder, but didn't have time to get one/test. I thought a set of three might be useful for collision detection, etc. Other things were a fifth wheel
rotational counter, which we didn't have weight for and doesn't compute direction.
In order to have really good autonomous behavior you need so many types and quantities of sensors that its not worth the expense or trouble.
I figure to get a good position and heading
plus obstacle avoidance i'd need 3 ultrasonic sensors, fifth wheel, plus maybe an RF triangulation system (which is highly illegal per FIRST) or something like it.
Basically, all things considered, mostly time and weight and cost, dead reckoning is most bang for buck. Certainly not smart at all, but its useful enough. And FIRST is often about good enough. ( as evidenced by the love of hammers )
EbonySeraphim
19-02-2003, 00:02
Caleb Fulton: You just sort of ran over the hardest case to check as if it was nothing. Unless there is some magical hardware tool that gives your program input on wether or not it is going up the ramp, that's very hard to know. I actually posted a relatively simple but very flawed solution in another thread. Also why would you want to go forward X amount of time? Wouldn't you not care how long it takes to get there, but rather, that you DO get there? I'm not saying you're completely wrong. Just throwing big flaws in the approach. I don't think there is a solution to autonomous code. Only a way that has the highest chance of success, one that is the fastest(higher chance of failure), and one that tried to be flawless, and ends up not doing much.
To Solace:
That check would have to be done with sensors. One on the far left and right of the robot. Once one goes off, you know thats the way your robot should be going for the rest of the time. The reason that they should be far apart is in case your robot drifts a bit to the right or left. You dont want your robot to think it should go the wrong direction.
To AntmanIV:
I wouldn't say you should abandon autonomous code completely - but you shouldn't leave anything there that could kill your robot (or people). Just think of the problem on a very simple level, and make the hardware guys do more work to make your job much easier. If my hardware guys could tell me that when the robot is going up the ramp this will give that input value, I would have near flawless line-tracking code.
Edit To jzampier:
About the dead reckon/line follow code. Why does it matter if the robot is too jerky? The/a sensor shouldn't always be on a line. Why not just say, keep the line between two sensors? As long as your robot goes foward and the line is between the sensors, you must be going the right way, right? Once again, I agree that dead reckoning is the fastest, but when it goes wrong...it goes wrong. And if you do a pure dead reckoning robot from the start, don't you only have a 50/50 chance of going the right way in the start? Left or right? I think you should at least know that before doing much else.
Caleb Fulton
19-02-2003, 00:19
What immediately came to my mind as I was suggesting the "when the robot senses when it is on the top of the ramp" idea was that if, assuming that you are trying to keep the tape between the sensors, both sensors are registering for more than 10 or so loops, you are on the ramp.
A gyro could also be used...
EbonySeraphim
19-02-2003, 00:59
(I do argue religiously)
What do you mean by "registering for 10 or more loops?" I assume that you mean both sensors are on for ten loops in a row. The problem is that on the ramp, the sensors will be on and off erratically(or so I think). How will your code distinguish this from actual line tracking data? On a frame by frame input/process loop, you can't look at the big picture. The robot only knows what happening in the current time.
I think I misread your top of the ramp notion though. The top of the ramp that is white I guess could easily be determined by that condition you stated. It's being on the incline that is the problem. The line won't get you all the way to the top, and it's near impossible to be sure that you're on the ramp. So you can't even tell your robot to go straight once you aren't tracking the line.
Brian_Lim
19-02-2003, 01:20
I do not understand why there is a need for sensors.
I do not even know if the Banner Sensors even work on the white refective tape.
If using sensors, there would be a need to accurately space the sensors apart to "see" the white line.
The most basic solution is to have the robot go forward a bit, turn in an arc to a specific counter, and then go forward again.
A simple toggle switch wired into the digital input tells whether the robot turns left or right.
To go forward, make code for the robot to go forward until a counter. To turn, make one wheel spin faster than another. To go forward again, another counter.
Our team was considering mounting some sort of sensor on the wheel to see how far it travelled. Just a touch sensor and studs placed at specific intervals on the wheel.
Why is having an internal counter unreliable?
Autonomous-mode seems one-dimensional to me. This looks like the best solution. Get up the ramp the fastest, knock the boxes down. Trying to find the reflective tape with the sensor spinning around? Good luck.
Dave Flowerday
19-02-2003, 01:43
Originally posted by Brian_Lim
Why is having an internal counter unreliable?
Because various things can affect how far your robot travels in the period of the counter. A fully charged battery will cause a robot to travel significantly faster and thus farther in the same amount of time compared to a somewhat depleted battery. If someone sets bins in front of your robot it will probably slow you down and screw up your timing as well. This is a fundamental problem with dead reckoning. Ask anyone who has participated in FIRST Lego League about these problems and I'm sure they'll have a lot to say about it!
AntmanIV
19-02-2003, 07:15
Originally posted by EbonySeraphim
To AntmanIV:
I wouldn't say you should abandon autonomous code completely - but you shouldn't leave anything there that could kill your robot (or people). Just think of the problem on a very simple level, and make the hardware guys do more work to make your job much easier. If my hardware guys could tell me that when the robot is going up the ramp this will give that input value, I would have near flawless line-tracking code.
well we are not abandoning it but were just thinking that if a robot gets shoved ^.- it might do it's coda at a weird angle and er... break the plastic wall on the ramp and :yikes: oops...
randomperson
19-02-2003, 07:56
Hmm... so much to think about now with only one day to go.. lol.
Break the walls? Dang... they must be really cheap then! Our team made a practice ramp and used 1/4 in. plexiglass or lexion or whatever that cheap plastic stuff they have, and I've run into it many times at full speed when testing our autonomous programs.. hasn't broken yet :D
Because various things can affect how far your robot travels in the period of the counter. A fully charged battery will cause a robot to travel significantly faster and thus farther in the same amount of time compared to a somewhat depleted battery. If someone sets bins in front of your robot it will probably slow you down and screw up your timing as well. This is a fundamental problem with dead reckoning.
Actually there is a way to implement dead reckoning that gets rid of the above problems. Use an encoder disk.:cool: These things are circular disks with stripes of black and white running down them. Mount this disk somewhere onto the drive train. Using this and a sensor (usually infrared or banner sensors would even work) you can now calculate how far your robot has gone by reading the pulses of the sensor. A little gear ratio math and you can now figure out how far the robot is going in each pulse. Although using the timing of the controller is almost the same idea this will not get the robot off track due to differnces in speed from a fresh battery. Of course nothing can really correct a big change in the course of the robot. I am just surprised that far fewer teams went the more complicated way to do it than the simpler way.
Break the walls? Dang... they must be really cheap then! Our team made a practice ramp and used 1/4 in. plexiglass or lexion or whatever that cheap plastic stuff they have, and I've run into it many times at full speed when testing our autonomous programs.. hasn't broken yet
It must be lexan because Plexiglas has been used at hockey games to protect the people but the barriers have been known to shatter. I think? Plus lexan is used in bullet proof windows so that does not shatter easily.
Jeff Waegelin
19-02-2003, 09:22
We had grandiose plans for multiple sensors and all sorts of complex controls, but in the end, our dead reckoning program works better. We may still throw a few impact sensors on just in case, but we found that our basic dead reckoning program works 95% of the time, even when we crash into a faster robot or hit human player stacks.
Dave Flowerday
19-02-2003, 10:23
Originally posted by wysiswyg
Actually there is a way to implement dead reckoning that gets rid of the above problems. Use an encoder disk.
This has been discussed several times and I'm well aware of other solutions. However the original poster was asking about why an internal counter doesn't work so well. When I said "a fundamental problem with dead reckoning" I guess I should have said "a fundamental problem with driving by timing loops".
sevisehda
19-02-2003, 11:28
There are countless ways to do this but I'd go with optical encoders. There proven and very accurate. Sure if your wheels slip then they lose all accuracy but there are ways of telling if your wheels slip. In the past teams have measured the current draw of the motors. If your bot collided with another bot your amps would suddenly increase because the motors are having to output alot of power. Then if you overwhelmed and the wheels slip the crrent will drop because the kinetic COF friction is less that the static so once your wheels start to slip there will less draw on the motor. Also there should be a noticeable change in current when you hit the ramp.
It may take some experimentation to figure out what can be done with current draw but its a possibilty. Saying that though no system will be 100% accurate. If a 300billion dollar defense budget can only get a bomb within 10 feet of a target. I predict even the best guidance system will only get a bot within a foot of its target.
EbonySeraphim
19-02-2003, 17:49
To wysiwyg:
Like what sevisehda said in his post, wheels can and probably will slip. Though he did mention a fix for it, the solution is way to complicated and still has a good chance of failure. What if something else makes the current reading shoot up? Your robot will try to correct something that didn't even happen! Also your robot could be slipping while its in place(it hit a wall), or it could just be slipping a little(hits a box), or maybe its just hit something so hard to push, its moving very slowly(and still drawing a lot of current). Those are all cases that a robot has to respond differently too.
The problem with dead reckoning is that is invokes most people to think in terms of a procedure. If any of you have taken a Computer Science 1 course, your programs could be moved in functions, and the main() function would look like a procedure.
int main()
{
//Do this until that
//Start doing this...
//Last stage now do that
return 0; //End of program
}
To compare what that is in a looping program:
while( auton_mode == 1)
int stage;
if(stage == 1)
{
//Do what it should do
//If "this" happened" set stage to 3 to fix it.
}
else if(stage == 2)
{
//Do whatever
//If "that" happened" set stage to 1
}
else if(stage == 3)
{
//Do whatever
//If this happens go to someother stage
}
} //while loop
Of course the code was oversimplified, but the point is that the robot shouldn't do "this" until "that" is done correctly.And doing "that" correctly is harder than most think. Not only that, but supposing you have a flawless procedural algorithm. The robot runs like games today - it's looping extremely fast and doesn't really do much code different from the previous frame. Converting that procedure into looping code takes a lot of memory because most conditions can only be assured to be true over a large number of loops(iterations) soyou have to remember what happened 20 or 30 loops ago (assuming you need to remember the condition of the robot about a second ago). Thats a big strain on memory, and processing such data to find out a certain condition would be too slow, resulting in big packet losses.
To Brian_Lim :
I have no clue how a robot will work without a single sensor in autonomous mode. It should know if its going left or right unless you wanna reduce your chance of having it work by 50 percent off the bat.
Jeff_Rice
19-02-2003, 18:38
I like sensors. I could care less whether dead reckoning makes your bot really fast. I want to learn elegant solutions that work well and are more fail-safe than your solutions.
:D
I like dead reckoning. We have at least one dead reckoning program on our robot. Dead reckoning is great when you only need it for a short time. We should all try our best and do what we can to do what we want.
Everything has its faults. There is no end-all, beat-all, solution. But what we must do is try and limit the faults, and learn how to make it work. That is what FIRST is about.
Lead programmer of 783 here.
We were poking around with the optical sensors from last year, and discovered a rather large problem. They trigger on anything reflective.
We pointed it in the general direction of the reflective tape. It detected that, and that was all fine and dandy. We then pointed them at the diamond plating used for alliance stations, it detected it. Not such a big problem, the wall would probably be out of their range anyways. We pointed it at last years bot, and it detected. This was a large problem. There was no way to tell our alliance robot from our targets on the bottom of the boxes.
So, we decided to switch to a dead reckoning program, and that hasnt given us too much of a problem, except for a slight miscalculation on my part that left a rather large hole in our drywall wall. Oops. The price of knowledge I guess.
Azash
No, these tag lines are never the same from me.
I have no clue how a robot will work without a single sensor in autonomous mode. It should know if its going left or right unless you wanna reduce your chance of having it work by 50 percent off the bat.
I wouldn't really consider it a sensor, but we have a dial on the robot that selects the program to run. There are 16 positions on the dial, so we can have up to 16 different programs. Some of those positions will be used for duplicate runs on different sides of the field. It really isn't that difficult.
I don't know what kind of experience you have programming, but you seem to be way off base in some of your statements. A "looping" program can pretty simply be implemented with a state-machine. If you remember that you have scratch RAM to play with or even the EEPROM, you can do some really creative stuff.
Just because you can't imagine it, doesn't mean it can't be done.
Ryan
Like what sevisehda said in his post, wheels can and probably will slip. Though he did mention a fix for it, the solution is way to complicated and still has a good chance of failure. What if something else makes the current reading shoot up? Your robot will try to correct something that didn't even happen! Also your robot could be slipping while its in place(it hit a wall), or it could just be slipping a little(hits a box), or maybe its just hit something so hard to push, its moving very slowly(and still drawing a lot of current). Those are all cases that a robot has to respond differently too.
Actually I have a solution. Mount the encoder disk onto a free wheel that is not connected to a motor. Now the disk only registers pings when the robot moves(hopefully). Of course this is probably the best way to place an encoder disk but unfournatly it is still not perfect. Of course nothing is perfect.
sevisehda
19-02-2003, 19:52
I dislike useing an idler, plus you'd have to use 1 on each side so you could calculate the turn as well. I threw out the idea of current monitoring because it has other uses. For example the amps increase when there is a heavy load on the motor, so if your bot had a CVT. The bot would be able to read this heavy load and drop to a lower ratio in order to start shoving. Also if it read slipage you could pulse the motors in order to reestablish traction. Some cars use similar principles to drive in snow::cough cough::. Either way you would have to experiment with this and see what really happens to the current and then have the code recognize each scenario.
For example the amps increase when there is a heavy load on the motor, so if your bot had a CVT.
I am getting a whee bit confused. How this relates to dead reckoning?
sevisehda
19-02-2003, 20:19
I thought we were disscussing ways to makes bots ridiculously complex in order to make the bot be slightly more accurate in getting to were we want it to go. Personnally dead-reckoning is good enough for me. I was trying to making the point that if one didn't feel comfortable with deadreckoning he could place optical encoders on the wheels to track distance. Then if you were afraid of slipping throwing off those numbers then you could check the current draw from the motors to identify slipping.
redbeard0531
19-02-2003, 20:46
I find it highly unlikely that robots will slip. If a 5lbs container causes you to loose traction, think of what a 130lbs powered robot will do. If your robot slips, you have 20 hours to redesign it, or prepared to get pummeled;)
EbonySeraphim
19-02-2003, 21:32
Jeff_Rice: I agree. I'm just more towards using the sensors.
Azash: Last year's sensors could be quite different. They do seem to be the same, I haven't actually looked at the part number though. I also realized that the sensors trigger anything reflective, but unless you are going to have them point anywhere else but the floor, it will only trigger on two things, the white tape, and myabe the wire mesh. They work if you put them on the bottom of your robot looking down. Hence, when then sensor goes off, you know where the tape is relative to your robot to a pretty high degree.
RyanKM: I know what you mean about the different programs running. But that dial, I assume, is something you have to set before the autonomous code. Will we know wether or not we are going left or right before the match start and be allowed to change something on the robot? If the answer is yes, then good for you. Select the dead reckoning program before the match.
All you need to know is that I have enough experience. I don't want to get into how many years. And if you looked at my psuedo code, that is a basic state machine. Maybe you just overlooked that I posted a solution. In case you care about my background, I have been an aspiring game programmer so I know plenty about looping code, and running differently on a frame by frame basis to achieve a psuedo procedural algorithm. Also, I can imagine it - heck, I can see it put to code, just bug ridden and very flawed. Please try to sound less insultive next reply.
wysiwyg: Excellent solution. And that one I can't see failing unless that wheel is lifted off of the ground, which I'm almost sure won't happen in autonomous mode. I know our team has a caster wheel that wouldn't be slipping, but since that could be in any orientation, I wouldn't know what direction it move over that distance unless I had some other form of input about the orientation of the wheel.
sevisehda: I don't know if i was clear in the original post. I think most teams have overcomplicated autonomous code. Not that I have seen, but based on the questions I see on these forums, people seem to be attempting pretty complicated things that have a high chance of failure.
Originally posted by EbonySeraphim
RyanKM: I know what you mean about the different programs running. But that dial, I assume, is something you have to set before the autonomous code. Will we know wether or not we are going left or right before the match start and be allowed to change something on the robot? If the answer is yes, then good for you. Select the dead reckoning program before the match.
No. The people who put the robot on the field will be blindfolded and given small shock collars. As they move randomly around the field, the judges will stop shocking them when they reach the proper position.
All you need to know is that I have enough experience. I don't want to get into how many years. And if you looked at my psuedo code, that is a basic state machine. Maybe you just overlooked that I posted a solution. In case you care about my background, I have been an aspiring game programmer so I know plenty about looping code, and running differently on a frame by frame basis to achieve a psuedo procedural algorithm. Also, I can imagine it - heck, I can see it put to code, just bug ridden and very flawed. Please try to sound less insultive next reply.
Are you saying my code is "bug ridden and very flawed"?
I don't believe he was trying to insult you as very few people ever do that on these boards; he was just pointing out that looping is very easy and doesn't require huge amounts of memory or a lot of resources. I agree with him whole-heartedly. Our autonomous code takes up 2 bytes, both of which are used for other things during regular operation.
Last year's sensors could be quite different.
They are the same.
I think most teams have overcomplicated autonomous code.
And many (including myself) would argue that line-following is overly complicated.
Please, take a deep breath and relax for a few minutes. You don't need to argue with everyone. What you may consider "overcomplicated" may be the easiest solution for some and may be a better solution for some types of robots. For example, read back to the first page and notice that Jeff Waegelin said dead-reckoning "works better" for his team. Are you saying that you are more qualified to assess what solution is best for every robot? As far as I know, such a uber-leet programming god doesn't exist. Especially not when it comes to FIRST.
I believe there may be a way to get foward information and how far the turning information is by only using one idler. Hmmmmm.... I came up with the idea yesterday. Of course this is something to fool around with during the summer when I have the time.
redbeard0531
20-02-2003, 08:46
If your gonna get this complicated, why not just get a spring loaded mouse. It will be lighter and easier than an idler and optical sensors.
Heheh thank you. A mouse is nothing more than two optical encoders in one castor. I knew something like that would have been built but I could not figure out what.
EbonySeraphim
20-02-2003, 11:12
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.
EbonySeraphim
20-02-2003, 11:19
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.
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
EbonySeraphim
20-02-2003, 21:53
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++.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.