Can this be done?
 

How many people really think that this can be done?

If yes, then do you really think that it would be worth it. If no, why do you think so?

Just curious on how other people are thinking about this.

Re: Can this be done?
 

In my opinion it can be done, just not with the current BOM. (Bill of Materials) to be competition legal.

For use durring a competition, I do not think that it is fesable due to excessive noise from everywhere. Also, upupupulefetupleftslowslowslowfastfastfast.... my hands can move a steering wheel/throttle faster. If just for a grabber of some sort, buttons would be more accurate.

Anyone have a good guess what any lag would be?


Wetzel
~~~~~~~~~~
H:\BT\BT - Flaming June.mp3

Re: Re: Can this be done?
 

Well, it depends on the computer you're running it on. The only real lag would come in the time it takes to say the word "up" or "gripper in" or (even worse) "start to dance in circles and make things go boom."

The IFI control system will loop approx. every 1/30th to 1/40th of a second, depending on how much stuff it has to do between the serin and serout as well as how much it has to serin. The way I'm thinking of doing it, you wouldn't use the OI at all and so your code would just be:

...declare variables...
Serin COMA/COMB, ..., [valForPWM1, relayA, valFor2, etc...]
Serout USERCPU, ..., [valForPWM1, relayA, etc...]

This should be very fast and would only depend on the speed at which the computer could throw data at the Tether port.

Again, this assumes that the tether is RS-232, whcih no one has been able to confirm. Basically, the computer would make the RC "think" it is the OI and instead of sending raw joystick values, etc it would send the pre-processed motor output values. Then the RC just needs to turn around and spit these values at the output uP.

Are people actually interested in this? Nobody has reported any errors in RoboEmu 1.06 as of yet, so I don't really have a programming project going right now, and that's not a good thing for my sanity. Anyway, I'll either start working on this or I'll do a Linux port of RoboEmu. Both are projects I've had on my list for a long time, although I got the idea for this one back before nationals last year.

Personally I find this dumb because of such complexities involved in getting a robot to move. You can't just tell it to move foward. I can see it now:
Operator: turn 90 degrees fast
Operator: foward faster faster faster
Operator: stop
Operator: turn 360 degrees
Operator: get goal
And on and on and on and on
Its just not practical for the purpose because of all the variables you'd have to command the robot to do.

I agree with you on the voice-operated part, but what I plan on doing is writing generic libraries that could be used to control the robot using a regular laptop. This would open up the possibilities for all kinds of neat off-season stuff, though I'm not yet sure what these neat things would be. Anyway, yet another day has gone by without any comments about RoboEmu, so I'm about ready to declare it "gold" and move on to this project.

there's one problem:

it's not allowed to use a computer to control a bot.

Besides, the only advantage would be debugging, which really isn't necessary.

In most cases, the control system can actually be far more reliable compared to a computer, just imagine getting to the most important part of a match and your computer blue-screens!

Durring offseason demos you can tho. And I bet you could make it look really snazzy. Especially with a touch screen....


Wetzel
~~~~~~~~~~~
H:\Ludvig van Beethoven\The Essential Beethoven\Ludvig van Beethoven - 04 - Moonlight Piano Sonata.mp3

in a way its a good idea to have run robot via laptop but i agree with everyone else. its to many variables to work out. plus each robot has a dif program so how would u be able to create a program in which we must be able to easily personalize for our needs.

Exactly.

Easy. I'll write a dll that includes all the communications code, etc. You just pass in the values you want the motors/relays to have and it outputs the correct packets. Likewise, you just call a function in the dll to get the current sensor values. Then, all you have to do is write a short C/C++ (or VB) program to do the processing in between the getSensorValues and the outputMotors calls (names pending).

I'll probably write some wrapper-app that includes some basic functionality, such as DirectInput joysticks, on-screen buttons, etc. for people that don't know C.



Anyway, if you're interested, vote here.

To eliminate background noise... Use extra materials(mainly lexan) to create a soundproof box.

I finished it. Check out RoboCon in the whitepapers. Unfortunately, I don't know of any GPL'd voice-recognition libraries, so it doesn't do any of that stuff. However, it does let control a robot from your computer. Please dont respond here as I dont check this thread often. Please respond in the programming forum.