Joystick and Push Buttons

[zeta_5416]

Firstly, I am aware that there have been numerous posts about the joystick on these Forums. My query is different; I am not interested in utilising pygame for my purposes. A few questions:

Question 2: Is the joystick guaranteed to be bound to /dev/input/event0?
Question 3: How will the push buttons be accessible, if at all? If they are, is it possible to emulate their functionality; if so, how?
Question 5: Will the push buttons have default actions? If so, what actions are these, can said actions be overridden, and how?
Question 7: Will the Pi(s) designated to go into space log in automatically? Will the winning entry scipts be run on login, and how? .bashrc entry, .profile entry, cron job, or something else?

[zeta_5416]

Update:

Question 2: It appears that on the flight hardware, the joystick is inaccessible (having been replaced by GP push buttons instead). This question is no longer relavent.
Question 3: Approximately two hours after posting this, I received a link to this page in the Astro Pi newsletter. Said page answers this question fully.
Question 5: There appear to be six general purpose push buttons, and two others. The GP push buttons one programs oneself, but it would be nice to know the purpose of the others.
Question 7: As of yet, unresolved.

[Davespice]

The joystick and the push buttons are separate and both will be present on the flight hardware.
You can program both of these in any way you like. There is no plan to connect a keyboard or mouse to the Astro Pi on orbit which should guarantee that /dev/input/event0 will be the HAT joystick.

The push buttons will have some default actions but this will only be for reboot and shutdown when Tim holds a button for 3 seconds. Reboot will be button B (bottom pair, right), Shutdown is DOWN, top quad bottom.

The scripts will be run automatically and will start from a command in /etc/rc.local
There will be a master control program that loops through all of the winning programs running them individually in turn, so when your code runs you'll have full access to the hardware and won't be simultaneously sharing it with another program.

[zeta_5416]

Thanks for the response.

The joystick and the push buttons are separate and both will be present on the flight hardware.

Present indeed, but wouldn't they be a little difficult to access under the monstrous metallic mass that is the case? Forgive me if I'm wrong, but I wouldn't imagine that the ISS crew would take kindly to removing the case so that the joystick could be accessed, due to the numerous sharp insides of the Pi...

The push buttons will have some default actions but this will only be for reboot and shutdown when Tim holds a button for 3 seconds. Reboot will be button B (bottom pair, right), Shutdown is DOWN, top quad bottom.

Will it be possible to override them, if said functionality is provided via some different route (perhaps a different key combination) in the script?

[Davespice]

I've attached a picture of the flight unit for clarity, the little red track-point cap is the joystick. The user will probably use their left thumb to move it. You won't be able to override the reboot/shutdown functionality from your code, that is being controlled at Kernel level. But if you wanted to assign different uses to those buttons that doesn't involve holding them down for three seconds then you'll be fine.

[zeta_5416]

I've attached a picture of the flight unit for clarity, the little red track-point cap is the joystick.

Ah, thanks much. I'd only seen the Pi in its flight case without the cap installed, and somehow had the notion of the Pi being in a position 90 degrees anti-clockwise from its actual position (hence covered by the case). My mistake.

You won't be able to override the reboot/shutdown functionality from your code, that is being controlled at Kernel level.

* Writes program which buffer-overflows, overwrites the kernel in memory, installs custom hobby OS in the place of Raspian, reboots into said OS, ignores warning... *

[Davespice]

* Writes program which buffer-overflows, overwrites the kernel in memory, installs custom hobby OS in the place of Raspian, reboots into said OS, ignores warning... *

Just remember we are going to triage all the code that is going on the flight SD cards and something like that is never going to slip through

[zeta_5416]

Just remember we are going to triage all the code that is going on the flight SD cards and something like that is never going to slip through

What about a script which dynamically generates itself after a given date (a.k.a. after the judging process has completed)? One could hide the OS binary or some bytecode deep down in .git/... I presume that you are giving the scripts sudo access because of the IMU sensors, so you should manage that carefully.

Granted, I don't have nearly enough time to throw something along those lines together (so I should probably not be browsing these Forums either), so you should be safe.

Next time, perhaps (presuming the eventuality of another such competition)...

[Davespice]

Every line of code and every binary file will be checked for every winner. There is no way anyone will get anything past us.
Don't underestimate the resources at the disposal of ESA and NASA

[jdb]

All the competition entries are to be in the Python language.

Each entry will be subject to code review - both for functionality and for ulterior motives.

If you can create an OS-level backdoor using Python, I'd have a lot of fun figuring out your exploit, seeing as how I get to poke and prod the source code for about 5 months before it has the chance of being deployed on-orbit.

[zeta_5416]

Don't underestimate the resources at the disposal of ESA and NASA

Fair point. I shouldn't imagine that they'd be particularly pleased if anything like that slipped through...

All the competition entries are to be in the Python language.

As quoted from the FAQ:

What programming language and version is required?
Python version 3.2 is the recommended programming language; version 2.7 is also acceptable. Bash shell scripts are also acceptable. If using C or C++, you must provide compiling instructions. Any programming language used must be compatible with the Raspberry Pi.

[jdb]

Fair enough. We expect almost all the entries submitted to be written in Python, as the ease-of-use API and examples have all been created in this language.

You're still free to submit a raw C code implementation, of course.

[zeta_5416]

the ease-of-use API

Certainly. I had almost considered writing mine in C++, and since the underlying RTIMUlib is written in C++ also, I would have access to the sensors - but I gave in and learnt Python instead. Haven't looked back. C/C++ is still my preferred language, but the high-level data structures in Python are extremely useful (and I did not wish to attempt to port the GPIO and PiCamera libraries, as I had not the time available to do so).

[Johnny5C]

I'm really looking forward to seeing your entry zeta!

[zeta_5416]

Thanks; it took quite some effort in the inordinately short amount of time I had to create it, but I managed to complete it nonetheless.

[Johnny5C]

Well done!