Hello there! I am working on our drive base and trying to get basic autonomous code to work. However, I have run into a small problem. When I enable auto mode, the robot moves to the side (which it should, but out of order). Then just stops. It doesn’t move forward or backwards like it should before that. The order of events should be drive forward->drive backwards->drive to the side.
I have been trying to add different commands to the scheduler and making a sequential command group. I have also added printf statements everywhere in the code to try and debug it. I also have had a mentor from the team to look it over and he could not figure it out either.
So I’ll link code here to see if the any one here can help me out! There should be a NetConsole.txt file on there which is a log of auto mode running.
Thank you so much,
Drew
Team 2053 Programmer
P.S. Thanks for the last responses I got from this thread! I have it all sorted out. I basically integrated the rotate to angle command as a separate function, but still in the same command. You can see it in the code if you would like.
Adding a bit of info to to the above post (I’m one of the mentors on the team)…
It seems to be some sort of scheduling issue. I would have expected the function call order after enabling autonomous from a power turn on to be (roughly):
And each call to DriveAuto (a drive forward, left, or right step for some amount of time) to finish execution before going on to the next step. But, it calls the constructors of all the steps of the command group and then seems to jump to executing the last step in the sequence.
Additionally, it seems run the default DriveBase Susbsystem command (which is our main teleop drive function - reading joysticks and moving the robot). So the real autonomous step is being called periodically back and forth with the default command which are most likely in conflict with what they are command the mech_drive function to do in ping-pong fashion.
I did not expect the default command to get called at all during autonomous.
Those assumptions are based on how we had last year’s code - which may or may not be valid. We have also looked at some other team’s command based C code and not found any differences in their structure of autonomous calls.
This part is easy. There is no “requires” statement in your DriveAuto command which means there is nothing to tell the Scheduler that DriveAuto and your default command for the DriveBase should not run concurrently.
The other issue didn’t jump out at me right away and I don’t have time at the moment to dig deeper. I’ll see if I can get some time later to circle back.
It looks like you’re using the WPILib Timer to control the elapsed running time of your DriveAuto commands. Looking at the documentation for Timer, the resolution is in milliseconds (1000 in a second). In AutoCommandGroup.cpp, you’re passing in values of 0.3. If this is supposed to be 1/3 of a second, try changing these values to 333.
For safety’s sake, always be ready to quickly disable your robot when testing this kind of code in case it actually tries driving for 333 seconds in one direction or another.
That was correct - adding requires prevented the teleop portion from running.
Still debugging why it jumps right to the last command in the sequence:
What documentation are you seeing that in, please? Finding good WPILIb documentation is difficult. Looking at WPILib Timer C Code, it specifically mentions seconds. In the code we have it print the timer value each iteration through the DriveAuto call, and it increases between .1 and .2 (seconds) each time. The robot stops after .3. In actuality, I would say it moves for about 1 second.
What I’m thinking is that the separate calls to DriveAuto aren’t being treated as “new”, and unique, and each constructor is overwriting the previous calls and it effectively only acts on the last.
The prints seem to corroborate that, I’m just not sure why that would be now…
The best place I’ve found (sortof) documentation is inside WindRiver itself. Hold down Ctrl while clicking on a class name and it will take you to the header file. It does, indeed, look like it’s in seconds.
When we call the autonomous group it seems to not make separate instances fo each command issued within the command group. We are using “AddSequential”, and 3 commands that make our robot go forward, backward and then sideways (just for test purposes).
In our code we have a “DriveAuto” command that is parameterized and we pass in direction and time to drive for. It seemingly only runs the last command in the series. It had 3 calls to the DriveAuto, but each has the parameters of the last command in the command group.
It would appear as though the code is only creating one command in memory and the two subsequent calls (to the same function) are over-writing the first in memory.
In the code, we have a bunch of printf’s and oddly, it never prints out anything from any of the calls to the constructors for the DriveAuto, which I expect shortly after it get’s into autonomous.
Is it possible the code isnt inheriting write and over-riding the constructors - or we aren’t instantiating the command group right?
The constructors for DriveAuto are called while the robot code is initializing, which happens while the cRIO is booting up. It’s possible your console isn’t connected at the time this happens. It’s tricky to get the console connected at just the right time while it’s booting up.
Do you see the printfs that happen in DriveAuto::Initialize()?
If you suspect that somehow the compiler is generating only one object with the same values would be to add the DriveAuto instance to your printfs - like this:
printf(“me=%p”, this);
This will print out the member address of the current DriveAuto instance. You can also do this for the member variables, i.e.
printf(“my X=%p”, &speed_side);
This would tell you if there’s a possibility that you have different DriveAuto command instances that are somehow sharing a common set of member variables. I don’t see anything in the code that could accidentally allow this.
Just to close this one out in case anyone has a similar issue down the road- the problem we had was that the variables “in the class”, were not actually in the class at all. They were in the file, but made global in scope because they were outside the class structure. When we called the same drive function multiple times in the same command group, it did construct them all, but each subsequent call overwrote the global variables with that set of parameters.
So, we wound up with 3 back to back commands doing the same thing, whatever the very last command issued was.