Running a VMware Player Virtual Machine to run a Driver Station

[Philip Arola]

Like I stated in my post, I have hardware changes (apparently, I think it is my USB headphone amp that may be doing this) that mess up NI licensing.
I know my laptop is perfectly capable of running the driver station in a VM. I have. I just need a bit of help configuring the network. It doesn't communicate with the robot from within the VM(yes, I set the IP properly), but I can communicate in the host OS fine. Like I said, the licensing issues are what I am trying to evade so I don't have to reinstall constantly.

[Philip Arola]

I worked it out.
I bridged the 2 VMware adapters and the WiFi adapters in the Windows Network manager on the host, set the bridge IP and DNS as I would the WiFi adapter, and set the Virtual Ethernet adapter in the guest to the same IP and DNS.
The host Driver Station doesn't work in this config (it works without the bridge), but the VM runs it fine.

[abrightwell]

I have the Classmate E12 2014 developer and driver station image running in VirtualBox (see picture). Essentially, through some Windows PE madness I was able to do so, but it wasn't "easy" to figure out. There are a number of reasons that I wanted it in a VM, most of which I wanted a develop in a *nix environment and test the robot with minimum hardware and effort. What is important to note though, is that we will not use a VM for competition. I don't even think that would be smart for performance, but probably too complicated due to the networking with the FMS. As usual we will use a standalone laptop solely dedicated to the purpose of being a driver station. At any rate, it was a fun exercise and I now have my test machine.

[NotInControl]

You should make sure that you uninstall the driverstation from the host computer so that it doesn't cause IP conflicts if opened.

The driverstation has an option to modify your IP address automatically by default to change it to the 10.TE.AM.5 IP address required.

Doing this on the host and VM computer will cause conflicts.

Also I would recommend only using the VM Driver Station for testing purposes only, and not as your competition driver station. You should have a dedicated driver station propoerly configured to run natively on the hardware for competition and matches.

[defied]

Some things to watch out for:

I work primarily with ESX and ESXi, so I don't know if workstation has this, but ensure USB passthrough is enabled, so the Virtual can access the controllers.

If you use bridging, the field may authenticate the traffic packet based on MAC address, and if the VM interface MAC is encapsulated in the payload, but the Physical MAC's interface is registered as sending the packet, the field radio could reject/drop those packets. I think this is highly unlikely, as the field network last year was a simple configuration.

The same applies if you are using NAT'ting, except replace everywhere I said MAC with IP address. Because different organizations have produces all of these different items at a nearly free to FIRST level, I HIGHLY doubt this is integrated in to the Field.

Those are the big ones I can really think of.
Make sure you have vmtools installed so as to optimize your video, and virtual hardware to hardware mapping.

Hope this helps, and let me know if you have nay other questions.
D

[Joe Ross]

Originally Posted by defied

If you use bridging, the field may authenticate the traffic packet based on MAC address, and if the VM interface MAC is encapsulated in the payload, but the Physical MAC's interface is registered as sending the packet, the field radio could reject/drop those packets. I think this is highly unlikely, as the field network last year was a simple configuration.

The same applies if you are using NAT'ting, except replace everywhere I said MAC with IP address. Because different organizations have produces all of these different items at a nearly free to FIRST level, I HIGHLY doubt this is integrated in to the Field.

I helped a team that had bridged their ethernet and wireless connections. They were not able to connect to FMS until they removed the bridge, even though all other settings were OK.

I don't think the field network configuration is as simple as you suspect. From the FMS whitepaper:

The FMS software (running on the FMS Server)
communicates with each Driver Station via the
managed switches in the Scorpion Case and Station
Control Cabinets. This communication employs
team-specific virtual local area networks (VLANs)
which serve to isolate each teams data traffic.
...
The FMS software configures the managed switches
and Access Point before each match to ensure the
data and communications for each team is kept
separate from others.

[defied]

Originally Posted by Joe Ross

I don't think the field network configuration is as simple as you suspect. From the FMS whitepaper:

Hi, Joe.
What is being discussed in that body of text refers to creating multiple isolated Virtual Local Area Networks (VLANs) in order to keep traffic communications privatized per network (or robot in this case). This could prevent someone on one robot from spoofing traffic on another robot on the opposing team.

If you're statement that bridging did not work, then yes, there could be another method of security in play. I would have to see the traffic to determine if that is the case and what it may be. 0]

Thanks for the info! I appreciate it. It will be interesting to see their latest whitepaper. I'm sure I'll be asking more questions.

D