request for example prefs.json file

[Luke Sjulson]

I was wondering: does anyone have an example of a prefs.json file that works with the sample protocols, such as the free_water one? I am trying to configure my hardware so it will work, but the reward ports seem to need to be classified as "PORTS" instead of simple GPIO outputs, and I haven't been able to automatically generate a prefs.json file with the setup script that works correctly.

thanks!

Luke

[jlsaun...@gmail.com]

Aha! Yes. Sample prefs at the bottom & attached

The hardware parameterization in prefs has two levels: a "group" (eg. FLAGS, LEDS) and then a "name" - an LED named "C" for a center LED. The "group" part is intended to be flexible, because, for example, a task might want to turn all LEDs in the nosepoke off after a trial ends, but there might be an additional LED that's being used as an arena light that we don't want to turn off -- we still want to be able to write a method that iterates through hardware['LEDS'] but not *all* the LEDs in the system. The name of the hardware type is used by default when first instantiating.

So the 'group' tags are intended to be edited to match the requirements of a task -- the task says it needs 3 solenoids in the 'PORTS' group, so eg. if one was replicating someone else's experiments you would configure your solenoids however they needed to be and put them in that group.

The automatic generation of hardware prefs is relatively new (in early summer?) and I haven't been in the lab doing extensive testing during that time, so haven't had much time to sculpt that process -- prefs is sort of intended to be worked on as text, but I do also want to expose that to the GUI once that code gets refactored.

It's a design tradeoff that I think still could be made more elegant -- and especially could do with some better documentation (opened an issue to keep track of that here: https://github.com/wehr-lab/autopilot/issues/38 . I could also see a 'group' being an attribute or parameter and having the prefs structure being more uniform/predictable by having parts nested under their class name (as is default), which would sort of imply also flattening out the 'name' nesting level. Benefits to both I think.

You may also notice two types of hardware parameterization below, some hardware objects are parameterized with dictionaries, and others just have a single value -- in init_hardware (a monster of a method that needs to be split up: https://github.com/wehr-lab/autopilot/blob/01543a9708d4bf06c74dc6af6fc7e8917331fc98/autopilot/tasks/task.py#L121), if a dict is not given, the value is just given as the first argument, as many GPIO devices can be parameterized with just a pin number.

{
    "AGENT": "PILOT",
    "AUDIOSERVER": true,
    "BASEDIR": "/home/pi/autopilot",
    "CHILDID": "",
    "CONFIG": "",
    "DATADIR": "/home/pi/autopilot/data",
    "FS": 192000,
    "HARDWARE": {
        "FLAGS": {
            "L": "",
            "R": ""
        },
        "LASERS": {
            "LR": {
                "name": "LASER_LR",
                "pin": 36
            }
        },
        "LEDS": {
            "C": {
                "pins": [
                    22,
                    18,
                    16
                ],
                "polarity": 0
            },
            "L": {
                "pins": [
                    11,
                    13,
                    15
                ],
                "polarity": 0
            },
            "R": {
                "pins": [
                    19,
                    21,
                    23
                ],
                "polarity": 0
            },
            "TOP": {
                "name": "LED_TOP",
                "pin": 32
            }
        },
        "POKES": {
            "C": {
                "pin": 8,
                "polarity": 0
            },
            "L": {
                "pin": 24,
                "polarity": 0
            },
            "R": {
                "pin": 10,
                "polarity": 0
            }
        },
        "PORTS": {
            "C": 33,
            "L": 31,
            "R": 37
        }
    },
    "JACKDSTRING": "jackd -P75 -p16 -t2000 -dalsa -dhw:sndrpihifiberry -P -rfs -n3 -s &",
    "LINEAGE": "NONE",
    "LOGDIR": "/home/pi/autopilot/logs",
    "LOGLEVEL": "DEBUG",
    "MSGPORT": 5565,
    "NAME": "pilot_2",
    "NCHANNELS": 1,
    "OUTCHANNELS": [
        1
    ],
    "PARENTID": "",
    "PARENTIP": "",
    "PARENTPORT": "",
    "PIGPIOARGS": "-t 0 -l",
    "PIGPIOMASK": 1111110000111111111111110000,
    "PROTOCOLDIR": "/home/pi/autopilot/protocols",
    "PULLDOWNS": "",
    "PULLUPS": [
        7
    ],
    "PUSHPORT": 5560,
    "REPODIR": "/home/pi/git/autopilot",
    "SOUNDDIR": "/home/pi/autopilot/sounds",
    "TERMINALIP": "192.168.0.100",
    "VENV": "/home/pi/git/autopilot/venv",
    "VIZDIR": "/home/pi/autopilot/viz"
}

[jlsaun...@gmail.com]

just finished nmc talk, need a bit of a weekend but i should be able to catch up on some documentation next week :)

[Luke Sjulson]

Perfect, thanks for the quick reply! I hope your talk went well - I wanted to see it but couldn't make it.

Luke

[jlsaun...@gmail.com]

issue 38 has been closed (profanity warning because it is late and i have been looking at tiny text all dayu!!!!!%!%!%!!%!%!) https://github.com/wehr-lab/autopilot/issues/38