View Full Version : RoboEmu 1.11beta1
To commemerate the 790th download (that's an average of once per team!) of RoboEmu 1.10, I bring you RoboEmu 1.11.
Like 1.10, I'm releasing it here first to get a little feedback before turning it loose on the community as a whole in order to save headaches for both myself and the endusers.
Anyways, I think you're going to like the new version, as it finally supports all the operators, both unary and binary. In addition, I took almost all of the suggestions I got last time around and implemented them. Here's the changelog:
Fixed LOOKDOWN
Fixed ABS
Added support for REV, SQR, DCD, NCD, SIN, COS
Added support for //, **, */, DIG, REV
Added match mode (15s autonomous then 1:45 normal)
Added parsing of $STAMP directive--only need to open slot 0 now
Added ability to minimize
Added ability to open project files from command line
Added check for 26-byte limit
Added file freshness check--will reload files if needed
Added '!dump directive
Changed UI to have a pause toggle instead of two menu items
Moved recent file list to registry, where it belongs
As always, I'm looking for bug reports, logic errors, or new feature suggestions as well as anything else you want to send me.
--Rob
VERY COOL!!!
do you have to src available?
Nate Smith
09-02-2003, 09:11
Out of curiosity, did you correct the action of comp_mode? Per update 11, 1 now means disabled...
Originally posted by guzugi
VERY COOL!!!
do you have to src available?
Yes, RoboEmu is open-source, GPL'd software. I didn't post the source for 1.11beta because it is a little on the big side and I didn't really want to waste CD's space. If you want the source for version 1.10, it's available at my website, http://www.robbayer.com/software.html. Or, if you want the 1.11beta1 source, I can send it to you later tonight.
Originally posted by Nate Smith
Out of curiosity, did you correct the action of comp_mode? Per update 11, 1 now means disabled...
Oops, kinda forgot about that. I'll do it for the official 1.11 most definately. Thanks for the reminder.
Here's a few questions I have for people:
1. What does PBASIC do if you try to divide by 0. RoboEmu currently crashes.
2. Is it legal to have more than one SHIFTOUT (reinit master uP)? RoboEmu currently allows this, but I'm not sure if the actual controllers do.
3. What does PBASIC do with array-out-of-bounds type errors? Yes, this does mean I'm currently working on supporting arrays.
4. Are there any other operators/commands/features you'd like to see.
i noticed you mention that it "automatically reloads files"? how does one do that? for example: i use roboemu in parallel with the stamp editor. When i make a change on the program, i have to switch to roboemu, browse for the file again, and then run it again...is there a shortcut to just say "reload the current file"?
Steven Carmain
09-02-2003, 12:52
And can you change the switch names like dashboard v1.1?
Looks like you can, just double click on the titles, and change the name!
Originally posted by guzugi
i noticed you mention that it "automatically reloads files"? how does one do that? for example: i use roboemu in parallel with the stamp editor. When i make a change on the program, i have to switch to roboemu, browse for the file again, and then run it again...is there a shortcut to just say "reload the current file"?
If you pauses the emulator (ctrl + p) and then start it again (ctrl +p), it will check to see if the file has been saved since the last load. If it has, it will ask you if you want to reload. Say "yes" and it should work correctly. Let me know if it doesn't.
Joe Ross
09-02-2003, 13:21
Originally posted by rbayer
2. Is it legal to have more than one SHIFTOUT (reinit master uP)? RoboEmu currently allows this, but I'm not sure if the actual controllers do.
4. Are there any other operators/commands/features you'd like to see.
2) According to Tom Watson at Innovation FIRST, you can reinitialize the master uP more then once. I have not tried it though.
I'd like to see a "real-time" mode, that runs through one loop and then pauses for the rest of 26 ms.
I'd also like to see a single step mode, so that it runs one loop of your program, and the pauses till you step again.
Originally posted by Joe Ross
2) According to Tom Watson at Innovation FIRST, you can reinitialize the master uP more then once. I have not tried it though.
I'd like to see a "real-time" mode, that runs through one loop and then pauses for the rest of 26 ms.
I'd also like to see a single step mode, so that it runs one loop of your program, and the pauses till you step again.
Thanks for the info. I'll give it a try on a real robot soon, but hopefully it will work.
How fast is RoboEmu running for you right now? The way it's written, it should run at a maximum of one loop every 26ms. Is this not happening?
Single-step would be very cool and very easy to implement. I'll see what I can do.
Steven Carmain
09-02-2003, 13:30
I tried the time again, and even reset my computer, and the time is about 2x fast. And, the serout must have all the numbers in, unlike the old one.
Joe Ross
09-02-2003, 13:34
I agree with Steve. It is at least 2 times faster then it should be. It may be even more then that.
Greg Ross
09-02-2003, 15:12
Originally posted by Joe Ross
I agree with Steve. It is at least 2 times faster then it should be. It may be even more then that.
THAN. Have you been programming PBASIC too long?;)
I'm not sure if it this version, or if it's all, but it doesn't seem to support the "Toggle" command for feedback lights on the operator control.
Originally posted by guzugi
I'm not sure if it this version, or if it's all, but it doesn't seem to support the "Toggle" command for feedback lights on the operator control.
You are correct. No toggle support yet.
any idea if that would be in the next version (toggle) ? and when do you expect the next version?
also, let me just personally thank you because RoboEmu has saved me SO MUCH time! Now i can work on robot software AT HOME, without any robot, and know that when i put it on the bot, it will work perfectly, the first time!
THANK YOU!!!
Joe Ross
10-02-2003, 00:44
Originally posted by gwross
THAN. Have you been programming PBASIC too long?;)
I don't think that's the problem...just that it has been too long since I took Mrs. Ross's English Class ;)
Back on topic...
I tried the timing on my windows 2000 machine, and it works fine. On the windows 98 machine, it runs too fast. Any ideas?
Originally posted by Joe Ross
I tried the timing on my windows 2000 machine, and it works fine. On the windows 98 machine, it runs too fast. Any ideas?
That's very, very strange. On my computer, it seems to run 2x too slow. (ie 50ms/loop). I'm going to keep trying to fix it, but I'm not quite sure what's going on.
--Rob
Joe Ross
10-02-2003, 01:08
actually, I saw the 2x too slow when i ran it in wine...but I attributed that to wine, not the program.
I agree with Steven Carmain. I am running my same program which is using the posted 38 loop count per second algorithm on emu 1.10 and 1.11 and there is a marked difference. My program runs much faster on 1.11. (Actually, under the 1.10, my program would run the 15 second loop in just under 18 seconds, anywhere between 17.6 and 17.9 seconds.)
Also, the serout from the default program I downloaded from the Innovation First site has to be adjusted by adding 4 instances of ",127" at the end of the serout command which makes the completely compliant with the comment that comes with the default code that talks about the SEROUT line.
Lastly, 1.11 keeps dying when I have bad code.
Also, if there is bad code and I get the standard "Would you like to quit?" and I say "No" then the file I just loaded get's locked so that I can't save it using the PBASIC editor. I have to kill RoboEmu to save the file. This is not too much of a problem when I am writing good code.;):o
Steven Carmain
10-02-2003, 13:29
I used the code that I posted, and it still runs 2x fast, but runs fine in 1.10. My computer is an XP.
Wow. Five days of no activity and this is already on the second page. Anyway, I'm going to try to finish up 1.11 tonight, so this is the last call for any bug reports, etc. Here's the current list:
Bugs:
Strange timing issues
Crashes if dividing by zero
Crashes with very long lines
Doesn't close file handle properly on errors
Falsely gives ELSE without IF in some instances (doesn't happen in 1.10)
comp_mode is backwards (I hadn't read the update from InnovationFirst at the time)
Proposed features:
Toggle
Arrays (::shudder:: may or may not happen until next beta release)
Single-step
More of the DEBUG modifiers (ie BIN8, etc)
Anything else? I'm going to start working on it around 8:00 tonight, so please let me know by then. As always, either post here or send me a PM/email.
Jeff_Rice
15-02-2003, 11:14
It does not detect errors with the number of initialization constants turned on not being the same as the number of things in the Serin.
This is important when you are making a timer.
Thank you for making RoboEmu, rbayer.
well, for one thing, the toggle function might be nice...
but also...
i noticed some differences in the way that roboEmu and the true basic stamp interpret logic statements. I'm not sure what the problem is exactly, but in the example i had, if you have more than one operator in a series like this...
if [condition1] & [condition2] & [condition3] & [condition4] then
...
roboEmu does this the "correct" way, where ALL conditions have to be true, but this is not the case with the stamp interpreter. i've tries many combinations of parenthesis’ with varied results, but never the way i want them.
i guess i'm not sure what the problems is here, if it is roboEmu, or the stamp. Maybe i'm just have some syntax error, but i'll let you decide..
MEH
The & is not the correct way to do it as it is meant for bitwise anding (like C's &). Use the keyword AND instead as it is like C's &&.
Hmmm... I'll see what I can do to make RoboEmu more correctly incorrect.
Anybody have anything else?
--Rob
lol, THAT would fix it! thankyou!
by the way, what does the '&' operator do then?
Originally posted by guzugi
lol, THAT would fix it! thankyou!
by the way, what does the '&' operator do then?
It performs an AND on each bit. Likewise, the | performs an OR and ~ performs a NOT. Examples:
110111001
& 010101011
----------------
010101001
110111001
| 010101011
----------------
110111011
~110111001
----------------
001000110
You should always use the keywords OR, AND, and NOT when combining expressions (ie IF NOT (p1_y <137 AND p1_y>117)) and only use the bitwise versions when you really know what you are doing.
Any other RoboEmu comments from anyone? I'm off to robotics in a few minutes, but should still be able to work on stuff later tonight.
--Rob
another thing that would be nice is to have indicators for port feedback lights...such as "out12, out13, etc"
just an idea
eric
RoboEmu properly reports if the gosub depth is too great. However, if you fix the problem in your code, save it and have RoboEmu reload it, the depth is still reported as incorrect. RoboEmu must be exited and restarted.
redbeard0531
18-02-2003, 23:24
Please add support for a reset button. Or at least set all vars to zero when "Begin match" is clicked. Otherwise my counter is never reset. I have to completely exit out to reset it!
Greg Ross
19-02-2003, 12:19
Originally posted by redbeard0531
Please add support for a reset button. Or at least set all vars to zero when "Begin match" is clicked. Otherwise my counter is never reset. I have to completely exit out to reset it!
This sounds like a disaster waiting to happen. (A little hyperbole can sometimes come in handy.;) )
Remember that you power up your robot when you place it on the field, and your program then begins running (albeit disabled) as soon as communications are established with your OI. This means that if you don't check the comp_mode bit, and only start incrementing your counter after it changes to 0, your counter could have been running for something like 2 minutes before the match starts. I handle this problem by reseting my timer to zero whenever comp_mode = 1. Unfortunately, this isn't a 100% solution when running RoboEmu, since it doesn't start a match disabled.
What I would like to see RoboEmu do is to start a match with the 10 second human player period -- during which time comp_mode would be set to 1. Only then would comp_mode be cleared, and auton_mode be set. It would also be very helpful to have a visible match timer.
redbeard0531
19-02-2003, 19:38
I deal with that problem by putting the timer code in the autonomous subroutine. Since it doesn't get called until auto_mode = 1, i time from the start of the autonomous period. The only assumption that I make is that the robot will be fully powered off between matches;).
Greg Ross
20-02-2003, 17:43
Originally posted by redbeard0531
I deal with that problem by putting the timer code in the autonomous subroutine. Since it doesn't get called until auto_mode = 1, i time from the start of the autonomous period. The only assumption that I make is that the robot will be fully powered off between matches;).
I was thinking of my match timer -- which needs to run the entire match. (I won't reveal what it is used for. ;) )
Sorry for the delay everybody. I've gotten a grand total of approx 12 hours of sleep in the past five days and haven't had any time to deal with RoboEmu. Anyway, I'm thinking I might start work on 2.0, which will include some fundamental changes to the core of RoboEmu. Look for a preview release within a few weeks.
--Rob
Greg Ross
20-02-2003, 19:17
Originally posted by rbayer
Sorry for the delay everybody. I've gotten a grand total of approx 12 hours of sleep in the past five days and haven't had any time to deal with RoboEmu.
We understand. That's how we came up with so many RoboEmu suggestions within the last couple of days. We've been spending day and night writing code, debugging in RoboEmu, and then trying to figure out why it doesn't work in the robot. ;)
yes, agreed, well writen, FREE software, especially in this situation, is very helpful, THANK YOU!!!
Ken Delaney
17-03-2003, 19:51
I would like to express my gratitude to Rob for all his hard work on creating RoboEmu. I found the program invaluable for my programmers since we had so little time with a finished robot. We had to change very little of the code since we had debugged much of it using the emulator.
Our robot is a crab drive robot that can stack autonomously. We spent a lot of the time at Annapolis dealing with unresolved mechanical issues and trying to compensate for a high center of gravity. We should be much more competitive at the Philly Regional.
One suggestion I have for the emulator would be to show the sensor values. We used pots to control our steering and found the interface for using the sensors a little bulky.
Rob if you are going to be at Houston I would like to say thanks in person.
Originally posted by mrd_udhs
One suggestion I have for the emulator would be to show the sensor values. We used pots to control our steering and found the interface for using the sensors a little bulky.
Rob if you are going to be at Houston I would like to thanks in person.
You're very welcome. I'm glad some people are making good use of these things and finding them useful.
I've been trying to find ways of streamlining the sensor interface (same with the wheel and aux) but haven't found anything good yet. I'm still working on it, though, and will hopefully have something in version 2.0.
Unfortunately, my team doesn't qualify for nats this year (team 6) and I don't think I'll be able to take time off school to drive down myself. Anyways, I'm glad you've found RoboEmu useful and I really do appreciate the thanks and the feedback.
--Rob
I have a modest suggestion. Using ctrl-P to pause the emulation is really great, but you can't do that unless the main tool bar is the window that is active. If you've been playing with inputs, you have to go back and click on the tool bar to ctrl-P. That's the only GUI issue I have.
coolness++;
I'll add it to the list. Anyways, my plans for this weekend fell through, so I should be able to get a lot of work done on 2.0. Then again, I've said that about every weekend...
With any luck, I'll have something usable before nats.
--Rob
WizardOfAz
03-04-2003, 06:55
Hi Rob,
Great to have so many issues resolve with 1.11. But there is a problem with reload I guess.
If I load my program and run it, all fine. If I then modify it (even just resave with no changes)I get then offer to reload, which I OK, then a popup error dialog that says "Error Parsing file on line 560. Error: Malformed Serout: 14 Do you wish to quit?"
If I say yes, it quits, I restart, all is well again.
If I say no, then pause, then unpause, I get the prompt to reload again, and the same sequence follows.
If I use file->open files etc to try to reload the file that way, RoboEmu just freezes up.
I will send the source file off the list if you want, let me know.
Bill
Darn it! I thought I fixed that. Anyways, the problem is probably that your serout doesn't contain all the bytes (255, 255, followed by two relay bytes and 16 PWMs). In theory, I fixed this issue way back when the eduBot came out, but apparently the reload feature doesn't make use of the new, less-strict serout requirements. I'm sure everybody is sick of hearing this by now, but I'll say it anyways: I'll try to incorporate it into 2.0. In any event, I would definately appreciate the source if you are willing to send it as it helps me track down bugs faster.
--Rob
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.