VEX compatibility?
Is there anyone looking at allowing the Robotics Studio to work with the VEX robotics system? This is a very popular kit but the development tools are weak and C based. I will be leading up a VEX team next year, and would MUCH rather give the kids more real-life programming skills within the Robotics Studio than C.
Let me know if there is already something working for this, or plans to implement it in the future. You can find out more about the VEX robotics kits here:
http://www.vexlabs.com/
Thanks!
Jay
[610 byte] By [
Jay] at [2008-2-20]
Hi Jay,
I've developed an MSRS interface. I've been hoping to post and release it, but I keep getting distracted by life. To use it, you need a bluetooth modem or some other way to talk to the second COM port.
So much for the good news.... If you are looking to use this for FIRST competitions, you will be disappointed. The bluetooth modem is out of bounds as is the PC. If you are interested in working with the kit outside of the competitions, then let me know.
If you just want a better IDE, you can use Visual C++, but tell it that you are using a MAKE file, not a C++ project. You'll get the syntax highlighting, but several keywords specific to the Microchip will not be recognized.
Ed
Great! I would love to check it out. Right now we are hoping to get into next year's FIRST competitions, but the more I look into it we may not be able to raise enough money the first year. I am not going to let that stop me from starting the robotics group at my kids' school, as the experience is worth so much for them. So how are you connecting to the COM port now with your VEX hardware? I've seen a couple of other posts with a Palm interface, so I am thinking if that can be done then we could develop onto a PocketPC... I have so much yet to learn though as to what's possible. Can the MSRS apps run from a PocketPC? Might be a great way to justify an upgrade. My primary goal is to expose the kids to a programming environment and get them thinking with actual hardware/software interactions.
I have done quite a bit VB and VisualStudio development as well as a little C#. I will download the MSRS and start playing around with it. Let me know when you are ready to share what you've been working on as I would love to check it out. If we end up doing FIRST next season then we will just have to use the old development environment.
Thanks again!
Jay
Jay at 2007-10-3 >

Sorry about the delay in responding....
How about we take this conversation offline? I'm not sure most of this forum wants to here about the hardware specifics and other issues or about FIRST.
Contact me at:
EdHarfman
@
InsightBB
.
com
(Loose all of the whitespace. I just want to make the spam engines work for their dinner.)
I can e-mail you the projects to play with. It mostly works, but has a few issues with subscriptions that I've not figured out yet.
I use the BlueSMiRF from SparkFun http://www.sparkfun.com/commerce/product_info.php?products_id=582 and a bluetooth USB dongle to connect to the robot. Up to 115Kb and TTL IO so that it can be connected directly to the RS232 port without level shifters.
The MSRS 1.0 platform is NOT compatible with the PocketPC, but I believe the 1.5 is supposed to be. That would be an interesting platform.... Direct connect to the controller and WiFi/Bluetooth to a PC. Really distributed computing.
My target is to build a Mars Rover for outreach therefore the FIRST rules don't apply to me :>. It's mostly working. Right now, it's a matter for convincing Windows to do the rest of the job. (I can live with the quirks.)
Robot Interfaces that are implemented:
LEDArray (See Ben Axelrod's site - http://www-static.cc.gatech.edu/grads/b/baxelrod/MSRS/index.shtml)
Contact Sensor
DigitalOutput (Predates Ben's interface)
Drive
Encoder
LightSensor
Motor
Sonar
Rover interfaces:
RoverDrive (6 wheel drive)
AirlinkWebCam - Wireless IP camera since I couldn't get the IP camera supplied with MSRS to work with a camera that is not 'connected' to the PC. (Enumeration and selection assumes the camera is connected, but a wireless camera is not 'connected' until you try to connect to it!)
SquareBot configuration files
That all being said for things to look forward to when playing with MSRS.... Try REALLY HARD to get into the competitions. I am not a mentor, but going and watching these kids makes me want to be one. I've gone to the Purdue Regional Contest for the past two years for inspiration. I've not been disappointed. Remember, the FIRST competition is more than building a robot and programming it. Fund raising, outreach, teaching, learning teamwork are a part of it too. (Pick up the April issue of Servo if you haven't done so yet and read Dean's comments.) FIRST is really well designed (IMHO) to give the kids a good taste of all parts of a technical business.To help them appreciate management desires for a schedule and the engineering side of wanting it figure out how to make it work right.
Ed
"Life... ignore it or hate it. You can’t like it." - Marvin the Paranoid Android
It was an interesting interface and appropriate to my robot. There needs to be an 'output' description in MSRS. Yours is a good binary interface and very appropriate for my implementation, but if I could suggest a few changes having implemented it:
1) Names - You describe a binary interface. For a generic interface, leave it generic (Binary or Digital Output). Describing as a specific type of output can led to confusion when trying to origanize a real application. I could see it being used for valves, turning on compressors, lights, power to other devices.
2) In the generic sense, 'true' on the processor may cause the lights to go off, not on. After I implemented the interface, I was working with my light and found that my driver circuit did not fully turn on. My initial thought was to add an NPN driver onto my circuit, but that would have inverted the logic. Then my application would need to remember that on was actually off. (Confusing)
3) You should declare an analog output device as well as the digital. (There are D/A converters as well as A/D after all!) Something akin to your output, but with a range in addition to the value. Range is static for the device (0 to 255, -512 to 511) and value is whatever you set.
Grousing aside (more than a few people think of me a a 'black hatter' - looking for all the problems with a solution), I think it is a very good interface and well worth implementing. You did better with your interface than I did with my first interface. (I also didn't have the guts to actually post it. - Yes, that is meant as a compliment.)
I haven't done anything with the tone interface. That is more than I want to get into for my robot and I suspect a bit of a black hole in the generic sense. e.g. How far do you take the interface? Is single tone sufficient or should it support N tones each with a duration? Should it support WAV/MP3/? Is the robot the target for generating the sounds or is it the console? I'm not in the camp that the robot is just a series of motors/sensors connected to a USB box into the PC. I want the robot to be a structured 'intellegence':
Sensors on the robot
Reflex reaction on the robot (via micro controllers)
Command intellegence on the PC
This is for me playing with it (emphasis on playing :>) - a learning experiement about hardware, robot behaviour and robotic intellegence.
Take the comments above as ramblings that can easily be ignored. ;>
Thank you for your interfaces and your web page. I check it for updates every so often.
Ed
I think the "tone" interface is a great one. I've seen a lot of devices that support either a fixed set of sounds (either prerecored sounds, phonemes, or words) as well as supporting sequential playback of a list of sound indecies. Perhaps start simple:
Code Snippet
namespace GenericAudioClipDevice
{
[Flags]
enum ToneOptions
{
SupportsSingleTone = 0x1;
SupportsMultiTone = 0x2;
SupportsAudioClip = 0x4;
SupportsAudioUpload = 0x8;
SupportsAudioPlayback = 0x10;
SupportsTextToSpeech = 0x20;
}
[DataContract]
class DeviceState
{
[DataMember]
string[] AvailableClips;
[DataMember]
ToneOptions SupportedOptions;
}
[DataContract]
class PlayTone
{
[DataMember] // hertz
double Frequency;
[DataMember] // seconds
double Duration;
}
[DataContract]
class PlayAudioClip
{
[DataMember]
string Identifier;
}
...
class PlayAudioOperation : Submit<PlayAudioClip, PortSet<DefaultSubmitResponseType, Fault> > { }
...
}
It would be tough to prune this down to the minimal set (PlayTone and PlayAudio clip would likely be the most used by hobbyists). A text-to-speech message type would be most used, but may be hard for the hobbyist to implement, especially when you consider that the Windows OS already includes text to speech.
However, some sort of interface like this would be great where wireless access to the robot is either unreliable or slow (ex: 9600 long range modem -- celular data -- etc.). A high level interface like this would require very little bandwidth for a large amount of functionality.
#aaron
This is great! This is exactly the discussions that should be happening. I think we should move it to a more appropriate place though. I want to move it to the wiki, so that we can actually post the code, and edit it. but I fear it will not get the traffic there. If anyone is feeling motivated, please take the initiative and start a thread, or wiki page.
After much nashing of teeth, I've finally completed an interface for the VEX controller. The source code is located at http://www.codeplex.com/VexMsrs. (For those using the IFI controller, it should be easy enough to modify the sources to support it.) The interface is based upon the 1.0 distribution.
No, this code is NOT FIRST competion compatible. (I'm not using the robot for competition, but for education outreach.)
You (obviously) need a PC.
You need to get something that will use the second serial port on the controller. (I used the BlueSMIrF from Spark Fun Electronics http://www.sparkfun.com/commerce/product_info.php?products_id=582) You can modify the code to use the first serial port if you want, just make sure to disable all of the printf diagnostics.
You need a programmer cable. (I've got the hex file included in the zip file if you don't want to compile the file itself.)
Hopefully, some of the readers here are working with the robots outside of competition after the season is over. Good luck to all.
Enjoy
Ed