Vex IQ has a lot of options for programming and I plan on evaluating all of them this summer. Right now I’m trying out Modkit for autonomous programming. Modkit is trying to make me think different, but my brain is being stubborn. I’d like to be able to create a subroutine and pass it a list of parameters, but I don’t see a way of doing that. It looks like all variables are global and there are broadcasts instead of subs.
To simulate a function call should I first set a bunch of global variables and then broadcast a command? Instead of writing a sub in a single location I would write a block of code for each motor or sensor that catches the broadcast and then does something? Is that how you do it in Modkit, or am I missing something obvious?
Also, is there a way of renaming a variable once it’s created?
I don’t think you can have a function, located within a motor tab, that controls a different motor. (from what I’ve seen) That means you have to have that same broadcast-receiver and code for each motor.
Our general strategy when creating an autonomous program in Modkit: Put all the control code in a single area. Generally, under the “drivetrain” tab. It would broadcast commands to other motors.
I wanted to have the other motors broadcast back when complete, however it seems like the PID in the motors often causes them to never reach their intended position, meaning they must wait to timeout (sometimes 2 seconds or more), which is a problem when you have 10 commands, and 60 seconds.
So the two solutions were (1) Broadcast command; wait xx seconds and hope it arrives, which it generally does, or (2) Broadcast command; wait for motor x rotation > yy
Regarding the motor stall, I wonder if Modkit has any plans for creating some type of test condition, or some better way of handling for it. Python/Blockly had the same challenge, but the workaround was to create a loop that compares the current motor position to the previous position at some timed interval (like 0.1 sec); if equal then motor is assumed to be stalled. It might be possible to do the same thing in Modkit (I will try it). However, in my opinion this is overly complicated for Vex IQ and the language should handle it.
Do you know if Modkit has their own forum/support website, or to they just follow this one?
In general, my impression of Modkit so far is that it is very easy and intuitive for simple teleop programming, but a bit cumbersome for auton.
You can set the “stall timeout”, which our teams usually adjust to about .5, however that still assumes the motor is actually stalled for that length of time, and not moving one or two degrees.
In my opinion, the kids can generally figure out how long the move will take, and allow that much time in the code.
If you’re doing more than 60 seconds worth of Auto, it can quickly get crazy. But, for the IQ challenge, it seems pretty good for kids.
So the existing motor ‘set timeout’ command must take care of that… Thank you.
Some of our teams have been using Robot C and relied on the “waitUntilMotorStop()” command a lot. To evaluate Modkit I’m trying to redo their autonomous routines, but I’m finding that is not a line by line replacement.
In testing the “set timeout” setting, I noticed that it does not reset itself, and I do not see a way of doing it in the program. The workaround is to set it to a high value that will never be reached. This is very important in certain situations.
For instance, last year’s robot had a claw designed to pick up three blocks. Our teams used the motors in servo mode and had predefined positions for ClawOpen and ClawClosed. When closing the claw it may appear to be gripping the blocks at around position 100, but at that setting the blocks will slip. So we tell the motor to go farther, say position 50, even though the motor may only get to 70 or 80 before it stalls. The exact position it stalls depends on the power left in the battery, if the motor is overheating, etc. It’s hard to know exactly where it will stop; better to keep going as far as you can.
When you do this in Modkit with the claw motor timeout set to .5 seconds the robot will behave as follows: Start auton program, open claw (works fine), drive over blocks to end of row, close claw and hold blocks (works fine), more driving and turning, set stack on base block, open claw (IT DOES NOT OPEN!). I believe that the claw motor timed out while holding the blocks as the robot was driving around. Try the same test again with the claw motor timeout set to 25 seconds and everything works fine, the claw opens as expected at the end. This leads me to believe that the motor timeout is not being reset between commands.
All of our teams had similar issues when using Flowol, but they never figured out the cause and I couldn’t help them. This was maddening. The teams had built their auton routines in sections (green row, blue row, red row) and then connected them all together once they worked separately. So the green row would be working fine by itself, but if you ran it after doing the blue row the claw wouldn’t work, or the lift wouldn’t move, or it would start driving in circles. They spent days on those programs, but could never get past one working row of blocks. The teams that made it to Worlds had to switch to Robot C, but some didn’t get finished, and their confidence was already shaken. That’s why I’m spending the time to evaluate all the programing options now before the season starts. Modkit still looks like a good choice for younger teams, if you know about this problem and the workaround.
I don’t think you’re seeing a software issue (claw DOES NOT OPEN). I think that’s an issue where the motors have overheated.
I’m not sure, but I suspect what happens (our teams saw this last year) is that when the timeout occurs, the software on the brain moves on to the next command, while the software/firmware on the motor continues to tell the motor to move, causing the motor to overheat.
Our solution was for the next block in the program to tell the motor to open 5 or 10 degrees (depending on gearing)
Thanks for the input Steve. I had been working with Modkit on this issue and their suggestion was to tell the motor to Rotate in a specific direction (forward) to the ClawOpen position, rather than just Rotate to that position. Their explanation was that when the motor stalls it get’s confused about where it’s at and may be tightening when it should be opening. Their suggestion worked.
You also made a good point about the motor overheating. So I tried that, but it wouldn’t overheat, even after running it hard, going through a few batteries, and leaving the claw gripping the blocks for 10 minutes straight. They did have problems with that motor overheating earlier in the season, but then switched to a 1 to 5 gear reduction.
Anyway, problem solved. The lesson learned is to try and avoid situations that will cause the motor to stall.