The Rolling Spider does not send back its roll/pitch/yaw/altitude values to the controller, so you currently can not get them.
Are you talking about "requesting a picture to be taken", or "transferring a picture from the rolling spider to the controller" ?
Regardless, I've looked a bit inside your code, and I think that an explanation of the network protocol and the ARCommands encoding would help you change from "hardcoded constants" to a more flexible way:
Let's take your takeoff command:
new Buffer([0x02, ++this.steps.fa0b & 0xFF, 0x02, 0x00, 0x01, 0x00]), and strip it to the components:
0x02 --> Type of data (0x02 means "non acknowledged data"). In ARFreeFlight, we send the takeoff as an acknowledged command (type 0x04)
second byte is a per-characteristic sequence number
0x02 0x00 0x01 0x00 --> The ARCommand
This is slightly different from the UDP protocol (described here), because we do not code the buffer ID (as we use one characteristic per buffer) nor the data size (useless since we do not multiplex multiple messages into one packet on BLE).
An ARCommand is coded in the following way:
1 byte for the project identifier (
0x02 is for Rolling Spider, named MiniDrone in ARCommands)
1 byte for the command class identifier (The class
0x00 in project Rolling Spider is Piloting)
2 bytes for the command identifier (The command
0x0001 in class RollingSpider.Piloting is TakeOff). The "backwards" notation is due to the endianness.
N bytes of data (all arguments to the command), packed.
The ARCommands are described in those Xml files. Each .xml file represent a project (first byte), in each file, there are a number of class (second byte), each with a given id. In each class, the commands identifiers are "in order" from the file (i.e. the first command of a class has id 0, the second id 1 ...)
When built, the libARCommands generate a private (will be public in future releases) file with multiple C enum definitions for each project, class, and command ids. You can find an example of the file here. For the MiniDrone.Piloting.TakeOff command, we can see that:
ARCOMMANDS_ID_PROJECT_MINIDRONE has the value
ARCOMMANDS_ID_MINIDRONE_CLASS_PILOTING has the value
ARCOMMANDS_ID_MINIDRONE_PILOTING_CMD_TAKEOFF has the value
And so the command is
[0x02 0x00 0x01 0x00]
Using the same method, we can find that a MiniDrone.Animations.Flip(left) command is coded as
[0x02 0x04 0x00 0x00 0x03 0x00 0x00 0x00]:
0x02 for the MiniDrone (Rolling Spider) project,
0x04 for the Animations class,
0x00 0x00 for the Flip command, and then
0x03 0x00 0x00 0x00 for the 3rd entry of the direction enum (enums are coded as unsigned 32bits values in ARCommands), which is "Left"