Problems with the Simulator

Since Harrison Cassar is not answering, I'll answer(sorry, Harrison). Harrison found out that only the motor commands actually drive the robot. The simulators do not respond to create commands. Hope this helps. I am really sorry I didn't actually look at your code, once I get in my spare computer, I'll look at it. Have a great year.

Thank you for your response.

Motor commands are precisely what I used. Below is my code:

int main()
{
printf("Hello world\n");
mrp(0,200,1000);
mrp(2,200,1000);
return 0;

}

This causes the simulated robot to briefly fidget, then stop. Shouldn't it make it go 1000 ticks forward at a rate of 200?

Basically, whenever I write multiple mrp()'s in my code, the simulator only executes the first one (haphazardly) and skips the rest. Except sometimes it decides to do part of the later commands, and sometimes none at all... very strange.

Again, any tips would be very appreciated and I would be happy to provide any necessary information.

For the skipping motor commands, I personally put a freeze function after the motor command just as I put a create_stop after all create movement. This ensures that no more voltages are sent to the motors. It is a programming thing that I highly recommend because I have ran into problems when I don't use it.
For the fidgeting motor problem, more information would be great. To get more info, tell the link to track how many ticks the motor has turned by printing it onto the screen. If the screen says that it has actually traveled 1000 ticks or anything close by, then further diagnosis is required and please ask if you need help,with the diagnosis. Also, keep in mind that 1000 ticks is nothing for a robot to move. A motor has approximately 1100 ticks for one revolution so 1000 may not cause it to do anything if you want it to drive. Also, a speed of 200 is pathetic. Maximum speed is 1500 as specified in the screen on the link.

Thank you for still posting my original response YuSheng, I appreciate it (and I mean that seriously, not in a sarcastic tone).

Anyways, uqarni, if you need some extra help on the simulator and connecting to it properly, go onto my thread on the Botball discussion forum page and go to the one name "Botball Presentation". Read the post and reply, it will explain what you need to do to get the information in a few days.

Thanks!

Adding on to YuSheng's post, instead of freeze, you should put " bmd(port#); " after the mrp's because what is does is it keeps the program from moving on until the motors are done (bmd stands for block_motor_done). Therefore, it will tell your robot to before it finishes the program to wait for the motors to finish.

Hope this helps!

I do not use the bmd because I do want my motors to go on. And, personally, I use another variant of the block_motor_done command. I like to use my own function and give the motor specifications individual variables that iterate and will continue on with the program if the iteration variable is equal to the statement variable. The reason why I don't like the block_motor_done is because it tries to sense for the voltages sent to the motor and for some reason, voltages sent by other motors according to my tests have interfered with block_motor_done so that is why I use integer values instead of voltages.

The simulator is being revamped for Botball 2014. Hopefully this issue will be addressed. If you would like to submit a formal bug report, please visit the KIPR Bug Tracker.

Thanks.