Hi all.
My hardware adventures continue....I now have a working heading indicator, a blue LED for when the landing gear is raised, a red LED for when the landing gear is down, a set of alternating flashing yellow LEDs for when the gear is moving, and importantly, an illuminated LED switch to raise and lower the gear (basically what F6 does, but it doesn't try and fake an F6 button press). It even displays correctly when the autopilot takes over which my kids think is very cool. Boast over. :-)
This has all got me thinking about a proper helm/navigation panel together with all of the possible controls (and there are lots). In particular I thought about all the heading and elevation values we might be interested in. Heading and elevation it simulates the compass heading and pitch in relation to the nearest space station (which does some weird stuff given it is not spherical) or celestial body as the frame of reference. However when you target something, I notice that there is no relative bearing and elevation to the target displayed. You get nav tunnels and relative speed to target, so the calculated information must be there. Just wondering if it is not displayed on purpose.
Further I thought it would a cool idea to get the relative heading and elevation of a targeted vessel (so you at least know if he is pointed in your direction). For example, if the ship were directly in front of you, he would be bearing 000 at 00 elevation. If he were below you and to the right a bit, he could be at bearing 030 and -20 elevation. Similarly, if he were pointed in the exact same direction as you are, his relative heading would be 000 at 00 elevation. Pointed directly at you, but a bit above your head his relative heading is 180 at +10 elevation. That sort of thing. You could then do a little course projection maybe. Just thinking out loud. This might be getting a little too technical to fly, but I've always wanted to sail a ship in space, not do the top gun thing. A little to much Star Trek in me maybe....
Opinions?
Hardware adventure: Targeted ship information
Re: Targeted ship information
You really have to post pictures of your progress. You've made me curious.
Also, it would be cool if we could incorporate this into the game source. Maybe a compiler option, if the code isn't too horrible?
Also, it would be cool if we could incorporate this into the game source. Maybe a compiler option, if the code isn't too horrible?
Re: Targeted ship information
Hi impaktor. I'll go one better with a little bit of video to show off what I have done thus far: https://youtu.be/fkiyDU_Mrsc
It is just an experiment to see what I can do as far as input and output to the arduino and displays/buttons and to the lua scripts. Have a look and feel free to comment. I have a couple of videos that I'm swapping between, trying to figure out what I like as the final product vs cost & difficulty. They are:
https://www.youtube.com/watch?v=NMPYxAZ-jiY and https://www.youtube.com/watch?v=DUb0mSmViCQ
As for the code, well I have tried to keep it as contained as possible. There are some new classes SerialClass and LuaSerialComms which handle the actual communications to and from the Lua scripts and the Arduino. This all uses the USB COM3 Serial interface. There are little mods in the Pi class, where I have to initialise the connection, initialise the Lua methods, keep poll for and read commands from the COM3, and keep a state of the inputs and outputs so that (a) we minimise the commands sent to COM3 (eg, only when the heading value actually changes), and (b) so that the Lua code only needs to poll a static variable in the Pi class, and not go all the way to Arduino to know when a button is being pressed. Other than that the Lua code has small additions to game.lua (function displayReticulePitchHorizonCompass) and fx-window.lua (function button_wheelstate). Commands are passed back and forth and strings terminated with a tilde ~ So lgu~ is sent to Arduino by lua scripts when the wheel state is up which makes the red led light (and turns the others off). On the other side, when the landing gear button on the Arduino is pressed then lgd~ is sent to the computer and it notes that the button is down. When the button is released, then the Arduino sends lgu~ to the computer. It notes that too, but also notes that this is the trigger for a landing gear change of state, and sets a boolean "unhandledLandingGearEvent" to true. The Lua script will check for that at the same time as it checks for an F6 or the icon click, and does the landing gear thing. I don't try and simulate a mouse click or a keypress. It all works with the autopilot as well, so when it autoextends the gear for landing, the Arduino gets the message and does it's thing too. The heading commands are like hd123~ hd124~ etc.
The way I have done it could be vastly improved in both hardware, hardware code, and c++ implementation. It's not too responsive and I think I could move some of the code to the arduino (in terms of detecting landing gear triggers, and remove some code from c++ so as to not pollute it as much. I will push it to my git repository soon, so you can have a look, just as soon as I am happy with the basic architecture. We can then look at putting guards around the code with a compiler switch if you deem it worthy of inclusion into the master build. For now, it's just a hobby keeping me out of trouble.
It is just an experiment to see what I can do as far as input and output to the arduino and displays/buttons and to the lua scripts. Have a look and feel free to comment. I have a couple of videos that I'm swapping between, trying to figure out what I like as the final product vs cost & difficulty. They are:
https://www.youtube.com/watch?v=NMPYxAZ-jiY and https://www.youtube.com/watch?v=DUb0mSmViCQ
As for the code, well I have tried to keep it as contained as possible. There are some new classes SerialClass and LuaSerialComms which handle the actual communications to and from the Lua scripts and the Arduino. This all uses the USB COM3 Serial interface. There are little mods in the Pi class, where I have to initialise the connection, initialise the Lua methods, keep poll for and read commands from the COM3, and keep a state of the inputs and outputs so that (a) we minimise the commands sent to COM3 (eg, only when the heading value actually changes), and (b) so that the Lua code only needs to poll a static variable in the Pi class, and not go all the way to Arduino to know when a button is being pressed. Other than that the Lua code has small additions to game.lua (function displayReticulePitchHorizonCompass) and fx-window.lua (function button_wheelstate). Commands are passed back and forth and strings terminated with a tilde ~ So lgu~ is sent to Arduino by lua scripts when the wheel state is up which makes the red led light (and turns the others off). On the other side, when the landing gear button on the Arduino is pressed then lgd~ is sent to the computer and it notes that the button is down. When the button is released, then the Arduino sends lgu~ to the computer. It notes that too, but also notes that this is the trigger for a landing gear change of state, and sets a boolean "unhandledLandingGearEvent" to true. The Lua script will check for that at the same time as it checks for an F6 or the icon click, and does the landing gear thing. I don't try and simulate a mouse click or a keypress. It all works with the autopilot as well, so when it autoextends the gear for landing, the Arduino gets the message and does it's thing too. The heading commands are like hd123~ hd124~ etc.
The way I have done it could be vastly improved in both hardware, hardware code, and c++ implementation. It's not too responsive and I think I could move some of the code to the arduino (in terms of detecting landing gear triggers, and remove some code from c++ so as to not pollute it as much. I will push it to my git repository soon, so you can have a look, just as soon as I am happy with the basic architecture. We can then look at putting guards around the code with a compiler switch if you deem it worthy of inclusion into the master build. For now, it's just a hobby keeping me out of trouble.
Re: Targeted ship information
That looks great!
Re: Targeted ship information
Well, I haven't put a compiler option in there. I'm not sure that there would be a point given that it wouldn't apply to the Lua code changes, but I have restructured the serial interface code so that it has minimal impact on the Pi class. Everything else (other than some small additions to ShipController to incorporate the Serial thumbjoystick) is contained in separate classes (SerialComms, SerialInterface, and LuaSerialComms).
To the developers out there, if you thought it is worthy of inclusion to the main source, I wouldn't object. Has there been anyone else in the forum who was looking to make Arduino based flight controls for Pioneer? In any case, I/O in both directions using COM3 is stable and seemingly bug free, but a review would be welcome. Not sure how to formally request one. I have merged from upstream to get the new UI updates in the August build so if you compared https://github.com/kennworl/pioneer.git to the main source, the differences should stick out.
Forgot to mention that I have now wired up a thumb joystick for pitch and yaw which works great. My next experiment is to take some of the ship readouts (hull integrity, temp, lat/long, etc) and display them on a little 320x240 pixel resistive touchscreen display (which will double as a keypad for setting ship speed and various other things). I am trying to do away with the keyboard for the most part. I am also starting to design an A3 size panel for all Helm, Nav, and Tactical controls. Though I might take a break from that and look at doing a couple of the UI updates that nozmajner has mentioned in the issue tracker #4078.
To the developers out there, if you thought it is worthy of inclusion to the main source, I wouldn't object. Has there been anyone else in the forum who was looking to make Arduino based flight controls for Pioneer? In any case, I/O in both directions using COM3 is stable and seemingly bug free, but a review would be welcome. Not sure how to formally request one. I have merged from upstream to get the new UI updates in the August build so if you compared https://github.com/kennworl/pioneer.git to the main source, the differences should stick out.
Forgot to mention that I have now wired up a thumb joystick for pitch and yaw which works great. My next experiment is to take some of the ship readouts (hull integrity, temp, lat/long, etc) and display them on a little 320x240 pixel resistive touchscreen display (which will double as a keypad for setting ship speed and various other things). I am trying to do away with the keyboard for the most part. I am also starting to design an A3 size panel for all Helm, Nav, and Tactical controls. Though I might take a break from that and look at doing a couple of the UI updates that nozmajner has mentioned in the issue tracker #4078.
Re: Targeted ship information
Nice! If you put up any new video, don't forget to drop a link. :)
About the UI roadmap: talk with ecraven before starting on any of it, he's knee-dip in the whole thing right now and sure can and happily help with it.
And to answer your question there, that roadmap is more so we can see, what's left. We have some general plans, but we usually discuss the part we are on, and design it, mock it up, prototype, other mockups, rinse and repeat until we think it's good.
About the UI roadmap: talk with ecraven before starting on any of it, he's knee-dip in the whole thing right now and sure can and happily help with it.
And to answer your question there, that roadmap is more so we can see, what's left. We have some general plans, but we usually discuss the part we are on, and design it, mock it up, prototype, other mockups, rinse and repeat until we think it's good.
Re: Targeted ship information
Really cool stuff! Sorry I didn't post sooner. Stuff came in between.
Tweeted your video, I assumed you're fine with that.
https://twitter.com/pioneerspacesim/sta ... 7290120192
For submitting the code, you need only make a branch from your master, and push that to your origin. Pure Greek I'm sure, if you're new, but it's all written up here, if you want to go that route:
https://pioneerwiki.com/wiki/Using_git_and_GitHub
Personally, I'm not skilled enough to review any such code, or make decisions if it's OK to merge int master, but I'd love it if it did end up in pioneer.
If you have git/github questions, you can find us on #pioneer on IRC at sane CET-zone times.
I can't wait to see how far you'll take this. Also, you might want to keep an eye on suggested pull request to see what is cooking.
Tweeted your video, I assumed you're fine with that.
https://twitter.com/pioneerspacesim/sta ... 7290120192
For submitting the code, you need only make a branch from your master, and push that to your origin. Pure Greek I'm sure, if you're new, but it's all written up here, if you want to go that route:
https://pioneerwiki.com/wiki/Using_git_and_GitHub
Personally, I'm not skilled enough to review any such code, or make decisions if it's OK to merge int master, but I'd love it if it did end up in pioneer.
If you have git/github questions, you can find us on #pioneer on IRC at sane CET-zone times.
I can't wait to see how far you'll take this. Also, you might want to keep an eye on suggested pull request to see what is cooking.
Re: Targeted ship information
Fine with the tweet, it's all advertising for pioneer which can only be a good thing.
I have already been using the git instructions and have pulled, merged the latest upstream with my code and pushed back to my origin. So feel free to have a look. It's not too exciting unless you have the hardware it supports.
As for how far I take it, well the sky (or the hardware) is the limit. The arduino only has so many I/O lines and I am running out. So my next adventure is to set up an I2C serial bus for multiple devices hooked up. I want to put up panels for Science/Comms, and Engineering, but that will also require significant enhancement to Pioneer functionality. Not too sure what the group will think of that, but that is a way down the track for now. Concentrating on the existing Helm/Nav controls for now. Just keeping up with the cool imgui changes is enough for me at the moment. Next stop is a cardboard panel prototype with all the controls and displays so far.
I have already been using the git instructions and have pulled, merged the latest upstream with my code and pushed back to my origin. So feel free to have a look. It's not too exciting unless you have the hardware it supports.
As for how far I take it, well the sky (or the hardware) is the limit. The arduino only has so many I/O lines and I am running out. So my next adventure is to set up an I2C serial bus for multiple devices hooked up. I want to put up panels for Science/Comms, and Engineering, but that will also require significant enhancement to Pioneer functionality. Not too sure what the group will think of that, but that is a way down the track for now. Concentrating on the existing Helm/Nav controls for now. Just keeping up with the cool imgui changes is enough for me at the moment. Next stop is a cardboard panel prototype with all the controls and displays so far.
Re: Targeted ship information
For controlling pioneer from extra hardware, this looks like an interesting project:
https://hackaday.io/project/3502-pro-tr ... b-keyboard
https://hackaday.io/project/3502-pro-tr ... b-keyboard