I downloaded it for the first time today. First, this is great tool. I started writing something similar to this in Java (but *WAY* simpler) to help our the FRC students write software sine the HW wasn't ready. However, this will be much more useful, and I think it will also help for mentoring some of our brand-new FTC students, who are just starting out in programming.

Background: I'm the mentor for 3-4 FTC teams locally, and have been programming professionally for longer than I'd care to mention. We use RobotC and went to St. Louis this year using with one of our teams.

Bugs and/or issues found in about 90 minutes of use, trying to write a program on the Tabletop/Labyrinth environment.

1) nSyncedMotors does not exist in the namespace, although it is in the docs. Strangely, synchBC and the other similar constants are in the namespace2) nSyncedTurnRatio is also missing, probably for the same reason as (1).3) I can't get a break-point in a secondary task to fire. Related, I can only get a breakpoint to fire if it's the first line of the program. If I set a breakpoint as the second line of the program it won't fire.4) Sometimes even if a breakpoint hits, it won't bring up the debugger window. I can do it manually, but it can be confusing if the user is not used to an IDE as the program is halted and there is no 'obvious' reason why it's working.5) When I single step through the program, even when I modify a 'global' variable, the updated value does not show in the global variable debug window until some 'random' time afterware.6) I was unable to get even a very simple program that had a secondary task to work correctly. In our FTC robot, we use a MoveTask() for all robot movement, but this code does not seem to work right in the emulator. I tried a combination of hogCPU/releaseCPU to see if it was related to some global variable's data not being read correctly by the second task, but b/c of the breakpoint and global variable window issues described above I couldn't see what was happening. I finally gave up.7) The emulator appears to completely skip over my 'wait1Msec(10 * 1000)' code at the end of main(). I'm not sure if it's related to some timing issue, but in certain cases the wait1MSec appears to work, and in others it doesn't do anything.

Desired feature:- Since we have the 'NXT Display screen' as a Debug window, it would be nice to be able to write something to it for debug purposes aka. nxtDisplayString(). This would have allowed me to debug my program without the need of a debugger or global variable window.

I suspect I have a very simple bug in my program, but without the ability to see what's going on 'under-the-hood', I'm at a loss as to why. If desired, I can provide a simple example program that should show the issue.

Thanks!

Nate

Fri May 27, 2011 2:00 pm

glia

Rookie

Joined: Fri Feb 11, 2011 10:33 amPosts: 27

Re: First Impressions - 5/25 release

After HOURS of working on the Labyrinth Challenge, I realised that you could have just gone "full speed ahead" and get to the finish by going in between the blue poles. This would have saved me SO much work!

Signed glia's student

Mon May 30, 2011 5:53 am

glia

Rookie

Joined: Fri Feb 11, 2011 10:33 amPosts: 27

Re: First Impressions - 5/25 release

Liked:The green lines that show which program line is being implemented – excellent for debugging.The rotation of the table so that the challenge is always seen from the robot’s point of view (in my experience some younger students have trouble with mental rotations).The blue columns – student chortled with delight when these toppled over. The detail of the virtual robot – even the back wheel movements are delineated!The added “fireworks” plus congratulatory message when a challenge is completed – student grinned from ear to ear. The short time between making a program change, and the ability to test the effect of that change, makes it possible to test more lines of code in a given time interval than would be the case with a “real” robot. This short time interval also permits changes to be retained in student’s short-term memory during testing, and appears to make the whole process almost mesmeric(!)Especially liked by student:The discovery of a “cheat” for one of the challenges (see student comment above!) Not so liked by student:The addition of the small random element that made the robot’s path less predictable. For students with a computer science background I suspect this will be a point requiring continued explanation. Comp. Sci. students operate in what philosophers call a “deterministic universe” where, if the precursors of an action are known, the results can be exactly predicted. Physicists living mentally in the 1800s can have their deterministic system calculations using incompressible balls rolling on frictionless surfaces in vacuo, but real life isn’t like that. Personally I think this small amount of indeterminacy in the robot’s responses, giving it a small element of something like “free will”(!?), is a good thing, as it mimics the variable reactions of a real robot. After the student was given some strategies to cope with this variation, things went fine.The system “fell over“ a couple of times on the Windows XP system (but hey, it is an alpha implementation), however this has not happened so far on the Vista and Windows 7 systems. Puzzling:When following a line, the virtual robot on the Vista and Windows 7 computers (both about 60 frames on the training table) worked fine with a threshold of 45 (GAMEBOARD - Line tracking for rotations). On the Windows XP system (about 9 to 12 frames), a threshold of 90 was needed to allow the robot to line follow.The effect on the robot of the “randomness factor” appeared to be greater on the Windows XP system than on the Vista & Windows 7 systems.The motion of the robot is fine when line following using motor powers of 25/55, but when one of these values is changed to 0, the appropriate wheel on the virtual robot does not stop, it still goes backwards. When the values are changed to -40 & 100, the whole robot goes backwards on the Vista & Windows 7 computers; my student pointing out that these actions do not mimic reality.My reaction? I think this method of learning robotics is revolutionary, and if the present rate of progress can be maintained, this project has every prospect of being a spectacular success…

Mon May 30, 2011 10:08 pm

Ed Paradis

Rookie

Joined: Mon Feb 14, 2011 10:37 amPosts: 49Location: The Pitts(burgh)

Re: First Impressions - 5/25 release

I'm glad you liked so much about this release! It really makes me happy here that you called out a lot of specific design ideas that the team here decided upon. It also sounds like your tester had fun, but was challenged. This is exactly the reaction we'd like to see!

glia wrote:

Puzzling:When following a line, the virtual robot on the Vista and Windows 7 computers (both about 60 frames on the training table) worked fine with a threshold of 45 (GAMEBOARD - Line tracking for rotations). On the Windows XP system (about 9 to 12 frames), a threshold of 90 was needed to allow the robot to line follow.The effect on the robot of the “randomness factor” appeared to be greater on the Windows XP system than on the Vista & Windows 7 systems.

In all our testing, nothing hurt the experience of students more than low frame rates. 9 to 12 FPS is below what we would consider our lower threshold. The physics glitches and strange unpredictability you're seeing are almost certainly due to the low FPS. Mitigating this more than we already have done is a big design goal.

Now crashes... That is a different matter! We're trying to catch all of those before you guys do.

glia wrote:

My reaction? I think this method of learning robotics is revolutionary, and if the present rate of progress can be maintained, this project has every prospect of being a spectacular success…

Completed the Challenges using standard RobotC - seems to work fine. I'm assuming that teleportation to Planet H98 is not yet available? Was very impressed with the realistic robot - I managed to turn it upside down during one "whoops" in the final challenge - robot image remained excellent, with the rear wheel rotating gently! Used the Windows 7 60 FPS computer for the above - not the Windows XP 9 to 12 FPS machine.In your testing, what is the main factor governing FPS speed? Is the CPU speed or the graphics card speed more important for a computer running Planet H99 - and does a computer with two CPUs handle Planet H99 better than a single CPU machine with the same CPU & graphic card speed?EDIT: The reason for this query is that I was asked if it was worth upgrading the student's Windows XP system to better handle H99.

Last edited by glia on Fri Jun 03, 2011 8:27 pm, edited 1 time in total.

Fri Jun 03, 2011 5:04 pm

droidfreak36

Rookie

Joined: Sat Jul 17, 2010 3:41 pmPosts: 19

Re: First Impressions - 5/25 release

glia: Teleportation to H98 is available. Just complete the last H99 challenge (teleport pad) and the 3 missions in the right column (on H98) will be unlocked.

A few comments:

I don't like the way the new version doesn't include the sensor configurations. First of all, it lets me forget which sensor is in which port. Second of all, it doesn't let me rename the sensors or motors to names I like to use (rt, lft, US, etc.). I assume you're still working on a better method of sensor configuration, but at least please add those configuration lines back in soon.

Another difficulty I had was that it was hard to get repeatable results. I know this is the result of a wind effect, but it is annoying if you try to code a whole challenge in one program. In FLL, FTC and VRC competitions the autonomous program is run in a windless environment and must get repeatable results to work, so I suggest you make at least some challenges in such a way that they have no wind and you must complete the entire challenge in one program. If you want to make those more realistic you can always make some motors randomly run faster than others to make the use of encoders necessary.

_________________NOTE:This Star Wars fan thinks the droids should have won the Clone Wars.

Robots rule!

Fri Jun 03, 2011 7:02 pm

glia

Rookie

Joined: Fri Feb 11, 2011 10:33 amPosts: 27

Re: First Impressions - 5/25 release

droidfreak36 wrote:

glia: Teleportation to H98 is available. Just complete the last H99 challenge (teleport pad) and the 3 missions in the right column (on H98) will be unlocked.

Thanks droidfreak36 - I didn't notice this, and I have just cleared the record of Challenges to try again using "natural language" commands. Ah well...

Regarding "Natural Language" RobotC, I'm puzzled.File/Open Sample Programs/Natural Language Samples/point turn.c did not appear to cause the robot to turn the same number of degrees clockwise and anti-clockwise.

Labyrinth Challenge notes page 6, the first turn of the robot needs to be 90 degrees anti-clockwise or 270 degrees clockwise. The page 6 suggestion is for a clockwise pointTurn(right) instruction. The longer 270 degree turn seems anti-intuitive to me. Is there some reason to prefer clockwise rotations of the robot, or is this just to test if the student is awake?

pointTurn(left); // make a sharp left turn wait(1.05); // wait for 1.05 seconds stop(); // stopseems to make the robot turn about 90 degrees anti-clockwise - but the commands following the stop(); seem to influence the amount of turn, causing the 90 degree turn to increase by about a quarter or a third. For example, following the commands above by wait(2.0); makes the robot turn more than 90 degrees anti-clockwise. Substituting forward(75); // forward speed 75 wait(7.0); // wait for 7.0 seconds stop(); // stop the robotfor the wait(2.0); makes the robot turn even more anti-clockwise.It surprises me that later commands can change the effects of earlier commands. This seems to be quite reproducable.I guess I must be doing something wrong... Any hints?

Fri Jun 03, 2011 8:43 pm

RobinShoop

Site Admin

Joined: Thu Jul 05, 2007 12:45 pmPosts: 35Location: Carnegie Mellon

Repeatability

I noted the comment from Droidfreak:

"Another difficulty I had was that it was hard to get repeatable results."

Initially I was using a laptop using a battery and had the same issues. I found out that laptops that are not plugged in do lots of things to extend the life of the battery that significantly reduce reproducability. Once I plugged my computer back in I get very reproducable results every time. Are you using a laptop that isn't plugged in? Please let us know.

Thanks

Sat Jun 04, 2011 5:16 pm

droidfreak36

Rookie

Joined: Sat Jul 17, 2010 3:41 pmPosts: 19

Re: First Impressions - 5/25 release

No, I'm not using a laptop. I'm using a PC running Windows XP. It's a weird computer because my dad made it a while ago and upgrades it to keep up with the technology. I had problems during racetrack challenge when I tried to do it in one program. The robot started getting about a foot of variance, which isn't good for trying to go around all those obstacles.

_________________NOTE:This Star Wars fan thinks the droids should have won the Clone Wars.

Robots rule!

Sun Jun 05, 2011 10:22 am

Ed Paradis

Rookie

Joined: Mon Feb 14, 2011 10:37 amPosts: 49Location: The Pitts(burgh)

Re: First Impressions - 5/25 release

droidfreak36 wrote:

No, I'm not using a laptop. I'm using a PC running Windows XP. It's a weird computer because my dad made it a while ago and upgrades it to keep up with the technology. I had problems during racetrack challenge when I tried to do it in one program. The robot started getting about a foot of variance, which isn't good for trying to go around all those obstacles.

When running one of the challenges where you see a lot of variability, what does the white number in the top left read? Does it stay steady, or does it bounce around a lot?

I tried watching it for a while. Most of the time it stays between 40 and 50, but once it jumped below 30 for a few seconds. That was weird...

Anyways, maybe that's the problem.

_________________NOTE:This Star Wars fan thinks the droids should have won the Clone Wars.

Robots rule!

Tue Jun 07, 2011 5:22 pm

mmckee

Moderator

Joined: Thu Jun 09, 2011 10:14 amPosts: 7Location: Pittsburgh, PA

Re: First Impressions - 5/25 release

droidfreak36 wrote:

I tried watching it for a while. Most of the time it stays between 40 and 50, but once it jumped below 30 for a few seconds. That was weird...

Anyways, maybe that's the problem.

I'm not entirely certain what the ideal frame rate for the virtual world is (which is what the number readout represents), but I do know that large fluctuations can really mess with your program, especially since it is unlikely to fluctuate the same way every time. If the issues persist, try making sure that you don't have any background tasks running on your computer, or decrease the power level of the robot, which will help keep your frame rate a little more constant.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum