Basic question freewater task

[neurodavidus]

Hi There,
After managing to have the basic blinking task working I wanted to try something a bit more complex. My plan was to understand the free water task but instead of solenoids and infrared beams simply turn on some LEDs and manually action a button to simulate a rodent behavior (something I can easily implement on a breadboard .
I was just looking at the task code and I am a bit confused.
In line 52 you are defining the Hardware Digital Inputs for left, center and right ports. But somehow I can't figure out how the status of these inputs (high or low) is used to control the opening on the solenoid.
Basically, I see line 151 where you turn on the LED of the selected port.
Is the magic of opening the port occurring in line 150? Is this something that should be configured when I add hardware on the configuration of the PI ?
thanks for helping
David

[neurodavidus]

Hi again,
I looked more carefully at the Hardware documentation section. Regarding my question above, my guess now is that the opening of the solenoid based on the DigitalInput state (high/low) is not coded in the task itself but in the hardware configuration of the solenoid. Correct? But I am still struggling to find how to set up this. I have to admit that the language in the hardware section is very technical and I am starting wondering wether I am not out of league here. I Will keep searching in the doc but some low-level help would be appreciated.

Another issue is time management in the task. In the task, I don't see how the poking times are saved relative to the lighting of the LED that indicates which port was randomly selected. I would like to understand this because I would like to know how to control solenoid opening depending on the delay between LED on and correct poke.

Overall my difficulty to understand how such a simple task is coded and run using Autopilot makes me feel that I don't get the big picture. Probably this is because my only experience with hardware control is with LabVIEW in which you can easily visualize the logic of the operation, how this logic is dependant on the passage of time since the beginning of the task. When I look at the Feewater.py code I feel lost .... I understand what is there but I feel some important aspects are not there. Any suggestions that could help me?
thanks a lot
David

[sneakers-the-rat]

Glad to hear you've gotten the blinking task working!!! Love your tenacity even if you feel a bit out of your element, as I'm sure I've said before, ironing out all the points of confusion, bad design, etc. is the ongoing development mission here, so eventually we can minimize that very legitimate feeling.

The way that the solenoid is triggered from the digital in is part of a general trigger handling method. When a digital_in object is created, it has some 'polarity' argument which defines the 'direction' of the logic --- ie. when polarity == 0, the pin is pulled low, and when the input goes to a high voltage (some switch was closed, say) it calls some 'callback' function, see assign_cb.

When the parent task instantiates the hardware objects at the beginning, it will assign its handle_trigger method as a callback, here. So whenever a logic change is detected whatever is set in the task's triggers dictionary for the given id will be called, here

What's happening on L150 of the task is preparing the trigger -- when the target Digital_In object is triggered, it will call the open method of the solenoid.

Should be no change if you wanted to use a button instead of a solenoid! both are Digital_In .

The way the task is written, the only timestamp that's saved is from when the trial starts, L156. If you want to vary the reward duration, what you could do is record the time that the trial starts in some attribute, eg. if on L152 you wrote self.start_timestamp = datetime.datetime.now(). And then, instead of having open called as a trigger immediately whenever the mouse responds (comment/delete L150), you change the response method to do something like this

def response(self):
    """
    Give reward proportional to delay, reset lights, and tell the Terminal the trial has ended
    """

    # get time of response
    response_time = datetime.datetime.now()

    # get total seconds elapsed from timestamp
    # stored in 'water' stage method
    dt = response_time - self.start_timestamp
    # convert timedelta to float, see
    # https://docs.python.org/3/library/datetime.html#datetime.timedelta.total_seconds
    dt = dt.total_seconds()
    # and then to milliseconds
    dt *= 1000

    # do some scaling operation (whatever you want to do here)
    # for example, if we want to have some linear decrease in 
    # reward duration from 50ms to 20ms over 1 second of delay...
    # (see https://numpy.org/doc/stable/reference/generated/numpy.clip.html)
    reward_dur = np.clip(
        50 - 30*(dt/1000), 
        20, 50
    )

    # then use the 'open' method of the solenoid with the duration
    # as the argument
    # note the similarity to L150
    self.hardware['PORTS'][self.target].open(reward_dur)

    # mebs also turn the light off rl quick
    self.set_leds()

    return {'TRIAL_END':True}

I think if it's hard to understand then that's my fault! Some of the difficulty comes from how a lot of Autopilot happens concurrently, so linear flow of time is a bit harder to think about -- eg. rather than having trial start -> delay -> reward start -> delay -> reward end, the trial start and prepares as much as it can for the next stage, then all the triggers/etc. like reward happen in parallel to the computation of the next stage (in this case just turning the lights off and ending the trial).

I would love to hear any places in particular in the docs that are hard to understand, feel free to call me out line-by-line like "what does this mean???!!" or places you think need clearer explanations -- very helpful to me. I'll do the best I can to flesh out the docs and fix bugs as you encounter them, but I am but one grad student who is currently writing their dissertation at the moment, just to note my limitations.

Hopefully that helps, let me know if you have further questions :)

[sneakers-the-rat]

The way that calibrations mapping duration to volume work for the solenoid class is pretty ugly, see the dur_from_vol method on the solenoid class. prefs loads some json file with fit calibration parameters, (obtained from calibrate_port),

so if you wanted to open by volume rather than duration, you would use the calibration routine in the terminal (tools menu -> calibrate water ports), and then you could do something like

volume = 20 #mL
solenoid.open(solenoid.dur_from_vol(volume))

sigh i wonder if this is how all people who develop software feel, wanting to constantly rewrite the whole library, or if it's jusåt a 'first library' feeling where I've learned basically everything I know in building the first draft of it, but now that entire first draft needs to be rewritten :p

[sneakers-the-rat]

I've drafted a generalized way of defining calibrations over on this branch, which i'll be merging as soon as i finish the work on it:

https://docs.auto-pi-lot.com/en/parallax/autopilot.hardware.html#autopilot.hardware.Hardware.calibration

[neurodavidus]

Thanks Jonny! It will take me some time to digest all of the above and put it into practice but your first answer is already helping a lot ! I'll get back to you as soon as I have had more time to play with my breadboard and fake task ...best. David

[mnmneE]

Hi,
I read the thread which is pretty informative,
yet I have one question if I need to define a pushbutton in the hardware then it will be under Digital_In class (the base is 'autopilot.hardware.gpio.GPIO'), right?, through the discussion, it is mentioned that the solenoid will be as a pushbutton Digital_In objects but in the documentation, a solenoid is a Digital_Out object! thanks in advance

[sneakers-the-rat]

Sorry @Modarmalla just seeing this! Thanks for raising this question. could you point me to where in the docs you're seeing this? I want to correct any ambiguity/incorrectness.

Solenoids should be Digital_Out or their own Solenoid class. The Digital_Out class is the general-purpose output-over-GPIO class, and the Solenoid class just adds some additional logic and syntax to calibrate opening durations to release a specific volume of fluid rather than open for a specific duration (it's just a LUT that I realize is only documented in a distributed way in the API docs and really needs to be reimplemented, but let me know if you'd like to use it!)

A digital button should be a Digital_In object!