xmega_connector should use IEEE2015 serial proxy

[jpanikulam]

We have added last year's xmega_connector as the ros-end of serial communication. This effectively replaces the old ieee2015_xmega_driver package, but there is still too much uncertainty to remove the old project.

The ideal path is to replace the communication components of the new one with the old one.

Advantages of the old serial proxy:

• More neatly formatted
• Thread-safe (Individual functions/services do not have to grab an XMega Lock)
• We understand it bottom-to-top

Advantages of new serial communication:

• Works in its current state (The old one also works)
• Designed by Forrest

[khaledhassan]

Is the "old serial proxy" the one used in the 2014 competition, and the "new" one is what you guys wrote for this year's?

-- begin potentially obvious comment -- The message handling code on the XMEGA from last year only supported one message at a time, which necessitated the lock on the ROS side. If you want to remove the lock, you'd have to change the XMEGA firmware as well. -- end potentially obvious comment --

[jpanikulam]

@khaledhassan By old I mean new. Called "IEEE2015 Serial Proxy" from here on:

I think the real solution is somewhere in the middle. Key features to desire from the IEEE2015 proxy are:

• Messages are guaranteed to be sent thread-safely (i.e. not interrupt eachother), without relying on the function that sends the message to carefully apply threadlocks. We don't have to count on each function that sends a message to succeed/exit cleanly to be able to continue sending messages (Maybe not necessary?).
• It's easier to read without waiting for Python to finish writing, meaning we don't have to rely as much on polling (Also maybe not necessary?).

Also: Props for being the first comment on an IEEE2015 issue.

[jpanikulam]

Migrated!