Delay in controls (HELP!)

Our robot has been fine up until today. Nothing different has happened. When we turned it on today, it seemed like the motors wouldn't run. But then the robot moved. It seems we are experiencing some major delay between our driver station, and our robot. We tried it inside our room, with the robot on blocks right before that, and it worked perfectly. we then took it outside, and....lag! Any answers would be great!

[Chris is me]

Coding in C++? Check how you're allocating memory.

Originally Posted by Chris is me

Coding in C++? Check how you're allocating memory.

We haven't changed our code at all. It's the same code that ran at the competition (We will, however, be adding major changes within the next week). That code worked fine.

[Chris is me]

Originally Posted by SuperNerd256

We haven't changed our code at all. It's the same code that ran at the competition (We will, however, be adding major changes within the next week). That code worked fine.

A very strange bug that I know little about happened to my team once. Apparently, when something specific happened (in our case, unplugging the Axis camera), the code would write to memory in such a way that it would just use up more and more memory to the point of causing lag a few matches later. This would persist when we turned it off and on, but not when we reloaded code. This problem was eventually isolated in code.

Originally Posted by Chris is me

A very strange bug that I know little about happened to my team once. Apparently, when something specific happened (in our case, unplugging the Axis camera), the code would write to memory in such a way that it would just use up more and more memory to the point of causing lag a few matches later. This would persist when we turned it off and on, but not when we reloaded code. This problem was eventually isolated in code.

We'll try that. The only thing that I can see is we unplugged our compressor, since we won't be using pneumatics anymore, and it was taking up too much memory, so as that we couldn't drive. Thanks!

[apalrd]

In LV, I've seen this issue when the WPIlib spits out errors. It seems that, if any individual thread gets a VI or two spitting constant errors, then the processor load of logging and transmitting all of these errors to the DS bogs it down enough for the thread to become unhappy (which usually trips one of the 100ms watchpuppies, which then sends more errors, and then everything dies).


I'd see if there are any errors being spit out.

Originally Posted by apalrd

In LV, I've seen this issue when the WPIlib spits out errors. It seems that, if any individual thread gets a VI or two spitting constant errors, then the processor load of logging and transmitting all of these errors to the DS bogs it down enough for the thread to become unhappy (which usually trips one of the 100ms watchpuppies, which then sends more errors, and then everything dies).


I'd see if there are any errors being spit out.

If it weren't for that last sentence, I'd have almost no idea what you were saying.

[mesamb1]

Originally Posted by Chris is me

code would write to memory in such a way that it would just use up more and more memory to the point of causing lag

Sounds like you forgot to deallocate your memory. I find segfault and memory leak stories break the ice with any CS person.

SuperNerd256, I find it unlikely that your compressor was taking up that much memory. I am rusty on my C++ library, but I could not imagine it is doing massive amount of of operations(perhaps a few function calls that go no where when the compressor is unplugged) or declare so much memory you eventually get a lag(unlike an image which is large).
Some suggested trouble shooting(which you may have tried), is your battery good? Is the Classmate running something else(possibly in the background, an update program or something that has highest network priority then the driver station and is trying to figure out why your robot is not responding to its internet request) using task manager? Is this a recent compile of the code(like Chris is me's story, but insert any variable that has never been deallocated will add up over time)? Is your robot in a Faraday Cage?

[apalrd]

Maybe my understanding of embedded programming is different than everyone else's, but I've always understood embedded systems (such as FIRST robots) which run in real time iteratively have little need for dynamic memory allocation (as they always use the same variables, and pass data in and out of functions and variable storage). For things like the camera image it might be nice to allocate memory dynamically, but still, does a robot really need to create and destroy objects while it is running (post-initialization)?

Although all of the RT embedded programming I've done outside of FRC is for systems which lack dynamic memory allocation (and I'm lucky if it has an RTOS with pre-emptive scheduling). In FRC, I use LabVIEW which does everything for me.

Originally Posted by mesamb1

Sounds like you forgot to deallocate your memory. I find segfault and memory leak stories break the ice with any CS person.

SuperNerd256, I find it unlikely that your compressor was taking up that much memory. I am rusty on my C++ library, but I could not imagine it is doing massive amount of of operations(perhaps a few function calls that go no where when the compressor is unplugged) or declare so much memory you eventually get a lag(unlike an image which is large).
Some suggested trouble shooting(which you may have tried), is your battery good? Is the Classmate running something else(possibly in the background, an update program or something that has highest network priority then the driver station and is trying to figure out why your robot is not responding to its internet request) using task manager? Is this a recent compile of the code(like Chris is me's story, but insert any variable that has never been deallocated will add up over time)? Is your robot in a Faraday Cage?

Battery is at fully charge. I don't think classmate was running anything else, but I'll check. The code hasn't been loaded since last season. It's not in a Faraday Cage, but now I want to build one!

Originally Posted by apalrd

In FRC, I use LabVIEW which does everything for me.

We are using C++ for the first time this year. It worked out pretty well.

[mesamb1]

Originally Posted by SuperNerd256

The code hasn't been loaded since last season

I would try to recompile the code. While I dont know what specifically it would fix with your code, it might be a magic bullet that solves the issue. What is going through my mind, is a delay on the classmate side, a memory issue, an lagging loop, or a bad wireless connection.

I told me lead mentor, and we will be reloading the code at our next meeting. Thanks!

[mesamb1]

Originally Posted by apalrd

I've always understood embedded systems (such as FIRST robots) which run in real time iteratively have little need for dynamic memory allocation (as they always use the same variables, and pass data in and out of functions and variable storage).

Originally Posted by apalrd

In FRC, I use LabVIEW which does everything for me.

The short answer is not quite. You cant ever forget memory. Any time you call a function and it has any variable you have allocated more memory you run the risk of trouble. Even with 8GBs of ram a recursive statement just declaring 1.01 run a billion times will run into issues with memory allocation. That sounds insanely unlucky to happen, but if you dont get rid of variables you are using over time you have a left a lot of variables the processor has not optimized out of existence once used.
Even labview you do this. All those close vi's de-allocate all the cache you initialize.

[linuxboy]

Someone may have mentioned this but If you are in a area with a lot of Wi-Fi Access Points you could be getting interference which would cause dropped packets / lengthy packet delivery times. I suggest using the 5GHz range if you can and wireless N because in my experience using those settings has avoided interference.