Currently, the simulator crashes when you create a CANTalon device. Would be great if someone could pitch in here, I won't have time until late in the weekend. One thing that's very important is that it shouldn't crash if robotpy-ctre isn't installed.

Eventually, we need to support devices in a more general way.

With a standard xbox controller, the axes are as follows

0. Left Rotate
1. Left Move
2. Left Trigger
3. Right Trigger
4. Right Rotate
5. Right Move

However, on the simulator with pygame, the axes are as follows

0. Left Rotate
1. Left Move
2. Both Triggers
3. Both Triggers
4. nothing
5. crashes

pyflakes only detects things that are actually code errors (well... mostly), and it's pretty fast. Should add this in the future.

I think I would have it separate from the tests, as most of the things that pyflakes catches are things that are almost certainly errors.

Via @ArthurAllshire:

Also, it would be nice if the library could detect that you had already run the tests on a particular code base using a checksum, and then not run them again when you are deploying, or trying to run them again.

This is a bit complex if you really want to do it right, since you should probably hash imports et al. But probably doable.

I won't have time to get to this anytime soon, but it's a good idea.

Using pyfrc 2017.0.7
If the robot code utilizes multiple Pneumatics Control Modules, the simulator throws an exception when Solenoid objects are created, thinking the same ID resource has been used more than once. For example, if we have one PCM assigned to CAN ID 0 and a second one at CAN ID 2, this line will work:

solenoid1 = wpilib.Solenoid( moduleNumber = 0, channel = 0 )

But this will then throw an error:

solenoid2 = wpilib.Solenoid( moduleNumber = 2, channel = 0 )

The exception:

File "C:\Python34\Lib\site-packages\wpilib\solenoid.py", line 75, in __init__
  self._solenoidHandle = hal.initializeSolenoidPort(portHandle)
File "C:\Python34\Lib\site-packages\hal\functions.py", line 42, in outer
  raise HALError(getErrorMessage(status.value))

hal.exceptions.HALError: HAL: A resource is already allocated.

Deploying the same code to the robot works fine. Seems to be unique to the simulator.

An exception occurs at https://github.com/robotpy/robotpy-wpilib/blob/master/wpilib/wpilib/_impl/timertask.py#L32 because the delay period is negative.

Is evident in robotpy/robotpy-wpilib-utilities#10 -- but I've found that the example works on Linux without a problem, but fails (sometimes) on OSX 10.11. I presume there's a weird race condition that was introduced with #38?

@james-ward could you look at this maybe? I won't be able to do any robot stuff until Sunday/Monday.

This is the most common type of simplistic test one might want, I imagine. The primary usefulness I think would be exercising all your stuff, so you can be sure that they don't have syntax errors. Adding an additional function that gets called to check it is nice, but should be optional. Something like.. hm. I don't really know what this looks like. Maybe:

# port, button number?
release = (1, 1)
fire = (1,2)

# time, button to press (defaults to pressing for 0.2s)
tests = [
  (1.0, release),
  (2.0, fire),
  .. 
]

run_button_test(tests)

@sarosenb you should do this.

Or, perhaps tell them that they should run the builtin.

If you have multiple roborios and they have the same mDNS hostname, SSH will complain and won't allow the connection to succeed. The typical way one fixes this is sending the known hosts file to /dev/null.

Given we're using a default password, I don't think we care about MITM attacks.

File: pyfrc/lib/pyfrc/robotpy/installer.py

Code (line 366 through 379):

if not no_resolve:
    try:
        print("Looking up hostname", hostname, '...')
        addrs = socket.getaddrinfo(hostname, None)
    except socket.gaierror as e:
        raise Error("Could not find robot at %s" % hostname) from e

    # pick the first address that is sock_stream
    for _, t, _, _, (ip, _) in addrs: # <- Error on this line due to (ip, _) not working for IPv6
        if t == socket.SOCK_STREAM:
            print("-> Found %s at %s" % (hostname, ip))
            print()
            hostname = ip
            break 

The returned tuple from socket.getaddrinfo() is different depending on if it is IPv4 or IPv6 addresses.

socket.getaddrinfo() will return two differently formatted tuples, depending on if the address is IPv4 or IPv6:

IPv4: [(<AddressFamily.AF_INET: 2>, 0, 0, '', ('8.8.8.8', 0))]
IPv6: [(<AddressFamily.AF_INET6: 23>, 0, 0, '', ('2001:4860:4860::8888', 0, 0, 0))]

I do not currently have a system to test with, so this might not be the best way. I believe everything in the control system supports IPv6 since our RoboRIO was resolving with a IPv6 address. I'm not sure if the ssh supports IPv6 or what other implications there are, but the RoboRIO still had an IPv4 address associated with it:

socket.getaddrinfo('roborio-4901-frc.local', None) returns
[ (<AddressFamily.AF_INET6: 23>, 0, 0, '', ('fe80::280:2fff:fe17:3af1%8', 0, 0, 8)), (<AddressFamily.AF_INET: 2> 0, 0, '', ('129.252.23.54', 0)) ]

Per the Python socket.getaddrinfo() documentation:

The function returns a list of 5-tuples with the following structure:
(family, socktype, proto, canonname, sockaddr)

How about, instead of unpacking it like this:

for _, t, _, _, (ip, _) in addrs:
    if t == socket.SOCK_STREAM:
        print("-> Found %s at %s" % (hostname, ip))
        print()
        hostname = ip
        break 

You unpack it like this:

for _, t, _, _, sockaddr in addrs:
    if t == socket.SOCK_STREAM:
        print("-> Found %s at %s" % (hostname, sockaddr[0]))
        print()
        hostname = sockaddr[0]
        break 

If IPv4 doesn't work, you can check the first tuple element to see if it is an AF_INET or AF_INET6:

for family, t, _, _, sockaddr in addrs:
    if family == socket.AddressFamily.AF_INET and t == socket.SOCK_STREAM:
        print("-> Found %s at %s" % (hostname, sockaddr[0]))
        print()
        hostname = sockaddr[0]
        break 

Currently, the sim won't go above 4 axis. This makes it difficult to sim things like a tank drive using an Xbox controller, as these axis's map to 5 and up.

Working on this now.

The PIDController uses a TimerTask object which also calls Timer.delay which increments our fake_time timer while running. Since it is running on its own thread, how many calls it makes is indeterminate and if what you wanted to get done in that time is also indeterminate. I think this means that we shouldn't be doing tests on actual time or do something different if the object type is a timertask. I am not sure which action to do so wanted to have a short discussion.

The easiest cross-platform + cross-language interface is a web browser, so what we do is build a web server into a special version of WPILib (or perhaps in a secondary executable that pretends to be a gazebo server, depending on how it works out), and that web server updates its webpage dynamically depending on the state of the robot.

The UI would be written mostly using HTML/JS, so that the same functionality would be identical to use in Python, Java, and C++ robots.

Users could click on the web interface to activate various sensors, and things like motor output would be shown in the interface as well. Additionally, a field would be shown, and the robot could move around in 2d space based on the motor output (I already have the motion equations working for pyfrc).

I theorize that the primary usefulness that programmers will get from a simplistic simulator is "whether or not the thing moved when I told it to move". To enable this, the simulator has a library of simple animations that you can enable, and 'attach motors or sensors' to it, and the animation will move when your robot code makes it move. All of the animations would be written using HTML/javascript, and it would be trivial for users to add their own animations for more complex simulation. The types of motion that would be originally supported would be:

• Circular motion about an axis using a motor
• Solenoid piston action
• Linear motion using a motor

There are other types of motion that should be trivial to animate, but I still need more thought on this.

The primary advantage to this type of simulator is that it wouldn't require creating a precise CAD model of the robot to get started, and if the library of available animations is general enough, would take a user maybe a half hour to get setup and ready to test things.

The first implementation of the simulator would be in pyfrc, which is why that issue is here.

Some reordering happened because of changes since last year, you end up with an error like this:

23:46:18:645 ERROR   : robotpy             : Could not instantiate robot MyRobot!
Traceback (most recent call last):
  File "robotpy-wpilib/wpilib/wpilib/robotbase.py", line 159, in main
    robot = robot_cls()
  File "robotpy-wpilib/wpilib/wpilib/robotbase.py", line 44, in __init__
    NetworkTables.setNetworkIdentity("Robot")
  File "pynetworktables/networktables/networktables.py", line 304, in setNetworkIdentity
    cls._checkInit()
  File "pynetworktables/networktables/networktables.py", line 129, in _checkInit
    raise RuntimeError("Network tables has already been initialized")
RuntimeError: Network tables has already been initialized

Should look at fixing it for 2018, as it's a bit annoying. Here's a workaround for anyone who has a physics module and needs to use NetworkTables:

    @property    
    def nt(self):
        try:
            return self._nt
        except AttributeError:
            self._nt = NetworkTable.getTable('/')
            return self._nt

I've observed that many robots will not turn until given a certain amount of power, due to friction related to the drivetrain. This also happens with forward/backwards motion as well. It would be useful for the simulation to be able to model this easily.

Not sure what's going on yet, but deploy is failing on one of our RoboRIOs.

Hi, I'm on Team 5045 and we used (and really enjoyed!) RobotPy last year. I upgraded my Mac to 10.11 (possibly related?) a week or so ago, and suddenly I have started running into an error when attempting to deploy code to the robot.

$ python3 robot.py deploy --skip-tests
15:30:26:383 INFO    : wpilib              : WPILib version 2015.0.15
15:30:26:384 INFO    : wpilib              : HAL base version 2015.0.15; sim platform version 2015.0.15
Deploying to robot at 10.50.45.2
NI Linux Real-Time (run mode)

Log in with your NI-Auth credentials.

WPILib version on robot is 2015.0.15
NI Linux Real-Time (run mode)

Log in with your NI-Auth credentials.

sftp> mkdir "/home/lvuser/py"
sftp> put -r "/var/folders/02/b5qrvn193_33457rk8dh0b9r0000gn/T/tmpc6w1yugj/py" "/home/lvuser"
Entering /var/folders/02/b5qrvn193_33457rk8dh0b9r0000gn/T/tmpc6w1yugj/py/
hm 1
ERROR: Command ['/usr/bin/sftp', '-oBatchMode=no', '-oStrictHostKeyChecking=no', '-oUserKnownHostsFile=/dev/null', '-b', '/var/folders/02/b5qrvn193_33457rk8dh0b9r0000gn/T/tmpw6kumwwm', '[email protected]'] returned non-zero error status 1

I tried to figure out what was going on but really couldn't seem to find anything. I can ssh into to the robot just fine. I added something logging to the ssh_exec_pass method (printing after each data = _read(pty_fd)):

$ python3 robot.py deploy --skip-tests
15:39:52:883 INFO    : wpilib              : WPILib version 2015.0.15
15:39:52:883 INFO    : wpilib              : HAL base version 2015.0.15; sim platform version 2015.0.15
Deploying to robot at 10.50.45.2
1 None
2 None
3 b"Warning: Permanently added '10.50.45.2' (ECDSA) to the list of known hosts.\r\n"
1 None
2 None
3 b'NI Linux Real-Time (run mode)\n\nLog in with your NI-Auth credentials.\n\n'
NI Linux Real-Time (run mode)

Log in with your NI-Auth credentials.

1 None
2 b'WPILib version on robot is 2015.0.15\n'
WPILib version on robot is 2015.0.15
3 None
1 b''
2 b''
3 b''
1 None
2 None
3 b"Warning: Permanently added '10.50.45.2' (ECDSA) to the list of known hosts.\r\n"
1 None
2 None
3 b'NI Linux Real-Time (run mode)\n\nLog in with your NI-Auth credentials.\n\n'
NI Linux Real-Time (run mode)

Log in with your NI-Auth credentials.

1 None
2 b'sftp> mkdir "/home/lvuser/py"\n'
sftp> mkdir "/home/lvuser/py"
3 None
1 None
2 b'sftp> put -r "/var/folders/02/b5qrvn193_33457rk8dh0b9r0000gn/T/tmpdquo6x2f/py" "/home/lvuser"\n'
sftp> put -r "/var/folders/02/b5qrvn193_33457rk8dh0b9r0000gn/T/tmpdquo6x2f/py" "/home/lvuser"
3 None
1 None
2 b'Entering /var/folders/02/b5qrvn193_33457rk8dh0b9r0000gn/T/tmpdquo6x2f/py/\n'
Entering /var/folders/02/b5qrvn193_33457rk8dh0b9r0000gn/T/tmpdquo6x2f/py/
3 None
1 None
2 b''
3 b''
1 b''
2 None
3 None
sftp 1 bytearray(b'')
hm 1
ERROR: Command ['/usr/bin/sftp', '-oBatchMode=no', '-oStrictHostKeyChecking=no', '-oUserKnownHostsFile=/dev/null', '-b', '/var/folders/02/b5qrvn193_33457rk8dh0b9r0000gn/T/tmpdgwnjzio', '[email protected]'] returned non-zero error status 1

It looks like somehow the sftp operation is hanging after entering the directory on the local machine? I don't know how to resolve this, but wondering if someone else on OSX 10.11 may able to replicate? Maybe a protocol mismatch or something between what's installed on the RoboRIO vs my machine?

Any ideas? We're in a tough spot as we're scheduled for a demo on Friday and right now the robot isn't operational. Any help would be much appreciated.

Cheers,
Theo & Team 5045

If a CANTalon is a static member of a robot class (ie like the way subsystems are declared in command based robots), tests will fail in the teardown due to an index error.
For example:

import wpilib

class TrivialRobot(wpilib.IterativeRobot):
    motor = wpilib.CANTalon(1)

if __name__ == "__main__":
    wpilib.run(TrivialRobot)

Running python3 robot.py test --builtin results in:

handle = <hal_impl.types.TalonSRX object at 0x7fe70d533240>

    def c_TalonSRX_Destroy(handle):
>       del hal_data['CAN'][handle.id]
E       KeyError: 1

Suspect it's overhead related to hal-sim, will have to check it out with a profiler.

Need to fix it at some point, but this will probably come later in the season unless someone else does it.

TODO: Need to see what changes are needed

Also update the deploy documentation.

For some reason, the deploy command doesn't seem to work on a specific windows 8 pyfrc install I'm using.

This line right here https://github.com/robotpy/pyfrc/blob/master/lib/pyfrc/mains/cli_deploy.py#L102
only works when it's changed to controller.sftp(tmp_dir, deploy_dir)

This is weird, and might be a side effect of different dev tools on windows?

It also might be localized to that machine; I'll do further testing if needed.

To test this, all you need to do is add a time.sleep(0.01) to the end of update_sim in one of the physics.py examples. The result is a flickering pyfrc ui and lots of "Robot Drive... output not updated often enough"

In my tests with a roboRIO, there are usually two scenarios for deploy-

1. The robot code deploys pretty much fluidly, takes about 2seconds
2. The robot code will hang for about 15seconds between

Deploying to robot at: [hostname]

and

WPILib version on the robot is 2016.0.0

I've narrowed it down to the line (in cli_deploy.py)

controller.ssh(sshcmd)

Looking at that code, for Windows all it does is call plink.exe with the desired args (lest I am to be mistaken)

Firstly, is there any degree of reproducability to this issue? It may very well be a Windows-specific issue. I do not believe it to be a computer-specific issue because both my personal Windows 10 laptop and the team's Windows 7 laptops share the same issue.

Secondly, there is this comment before the ssh function

    # This sucks. We should be using paramiko here... 

I'm not well versed in ssh communcations... Is this something that can be changed quickly by another developer or should I find the time in changing it over? (tests are going quite well, I have a decent bit of down time)

    self.arm_angle_sensor = wpilib.AnalogInput(4)

is in my code, but no analog input is shown on port 4

Running python robot.py coverage test does not cover many important methods, such as robot.AutonomousInit(), robot.TeleopInit(), and the execute() method of commands that are the defaults of subsystems, although their __init__() methods are called.

../../../../lib/pyfrc/tests/basic.py:32: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
../../../../lib/pyfrc/test_support/controller.py:148: in run_test
    self._robot.startCompetition()
/home/travis/virtualenv/python3.6.0/lib/python3.6/site-packages/wpilib/samplerobot.py:142: in startCompetition
    self.disabled()
robot.py:48: in disabled
    wpilib.Timer.delay(0.010)
/home/travis/virtualenv/python3.6.0/lib/python3.6/site-packages/wpilib/timer.py:74: in delay
    hal.sleep(seconds)
/home/travis/virtualenv/python3.6.0/lib/python3.6/site-packages/hal_impl/functions.py:98: in sleep
    hooks.delaySeconds(s)
../../../../lib/pyfrc/test_support/pyfrc_fake_hooks.py:24: in delaySeconds
    self.fake_time.increment_time_by(s)
../../../../lib/pyfrc/test_support/fake_time.py:207: in increment_time_by
    self._wake_children(time)
../../../../lib/pyfrc/test_support/fake_time.py:89: in _wake_children
    for thread, thread_info in self._child_threads.items():
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
self = <WeakKeyDictionary at 0x7fbf1e337f28>
    def items(self):
        with _IterationGuard(self):
>           for wr, value in self.data.items():
E           RuntimeError: dictionary changed size during iteration

Observed in https://travis-ci.org/robotpy/pyfrc/jobs/189867877

This would be really useful for getting people started with physics engine support.

With the latest version on pip robot tests are failing with 9 errors for me, all related to NetworkTables. This commit should fix it, but the pip version hasn't been updated.

Mostly the errors are are:
AttributeError: type object 'NetworkTable' has no attribute '_staticProvider'

RuntimeError: Network tables has already been initialized

The physics subsystem here could be improved, and I think it would be beneficial to allow access to physics.py from within user robot code. However, physics.py relies upon the physics functions bundled with pyfrc, and won't run on a robot. I would like to split those methods out of pyfrc and build an improved physics engine in robotpy-wpilib-utilities.

Thoughts?

It appears to be related to resizing of the simulation screen when CAN encoder values fluctuate.

Will require an update to the RobotPy installer too.

Not what I expected. Presumably because that's the drawing's coordinate system. I suppose it should be documented or changed to be 'normal'.

The "error" messages that aren't error messages are confusing users.

pyfrc 2015.0.x installed robot programs using the 'admin' user, which caused problems when trying to run Java programs and Python programs at RoboRIO startup.

the trigger AS WELL AS button 0 in code link to button 2 on the sim, and button 1 is button 3 on the sim and so on.

Looks like FIRST is deploying netconsole-host at deploy, instead of depending on the one with the image to be up to date.

wpilibsuite/allwpilib@e614217

Under hal_impl\function.py, line 237:
axes.axes = [_axes_list[int(a_128)+128] for a in hal_data['joysticks'][joystickNum]['axes']]
If a is equal to 1.0, _axes_list index will go out of range (int(1.0_128)+128) equals 256, but range of _axes_list only goes up to 255.

To fix, change both 128 scalar and offset to 127.5.
axes.axes = [_axes_list[int(a*127.5+127.5)] for a in hal_data['joysticks'][joystickNum]['axes']]

My thought is that it would be nice to graph the various outputs/inputs of the simulator in a real time fashion.

Originally I was thinking matplotlib -- but now because of #6, it might be different. It still could be matplotlib, as the output could be streamed to a web interface.

Just need to extract the relevant installer bits and put them in here.

In my experience, running python3 robot.py test had the tests run in about 1-3 seconds, yet when running python3 robot.py deploy the tests took >10 seconds reliably

If the NetworkTable update callback calls a time related function, it will recurse because increment time will continually get called.

This will ensure (according to man page: Persistence guarantees vary per system) that the deployed files get written to disk before a poweroff event.

The PhysicsInterface.get_position function does not actually return position, because the values passed to _move are relative to the robot, and not relative to the field. Need to do some transform (but I'm tired and the math is escaping me at the moment) to the values so it'll be correct.

Of course, once those values are correct, then will need to adjust the simulation elements and such...

Quite unfortunate, really. However, thankfully logging output goes to netconsole, because of the way robotpy-wpilib has it configured.