Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add heading, pitch, roll, and altitude data to the Network Survey Device Status message #50

Open
abitwired opened this issue Aug 14, 2024 · 3 comments

Comments

@abitwired
Copy link

Describe the solution you'd like
The Network Survey Messaging API Device Status Message supports heading, pitch, roll, and altitude data. I think it would be neat to use the phone's accelerometer and other hardware to provide these data types as a part of the Android application. Using the Motion Sensor's API to retrieve the phone orientation and then the Location Provider to retrieve altitude data. Including these data types alongside the existing GPS information in the Device Status message would improve mapping tools that consume the Network Survey data.

Describe alternatives you've considered
I can't think of alternatives to achieve this functionality outside of implementing a different app that uses the Network Survey Messaging API to forward those data types to the same MQTT broker on the same topic.

Additional context
The main use-case for this kind of data is being able to display a user's location and elevation (e.g., roughly showing that someone is on the 10th floor of a building or climbing in altitude on a plane). In addition, Android devices on things like drones, planes, etc. could make use of the 6DoF data for displaying their orientation.

@abitwired abitwired changed the title Add headig, pitch, roll, and altitude data to the Network Survey Device Status message Add heading, pitch, roll, and altitude data to the Network Survey Device Status message Aug 14, 2024
@christianrowlands
Copy link
Owner

Thank you for the suggestion.

I sort of like the idea of creating a new message type specifically for the Android motion sensors and maybe even the environment sensors. I am thinking there could be a setting to control if this message is sent along with the device status.

@abitwired
Copy link
Author

I think the setting to control that data should be included. Personally, I'm neutral about the new message type. It could be separate from the Device Status message. I think additional environment sensors would be neat since Android devices are capable of more than the accelerometer sensors I mentioned (e.g., temperature, light, heart rate, pressure, etc.). There may be some additional extensibility to the Android OS in the future that Network Survey could support. For example, possible service discovery of external USB-C devices as new "sensors" which are published on the Network Survey Message API.

@christianrowlands
Copy link
Owner

I have been thinking more about this one, and I have a couple thoughts.

  1. You mention the main use case that you want to display the devices location and elevation. The altitude is already included in the device status message (and all the messages). This would give you the information if a device is in a several story building or climbing in altitude in a plane. Does altitude alone cover your use case here? As for NS on a drone, you could at least display the heading of the drone similar to how Google maps does it where they compare the last few points to see if the device is heading a specific direction, and then update the icon accordingly to reflect the heading.

  2. I bring all of this up because I am worried publishing device motion sensor and environment sensor data is a step too far outside the core purpose of Network Survey. I am sensitive about keeping things in focus because I have been a part of frankenstein software projects before that did not stay focused and it caused their downfall. It does feel like one small step outward to include some extra sensor data, and survey data collection is the core purpose of NS, so maybe I am over sensitive here. I am still on the fence about this, but if your use case is covered by the already included altitude then I think we should stop there until a use case for the other data arises.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants