Add gazebo connector

[virtuald]

WPILib uses a separate implementation of itself to do this, but I'm not convinced yet that this is the right solution. I'd much rather do it from the HAL -- but already I'm seeing why they didn't do it this way. Will decide on this later.

[PeterJohnson]

What issues are you running into? I understand that some things are mapped at a higher level (e.g. joint rotation values and gyro values), but why can't those be mapped back to HAL-level voltages (maybe with the help of a configuration file)?

[virtuald]

I haven't actually started trying to map it all yet, still working on getting HAL filled out. However, there are things like PWM and other devices that the raw values are significantly different than the values going into WPILib.

Probably would need the help of a configuration file -- though, I think I can take advantage of the HalReport functionality. Haven't done that part quite yet.

[computer-whisperer]

How hard would it be to have your simulated HAL be capable of outputting to the 2014 wpilib wrapper? Could that solve the problem of an HAL for the crio?

[virtuald]

It would be highly inefficient.

[virtuald]

Oh, @computer-whisperer , are you talking about outputting to the wpilib wrapper for the simulation? For some reason, I was thinking of something else.

The API to talk to gazebo is actually pretty simple, so we could (should) just do that directly, instead of going through WPILib to do it. The question is just really where should we do it.

[computer-whisperer]

No, I was talking about using it for backwards-compatibility on the cRIO. Yes, it would be inefficient, but it would be better than nothing.

[computer-whisperer]

Another suggestion: what if there were some sort of client/server interface for communicating between wpilib and the HAL? It might introduce a bit of latency, but it would then provide an interface for adding additional software into the setup. The gazebo connector, your idea for a web-based simulator, and other enhancements could all be clients communicating with the wpilib/robot code server.

Just a thought.

[virtuald]

Well, that's sorta what I want to do -- except that I want the server to live inside the simulated HAL (or rather, I want to use the simulated HAL to provide the needed functionality). Similarly, the gazebo connector should be able to live inside the HAL too.

[computer-whisperer]

Are you thinking about using the web simulator while on the robot, or running in a development environment?

[computer-whisperer]

The way I was thinking, the gazebo connector, the web simulator, and the roborio HAL wrapper would ALL be HAL clients, that way you could run the robot code/wpilib setup anywhere, and connect one or more HAL clients to it.

[virtuald]

I think we're agreeing, but I don't see the need to have a client/server relationship. I think that the simulated HAL interface should be general enough to work for all the use cases.

[PeterJohnson]

I would definitely not recommend we make HAL any higher overhead than it already is for actual robot operation. It's one thing to have latency in simulation, it's quite another thing in actual robot operation with things like closed loop control. The network stack is a lot better on the RoboRIO than it was on the cRIO, but you're still looking at multiple milliseconds of latency with UDP. It may work when it's all just feed-forward user control, but any kind of sensor feedback is going to have significant issues--you're essentially doing the equivalent of NetworkTables at a much lower level.

[virtuald]

Yes, exactly.

[computer-whisperer]

Ok, makes sense.

[virtuald]

I'm going to start working on this either tonight or tomorrow. I've successfully launched the gazebo simulator on OSX with the FRC plugins (using this fix), and one of the bots does autonomous mode. I'm going to build the components necessary to talk to it.. shouldn't take too long.

[virtuald]

Looks like protobuf (used for message serialization in the protocol) has limited python3 support right now, so this might take more time. There are various forks that implement support for python3, and the developers have stated that python3 support will be available in a protobuf 2.6.x release.. so hopefully it will be ironed out by kickoff.

[virtuald]

This is definitely a bit more annoying than previously thought.

pygazebo is only tested on python 2.7, and so far has some minor compatibility problems. Thankfully, it uses trollius/asyncio which will be great for python 3.4. However, the protobuf messages it comes with aren't python 3 compatible, because of the protobuf issues.

For now, I'll keep track of these with a fork until they get fixed. The protobuf thing should be done pretty soon I hope (see this issue)

[virtuald]

I've got some test code successfully talking to gazebo using python 3. It's not useful for anyone other than me right now, so not checking it in yet. Tracking various PR's on pygazebo:

• https://github.com/jpieper/pygazebo/pull/8
• https://github.com/jpieper/pygazebo/pull/9
• https://github.com/jpieper/pygazebo/pull/10

[virtuald]

This is going to be yet another python package, the first implementation of it is pushed via 5c67749a794d68cf355aedfdd74dd6c173a0890a.

It uses an entrypoint to setup options/etc, and initializes the gazebo connection via a separate thread. I can use the fake DS to switch between the various modes and enable/disable the robot now. Will add more functionality soon.

Unfortunately, protobuf & pygazebo aren't ready for public consumption yet, and I've got patched versions of them living on my box in order for them to work. Once protobuf is ready, I'll PR necessary changes into pygazebo.

[virtuald]

FYI: protobuf trunk works out of the box for python3. I've pushed my pygazebo changes, those should be merged soon.

[virtuald]

Update: I can drive the gearsbot example around its field, and driving works just as well as the java version. Just need to implement the various sensors now.

[sarosenb]

That's exciting!

[computer-whisperer]

Umm, any idea why the gearsbot goes screaming off into the distance whenever I enable it, and keeps going when I disable it again? The java version worked just fine.

[virtuald]

You're positive all the code is up to date? It works for me. You might want to connect/disconnect your controller, just in case.

Sounds like the PWM values aren't getting translated properly -- as that's what happened when I didn't have it implemented properly.

[computer-whisperer]

Ha, never mind. I didn't realize that it was configured for tank drive, and one of the sides happened to be the throttle control on my joystick.

[virtuald]

Interesting note - using the PID Controller in the python simulator brings the simulated realtime factor down to 0.85. When running the elevator controls in the java simulator the realtime factor is 0.97. Not sure why that would be happening.

[virtuald]

I'm on vacation for the holidays now, so I may not have much time to finish this up if someone else wants to take a crack at it. The biggest problem is that the Gyro/Encoder use an underlying analog/digital input(s), so we need to somehow defer creating those objects, or unsubscribe them (which isn't implemented in pygazebo yet). However, this is difficult to do if we're operating purely at the HAL level, simply because WPILib doesn't give us a good way to hook in for these.

A big issue that needs to be closed is https://github.com/google/protobuf/issues/144, otherwise our package isn't going to be pip installable.

[virtuald]

I've moved frcsim support to its own repo: https://github.com/robotpy/robotpy-frcsim