Loading ROS onto a Vex Cortex

[cschun]

Hello! I didn’t know how to contact you besides this way, so I thought to try on here, I was curious about how you managed to use ROS on a vex cortex. If possible could you contact me just email me at thebluenecessities@gmail.com, i have a lot of questions and I don’t know if asking them on here would be the best idea. Thanks!

• Clara Chun

[Octogonapus]

Asking them on here is the best idea. Let's please keep information freely available.

In short, we had a ROS node running on a raspberry pi that sent information over UART to the cortex. We implemented this ourselves. Read through this file to see the raspi side: https://github.com/Team-Optimistic/robot_driver/blob/master/src/robotPOS.cpp Read through this file to see the cortex side: https://github.com/Team-Optimistic/Team_Optimistic/blob/master/uartHandler.c

[gftabor]

There is another option to consider which is

https://github.com/CanyonTurtle/rosserial

@CanyonTurtle might want to explain it

[CanyonTurtle]

https://github.com/ros-drivers/rosserial/tree/melodic-devel/rosserial_vex_v5

In order to use ROS with VEX microcontrollers, you can use the rosserial_vex_cortex and rosserial_vex_v5 packages ( I linked the V5 version). These packages, via PROS, provide a connection between VEX and ROS, where there is a ROS master running on a linux machine. They are documented, so if you take a look at the READMEs they should explain how to get ROS working with VEX. Please let me know if you have any questions about this!

@gftabor thanks for the tag! I'm glad for the chance to share this project with someone!

[CanyonTurtle]

@Clarachun ^^ I meant to tag you in the previous comment.

[gftabor]

So the approach we took when developing the team optimistic code is to build our own protocol for cortex to computer communications and then have the computer driver convert the raw data to ros msgs. This has the benefit of being very low overhead which allows more bandwidth communications. It is a lot more work to add an additional data msg, both sides of the communication have to be edited.

The ros serial approach is a lot more general solution that allows the cortex software to directly receive and send any ros messages. Like all ros communications this general approach has overhead associated with it.

We treat the cortex like a mouse with raw byte stream and they treat it like a computer co processor.

[cschun]

That makes sense to host it off another computer. But I feel like setting up the cortex to communicate with the computer constantly would be a bit odd. Correct me if I’m wrong, but does this mean that you had to have a computer on during the competition and constantly communicating with the robot so that it could handle the ROS packages and calculations.
That’s quite a lot of messages being tossed around tbqh. Also, how did you compensate for the confusing measurements of twist messages? I know they tend to be a confusing mix of accurate and not accurate, my labratory struggled with them this summer. In that same vein, did you have to create an entirely new category of messages to handle the vex microcontroller data? I’m so sorry about probably some of the more basic questions, I’m much less familiar with Vex than I am ROS, so there’s a discrepancy in my knowledge. Also, does this mean that the cortex isn’t handling any ROS related things except for sending messages and receiving them? But how’d you them create cortex friendly messages? If you did, how did you format robotC to cooperate with these messages or take them in?

@gftabor

[gftabor]

So for team optimistic an onboard raspberry pi was the ros master and had all the ros nodes. The cortex sent this messages detailed at this line.
https://github.com/Team-Optimistic/Team_Optimistic/blob/master/uartHandler.c#L6

Raw bytes with left and right encoders. The twist calculation was then done by the Raspi ros node driver. Nothing was in ros messages until it got to the computer.

This is different from the other approach implemented by @CanyonTurtle, which is quite honestly the more "Rosonic" (my play in pythonic) option. His approach has the cortex send actual ros messages over the uart stream.

[CanyonTurtle]

@gftabor explained this quite well, I would like to also help with some of your other questions @Clarachun:

did you have to create an entirely new category of messages to handle the vex microcontroller data?

But how’d you them create cortex friendly messages?

https://github.com/ros-drivers/rosserial/tree/melodic-devel/rosserial_vex_v5
https://github.com/ros-drivers/rosserial/tree/melodic-devel/rosserial_vex_cortex

If you choose to use the approaches linked above, you can use a broad variety of builtin message types to transfer data between ROS and the Cortex / V5 brain. For instance, a quadrature encoder could be represented by a std_msgs::Float32 message type, and you could establish topics for each sensor you are interested in. Or, you could choose to use one topic and publish an array of Float32s for multiple encoders. Right now there are no custom message types that are adapted to VEX hardware, but I think that is a good thing. It is better to try and conform to existing message types, because this increases the potential for compatibility and support around fundamental message types.

Also, how did you compensate for the confusing measurements of twist messages?

Some of the ROS message types certainly pose a fair challenge, but with rosserial_vex_cortex / rosserial_vex_v5 this can be done on the Cortex's end. You can choose to convert sensor values into message formats with calculations on the V5 Brain / Cortex in your PROS code (e.g. with an encoder, calculate the angular velocity by using speed = distance / time, and put this in one dimension of a Vector3 as a twist's 'angular' field, and then publish this twist on a topic). You could also choose to work around more confusing message types by using simpler ones, like Float32, Int, etc...

Also, does this mean that the cortex isn’t handling any ROS related things except for sending messages and receiving them?

The involvement between the cortex and the ROS graph can be as divided or involved as desired. Depending on why ROS is involved, it may be preferable for the ROS host machine to treat the Cortex / V5 Brain as simply a device to be read from, or to do things the other way around. ROS is flexible enough to allow multiple levels of transfer between the two, and I hope that if you are interested in using ROS with VEX microcontrollers you will consider using rosserial_vex_cortex / rosserial_vex_v5!