It is the NXT version yes. And I have done it from two different computers and the frames per second of the first computer is always changing between 9.5 and 12.5 approx., and on the second computer it is changing from 28 to 38 approx. The frame rate is above and the exact code I used is attached.

@ Crazed_Persona: This might be a designed feature, because real robots actually do behave like that. After being the programmer for both a Vex Robotics Competition team and a FIRST Tech Challenge team, as well as programming my own Lego robots, I can say that I have yet to find a robot that moves consistently through timing alone. To get a robot to move accurately, you'll have to use self-correction programs to keep it going straight and measure distance instead of time using encoders. Even if H99 stops behaving that way, you'll still have to deal with inaccuracy in real robots. Factors such as battery power levels, worn out motors and in some cases external forces cause robots to go off course.

This is an example of a move subroutine I wrote for our FTC teams TETRIX robot. It has 2 different motor ports on each side: lft1 and lft2 on the left side, rt1 and rt2 on the right side. This move subroutine can keep the robot going straight even if one of the 6 motors on the drivetrain is unplugged.



You probably can convert it into a program for H99 if you have the time, but right now I need to work more on the FTC robot (we're rebuilding everything but the drivetrain for our next competition).

@ droidfreak36 thanks for the help. I will take the code and convert it if I can. H99 is just like RobotC for ftc. For now.

@ Crazed_Persona: Not just like RobotC for FTC, because the encoders in H99 are configured as sensors (not as part of the motor). It's a slight change (and I think the makers of the H99 software should change it back), but you'll need to make it to the parts of my code that use encoders.

In ROBOTC for IFI VEX, encoders are treated as sensors. I think that is why they are treated separately in H99.

Ok, on the first computer, the low frame rate is causing the issue. On the second computer, your frame rate is marginal. I suspect that is what's causing the problem. We've seen something like this before in testing, so thanks for confirming it "in the wild".

The reaction of a few middle school students I tried this out on was:-
1) WOW! Cooooollllll!
2) An immediate desire to try out the code.
3) They made small changes to their code, & tried the changes out immediately – which is exactly the way I like them to program their NXTs. Excellent! In my experience, with the “real” NXTs, many of my kids want to program a whole project in one go, & then try the whole code in a “real” NXT – with the inevitable debugging problems. I have to teach them the incremental “code only one action”/”try that code”/”debug that code” approach – the H99 environment seems to make this approach natural. If it works this way with all my students, I’ll be really really pleased.
4) I noted one comment about the need for a “safe” environment where the robots did not have to crash. My students haven’t yet developed the adult fear of failure – they just charge in there and LOVE the ability to crash their robots, hear the noise when they hit something, and burst into delighted giggles when their robot climbs a steep slope, bucks & nearly overturns. If you put in the ability to explode robots in masses of fire & flames I’m sure they would love that too. Hope I’m not around these students when they learn to drive…
5) In “real” NXT robots, we usually rename motors left/right – it would be useful to be able to do that in simulation too.
6) They also wanted to be able to increase the simulation to full screen and flip back and forwards between the scenario and the code. I have since seen the Alt+Enter hint, and haven’t tried it on them yet. On my home two-screen computer (the second screen being a continuation of the first one), Alt+Enter takes over both screens, and I can’t have the full scenario in one screen, and the code in the second screen.
7) In my teaching, it would be really useful to be able to more closely simulate real NXT robots. As a minimum, being able to specify the placement of sensors on your simulation robots would be a help.
So far I’m really impressed with your approach – and the few kids I’ve tried it out love it. Keep up this excellent work!

So far, I am loving this program. I was completely new to RobotC when I got it, so having this program without a real robot was a helpful learning tool as I will be using RobotC in FTC next year.

There are a few things I would like to see added.
1. More sensor variety such as the light and gyro sensors.
2. Some type of gripper or attachment arm on both the NXT and H99 vehicles.
3. Ability to program a TETRIX Robot.
4. Ability to import designs from LDD or Inventor
5. Custom stages and maybe a yearly update with the FTC Field (that would be helpful to simulate before actually wasting battery power).

Things I would like to see fixed
1. Sometimes simulation window closes when debugger is started.
2. Sonar is a bit unrealistic on NXT. It's seeing things at an angle it shouldn't.
3. In simulation window, add a reset stage button and change restart to menu, or something along that line.
4. Also, as the robot runs, it seems to get slower, and the motor sound gets deeper. Is this supposed to simulate battery power? I was previously on an FLL and I have yet to see a robot that drains a battery that quickly (although they do go very fast).

So far for Beta, this is an awesome program!!

Oh, yes, that would be very nice, jedi_dude I am also a bit new in FTC(rookie year) and have been programming in RobotC since last summer, its a great program.

Some cool things to add:

1)Joystick control would be awesome so that you could explore the map(as well as test your robot out)

2) Being able to import your own robot(to help out with testing tele-op and Autonomous for FTC, and even FLL & FRC)

3) Everything from the post above me

Some things to fix:

1) I have seen some posts where the camera can get a bit confusing, so a mouse move-able camera would be nice

2) Not a very big problem, but when you put in a speed of, lets say, 10000000000000000000000000( I know, crazy, but the H99 robot is sooooooo slow), It goes somewhat backwards....

Anywho, this is a great start in virtual testing in programming, great job!!!

Most awaited and welcomed package! Thank you!
Would like to add a vote for importing own models. MS Robotics Studio allows importing from Solidworks. Since solidworks has good offers for education + a good Mindstorms NXT parts base to start with + a good learning curve – would be great to see that integrated. If not – Sketchup. If not – LDD. Or something else then.

And please, if you add a possibility to control the robot with a keyboard, allow an option to lock that under a password Would be like a cheatcode for them students

I got to try the beta version of the RobotC virtual world, it does nice, though I do have some suggestions on improvements:

1: The Virtual world takes A LOT of processing power, and the virtual program doesn't run smoothly with the extra power, this would be the one to fix for sure.

2: Have the ability to add different sensor, I mean, it would be nice to use different sensors than the ones that are stuck to the robot.

3: the ability to make a virtual world robot with some 3D/CAD software.

Well, those are some wierd improvements, but other than these, the RobotC is wonderful, its nice that I get a chance to see how my code works before I actually throw it into my real robot. Thought I give you my thoughts and what can be improved with the virtual world. thanks for reading.

As has been commented before, it would be great to make it an option to launch the last selected world when hitting F5 to compile and download and to save the position of the world window so it doesn't sit on top of the debugger window. This has been a fairly consistent complaint from my students. One click instead of three would be good.

The other thing is that, when starting two motors, one motor often seems often to start fractionally before the other, giving the robot an initial "jerk" that can throw it off course by a degree or so. I guess this may be programmed in to the robot behaviour, but I don't think I've observed it in my real NXT robots. Is this deliberate?

Not really deliberate, just the nature of the beast. Your real NXT robots do it too, you just don't see it. If I had to make a wild guess, your computer isn't fast enough to update the physics engine and/or the graphics rendering. This would exaggerate the result.

That makes sense. Under normal circumstances, I would not be able to duplicate the starting position of a real robot to within one degree of the previous start, and detritus on a polished floor or changes in the pile of a carpet between runs would not allow subsequent runs to exactly duplicate previous runs – whereas the “perfect” surface in your virtual environment allows that.
I’ve found this “perfect” surface a real benefit when teaching a student that procedures/functions really do duplicate the effect of the code they replace in a program. While I like NXT-G, and delight in the classroom fun and laughter that students have with this “compilable flowchart”, I have so far refused to teach “my blocks” which I regard as a clumsy kludge in an otherwise brilliantly executed introductory robotics language. By contrast, RobotC procedures seem fine.
There are a lot of things I don’t like about “C” as a language as well, but I’m really starting to warm to your environment using RobotC. This combination is starting to seem to me to have the potential to be a really really nice introduction to text-based robotics languages. Keep up the (so far) excellent work…
Regarding my computer, it isn’t the latest or best, but it is a reasonable one; 2.67 GHz i7, 8 GB RAM, 2 by 500GB disks in RAID 1 format, 64 bit Windows 7 Ultimate; when in the training table running maze 2 with 2.42 (8.33) RobotC, it shows a frame rate hovering around 60.

That is an impressive machine! If you see 60 FPS on the Maze table, then my guess was wrong. Repeatability is something I'm looking into for the next release.