Alternate screen (and other) interfaces?

waveform80 commented 9 years ago

I've been playing around with the Sense HAT for a couple of days and wanted a slightly faster (and easier) means of updating the LEDs. I've come up with a few little classes that might be interesting:

one for the LEDs (SenseScreen) which mmaps a numpy array to give simple but fast coordinate based access to the LEDs
one for the joystick (SenseStick) which opens the event device directly so it only listens to the Sense HAT joystick, not the keyboard, and also works when you're working remotely on the Pi (provides events as an infinite iterable - might have a look at an event callback system for this)
one for the IMU (SenseOrientation) which provides IMU readings as an infinite iterable (or straight properties)

I was just wondering if there was any interest in including such an alternate interface in the sense_hat library? I could understand if there was a desire not to confuse the library with two ways of doing things but if there's any interest I could bung together a PR (if there's interest I'd add a couple more classes to deal with the pressure and humidity sensors)

davidhoness commented 8 years ago

Hi Dave Yeah I am in favor of this, however I'd like to keep the original main class for backwards compatibility but perhaps change its underlying implementations to consume internal instances of your new classes. That way the user has the choice of doing it the old way, or instantiating your classed directly and not using the main class.

That sound good? Dave

davidhoness commented 8 years ago

With the stick interface it might also be nice to have a toggle for ground / flight mode?

In ground mode the Sense HAT is used with the HDMI port facing down, in this orientation the keyboard driver events match the events used in the code. In flight mode though the Sense HAT is rotated through 90 degrees clockwise when installed in the Astro Pi flight case. This then makes the directions not match the keyboard driver events. Up becomes right for example.

It probably wouldn't be too much effort to have a toggle which just remaps some global copies of the events depending on the ground/flight mode. Maybe we could also tie it into the orientation of the LED matrix?

What do we think?

waveform80 commented 8 years ago

Hi Dave - sorry for the late reply! Absolutely agree on not breaking backward compatibility. My thoughts if integration with the main class were wanted were that we could simply make a read-only "stick" property on the the SenseHat class which is an instance of SenseStick. If that's okay, I can do another PR for that; one thing I'd also like to add to SenseStick is callback hooks akin to those we're developing on gpiozero (e.g. "when_moved" with a direction parameter, or possibly just separate events for "on_up", "on_down", etc.). Any thoughts on design welcome!

The main reason I've stuck with separate classes so far is that this provides the opportunity not to open stuff the developer doesn't want to use, and provides the ability to close and re-open things as necessary, but I agree it'd be nice to provide a choice so users can stick with the monolithic class if they wish.

On rotation - sounds good. I've already got a "rotate" property on my SenseScreen class - I could replicate that on SenseStick, but I'm guessing that in the case where SenseStick is instantiated as part of SenseHat it'd be nice for it to follow rotations set through set_rotation on the parent? That shouldn't be difficult to arrange (I can just tweak set_rotation to set stick.rotate at the same time).

I'll try and get to all this at the weekend, but I've got a bit to do on gpiozero and the picademy worksheets too so we'll see :)

davidhoness commented 8 years ago

@waveform80 @bennuttall

Over the weekend I realised that we might be causing ourselves problems in the future by allowing the API (currently in the wild) to deviate greatly from what is on the Astro Pi flight SD cards. I can't confirm this yet but Tim may wish to run interactive Astro Pi activities from orbit.

If that happens we don't want to create the situation where user code wouldn't work out of the box on the flight SD cards. Version 2.1.0 is what's on them and we don't have a means to update to a newer version.

We have a means of uploading python files only so we could package these new classes with any user code being uploaded as a workaround. However I need to check that Raspberry Pi will be in control of that upload process. If we're not and ESA is doing it all then it's going to be a headache to get them to patch the code in this way.

I will find out which way this will occur on the 15th of this month when I'm at EAC in Germany. In the meantime I don't want any new releases of this module. Happy for the code to go into the repo though.

waveform80 commented 8 years ago

Sure, no prob. Just let me know if you want me to push anything else - I'm pretty swamped with gpiozero and picademy at the moment anyway, so I doubt I'll be able to do much on sense hat this week.

davidhoness commented 8 years ago

Hi @waveform80, I've checked that RPi will be in control of the upload process so it's going to be safe to make additions to the API, we shouldn't change anything that would break backward compatibility though. Just add new functionality which we can then include as separate class files in any potential ISS upload.

astro-pi / python-sense-hat

Alternate screen (and other) interfaces? #10