Full VEXnet protocol specification?

Does anyone know if there’s a full protocol specification for VEXnet? I found this short description http://www.vexrobotics.com/wiki/Vex_Packet_Protocol on the wiki. I’m considering writing drivers for Java and Objective C. Having the full protocol specification would make it much easier and avoid reverse engineering all of this stuff. There is an existing java driver for VEXNet [http://sourceforge.net/projects/javavexdriver/ which supports some features, but not the entire set.

Being an open source programmer, I would open source the drivers on google code once it’s working.

thanks

peter](http://sourceforge.net/projects/javavexdriver/ which supports some features, but not the entire set.)

on the wiki. I’m considering writing drivers for Java and Objective C. Having the full protocol specification would make it much easier and avoid reverse engineering all of this stuff. There is an existing java driver for VEXNet [http://sourceforge.net/projects/javavexdriver/ which supports some features, but not the entire set.

Being an open source programmer, I would open source the drivers on google code once it’s working.

thanks

peter](http://sourceforge.net/projects/javavexdriver/ which supports some features, but not the entire set.)

VEXnet really refers to the 802.11g wifi communications, the protocols on the wiki are serial communication protocols between cortex and LCD display, and joystick and partner joystick. If you goal is communication between PC and the cortex (via the programmers port on the joystick), then the protocol is not really determined by VEX, it’s up to the code on the user side of the cortex (where ROBOTC and EasyC run their code) and is independent of VEXnet.

What’s the intended application?

The intended use is a generic connection driver for VEXNet, which would handle the low level communication. Above that, other people can then implement the necessary libraries to send easyC or RobotC commands.

I would like to control the micro-controller over wifi from either a pc, mac or mobile device. Part of the communication library would be utility for pairing with VEXnet. Given how weak cortex controller is, I want to use some other system to be the brains. Assuming RobotC or EasyC provides sufficient functionality, it could send sensor data over wifi. Once you have that data in real-time, the possibilities open up.

The existing solutions for this type of control utilize the UART ports on the cortex to interface third party wireless solutions. Due to the way VEXnet works, it’s very difficult to use a standard PC to join the network and has been discouraged as it has the potential to compromise competition control. The existing VEXnet is becoming obsolete and is being replaced by VEXnet 2.0, this uses a proprietary point to point wireless communications protocol that is incompatible the wifi built into PC and mobile devices.

I was guessing VEXnet 2.0 was going that way, but was hoping there still might be a way. That’s really too bad, since it closes option of doing some great things with VEX. I guess VEX is moving more towards a closed system and not friendly to extensions like Arduino and Mindstorm.

For me, that really limits the potential and growth of VEX. There are many professional programmers that play with robotics in their free time, so it’s too bad VEX is effectively closing the door for those people.

VEXnet 2.0 has some potential, it’s very new and we don’t know what the long term strategy for its use is yet.

I’m one of those people, I have deliberately chosen not to reverse engineer and explore VEXnet too much, I focused my efforts in other areas. There is a real concern that if details about VEXnet were public then it could be used for destructive rather than constructive purposes.

I’ve done quite a bit of reverse engineering over the years and was hoping VEXnet 2.0 was more open and extensible. I can understand the fear of destructive uses, but hiding the specification doesn’t prevent it. Anyone that has worked with network monitoring tools can snoop the traffic, since it’s on the same freq as Wifi. I hope VEX changes their mind and opens up the specification. I may be an optimist, but my feeling is that most teams want to win fair and square. It also feels like the wrong message to send to users. VEX could grow much more if it was more open and more people could contribute cool things for VEX.

Oh well, I guess I’ll move on to other robotic systems that encourage user extensions.

Most teams, however, the behavior of some teams at the recent world championships (motor modifications) shows that there are always those who want to use knowledge to gain unfair advantage.

At world’s I did hear rumors of illegal modifications, but without proof I dismissed it as rumor. It sucks that a few bad apples can ruin it for others, but most teams I observed at Middle school world’s played fair and worked their butts off. One idea I had for our team during off season is to build a basket shooting robot that uses machine learning (ie supervised learning). Given VEXnet 2.0 is no longer an option, VEX is no longer an option for advanced robotics.

It does make me question, the usefulness of using VEX to teach students advanced programming topics. It really just becomes a mechanical engineering toolkit, which is fine.

The best short term solution is to use the joystick with the programming cable as the interface to the PC. It’s not as nice as direct wifi control but gives you the functionality. This in conjunction with one of the gcc based programming frameworks (ConVEX or PROS) pretty much allows you to do anything you want. An alternative would also be something like this WiFly Module connected to one of the cortex UART ports, this would then allow any networked device to control it.

For a stationary robot, the cable is a viable option. If I was going to use WiFly, it would be better to just use Arduino instead. I really wish VEX would follow the example set by Arduino and Lego. Make their designs open so that enthusiast can contribute cool stuff to the VEX community. Just looking at what’s available in the machine learning space from apache (full disclosure, I’m an apache committer/contributor) there’s a wealth of stuff. If VEX would just open up, it would benefit tremendously. Thanks for taking part in the discussion, I think I’ll focus on other robotic toolkits instead.

Check out www.cloudyrobotics.com , they are using a rasppi to control a cortex from anywhere in the world :stuck_out_tongue:

That’s pretty cool, thanks for sharing it. I see one of the areas of study at SFU is agents. One of my hobbies is writing high performance inference engines, so I’m curious to hear how you plan to incorporate agents with cloudyrobotics. Another area of my interest for the last 10+ years is combining knowledge base and statistical learning to build neat stuff.

Just for clarity, the programming cable is a USB to serial adapter that connects to the joystick. The joystick has the VEXnet key and wirelessly communicates with the cortex, you can communicate with the cortex using any software that can open a COM port on the PC at 115200 bps, the protocol is completely user defined. Just think of the joystick as a rather large, and expensive, wireless dongle connected to the PC.

did you mean raspberry pi?

Thanks for clarifying. That’s how I interpreted the response. I’ve decided to give up on VEX until VEX decides to open the specifications to the public. Given there are other robotic toolkits that are friendly to open source developers, it feels like a dead end to me. I hope I’m wrong, and VEX opens things up. Ultimately they own VEX and have every right to decide where they want to go. As a parent, my free time is limited so I don’t want to waste hundreds of hours on a dead end.

Hi Woolfel,
VEX Robotics was designed to be an affordable and accessible robotics platform used for education. Our primary customer base consists of teachers and students who want a simple solution that “just works” and provides them the tools they need to become engaged in STEM. Our system provides a variety of opportunities for STEM learning, all within a “sandbox” type experience which helps teachers promote STEM without fear of failure.

In general we at VEX try to be very supportive of open-source efforts. We (as many on the forum will attest) always try to be reasonable when providing supporting details on our products for users who want to take them above and beyond their “sandbox” style usage. However there are some aspects of the system which we will not provide. The primary reason why we do not provide these details (including the specifics of the VEXnet link) is our desire to preserve the integrity of the VEX Robotics Competition.

I’m sorry to hear you disagree with our philosophies in this regard, and even more sorry to hear that this detail is a deal-breaker regarding your use of our product. I hope you and your students have enjoyed your experience with VEX up to this point.

Regards,
John

thanks for taking time to respond and providing a thoughtful explanation. I understand that is VEX’s philosophy, there’s nothing wrong with it. From my perspective, I’m trying to teach my son and his team more advanced concepts like machine learning, supervised learning, collaborative agents and other things. Over all, our team has enjoyed VEX minus issues with motors, poor tolerance of VEX parts, VEXnet flakiness and slow shipping.

Competition is fun and all, but my focus is “how do you inspire kids to do insanely great things.” 15 seconds of autonomous programming is a good place to start, but to do anything really advanced, more openness is needed. I have a belief that if we challenge middle school and high school kids to explore advanced concepts, they will rise to the occasion.

Across the last 8 years I’ve seen a pretty decent chunk of “insanely great things” with the out of the box Vex solutions. The combination of metal, gears and motors are pretty cost effective and they work well together. I’ve not really seen a system that offers so much at this price point.

If programming is on your must list then I can suggest two different options:

  1. Use the Cortex Serial port and two radios. For example an XBee module on both ends. Write the command/control protocol for the radio link. The Cortex end reads the messages and does the task, replies back with sensor status. It uses the serial ports to do this.

a) You go simple with “send motor speeds get sensors back” in less than 30 bytes, that gives you about 30 packets a second of data each way.

b)Or go complicated “Move forward 12 and wait for further instructions”. This cuts down on the packet sizes and lets you move some of the processing to the Cortex.

c)Or get really out of control and go “Here is some code, download it, save it and execute it when I say to”. Just like Mars Rovers, etc. You’ll need to write some kind of byte code interpreter for the Cortex. I’ve done this in the past for 6811 chips, so I know it’s doable.

2)Don’t use the Cortex. Lots of other boards out there from Arduino (may be a little slow) to ARM processors of all sizes. The 29 Motor Controller then becomes your new best friend. No pesky Cortex fuses, full 4 amps to ALL ten motors (well you did install the Flux Capacitor for power right?).

Now you have a full range. Entry roboteers, can build, program the Cortex with Robot C. Advanced can jump in with either of the two programming systems that give more advanced control. Your top roboteers can go wild writing code on other platforms.

Hey, do us a favor and report back on what insanely great things your roboteers are doing. We are all about the exchange of really cool ideas and ways to push each other to new greatness.

Good Luck!

I agree kids have done some insanely great things with various robotic toolkits including VEX. Some of “side” robots I saw at world’s were quite fun and cool, no doubt about that.

Honestly I’m not a hardware guy and don’t pretend to be one. My focus is software and AI. At this point, the EV3 + Lejos looks like a better option for me. I prefer OO language and the wealth of open source tools and libraries for AI with Java is far greater than RobotC or EasyC. The other option I considered is python, since there’s alot of open source AI stuff written in python.

I would rather leverage an existing wire protocol and not re-invent a bad one poorly, plus it’s probably more time than I can muster. If I was single and had tons of free time, it would be a fun hobby. As it is, I try to sneak 3-5 hours a week and even that is pushing it.

If I could get my son into bread boards, then I’d have an excuse to dive deep into EE/CS, but that would be totally beyond VEX and cortex.