Flight Control, Mk II

[derickhuth]

This is really cool. I'm making something similar with a RaspberyPi, but it's more of a display.

[Freshmeat]

@derickhuth Go for it. You probably will want to use kRPC, but I would love to see what is possible with that kind of computing power.

The software is progressing nicely. I had a short detour to install Visual Studio with an Arduino plugin, it is a delight to have an actual IDE instead of a glorified text editor. Once I get confirmation that KSPSerialIO work and a clarification on the action group byte, I can go for launch with a slightly improved functionality compared to earlier, but vastly improved code. I still have lots to do, but it would be nice to actually be able to take off.

[Freshmeat]

Short status update: Progress slowed somewhat down after the control panel got to a working condition. After quite a break in the action I was able to fly rockets, and a lot of time went into actually playing the game. Every panel has its function apart from the TFT panel and the max7219 LEDs, which are working but not programmed to any function yet. The Maxim because it is a chore, the TFT because I have not yet decided what to do with it. It is slow and small, and the SD card reader is nonfunctional.

I have hooked up a real time clock, so I can see when it is time to call it quits. It even prints a message at bedtime. The keypad now builds a string, and once * is pressed twice, it parses and executes a command. For now it is only possible to set the RTC, but I can expand. I will probably need to enter vehicle mass for a suicide burn guidance, and trim for the joysticks could be another useful input.

The LCD screens are incredibly useful, and I have code in place for rocket and airplane settings. The rover setting is in progress, but I am not sure what information a rover needs. Heading and lat/long, slope and slope in driving direction will probably be it.

I have 8 lights on the annunciator panel, and a bit of loss there as well. Apart from the obvious high temp and resource depleted, I want a velocity warning for landers. Other than that, what could be useful there?

So if anyone has suggestions on the above, I would love to hear it.

Edited July 13, 2016 by Freshmeat

[stibbons]

Nice work! Sounds awesome, you should definitely post more pics.

For the annunciator, one or more lights indicating whether it's safe to open parachutes is awesome. The game seems to base the status description on the Mach number, and some experimentation in the KSPSerialIO thread figured out that:

• VData.MachNumber > 0.85 corresponds to "unsafe"
• 0.85 > VData.MachNumber > 0.8 correspondes to "risky"
• VData.MachNumber < 0.8 corresponds to "safe"

[Freshmeat]

Another neat piece of functionality:

Apart from the working LEDs, the LCD now show the amount of dV needed to circularize at either AP or PE. Most flights involve circularization at several points at rendezvous or transfer to new SOI, and I like to know in advance roughly how much I need. For hypothetical orbits I have a spreadsheet on a secondary PC beside my rig to plug in the numbers. If anybody wants it I can post the code, but it is not the cleanest bit I have written. If anybody wonders about Orbital Velocity = 0, it is due to the numbers are fed from KingLuxors debugger. Incidentally, it also caused me quite some confusion when I wrote the dV code. I managed to estimate semi major axis to AP + PE, not counting radius of Kerbin. Nan's all the way until I figured it out.

Next will be annunciator. Thanks to @stibbons for the suggestion. Need to make blink and fastblink functions as well for the lights, I guess.

[Freshmeat]

...And that broke the arduino. Too much load (square roots and several additional floats) made the controller disconnect at intervals. I will be looking for alternatives, but for now, I fly as it is.

[Freshmeat]

So taking a week off and enjoying the weather by the Rhine (not enough rain to make it uncomfortable in a tent, and nice temperatures), I thought up a solution. Several tasks are not necessary to update every loop, so I made a 250ms check. Every other check LEDs are updated, in between i either update gauges (apart from radar altitude, that is still in realtime) and clock, or circularization (if rocket) or inclination of surface (if rover). When I get around to program the TFT it is definitely also only going to update every 500 or 1000 ms.

I am looking into using a faster library for my LCD displays as well, but have not gotten around to see if it, and how much could be gained.

[Mad_Scientist]

Great work! I am also starting to work on the prototype, but not ready to share it yet )) Have you though about performing all of the mathematical and logical part outside the Arduino? Then you just need to send status updates to the board and read inputs.

[Freshmeat]

@Mad_Scientist I rely on a plugin called KSPSerialIO that sends a nonconfigurable packet of information, but does so fast and newbie-friendly. Both @stibbons and @Antipaten use several microcontrollers in their setups, but the data transfer back and forth is a whole new chapter of complexity that I don't feel like bothering with until next spring break at least. For now, the solution I have works fast enough, and I actually get to play the game.

[stibbons]

On 7/27/2016 at 9:05 PM, Freshmeat said:

Every other check LEDs are updated

You might be able to optimise this even more by tracking the current value the LED is displaying. Then you only need to update it when the associated VData variable has changed.

After that, yeah, all of the floating point calculations are really hurting you.  The last time I checked, an ATMega 2560 was roughly ten times slower with floating point calculations than integer operations. If you can cast the AP and PE to longs and get the dV calculations done that way it would probably help a fair bit.

16 hours ago, Mad_Scientist said:

Have you though about performing all of the mathematical and logical part outside the Arduino?

Doing it on another micro adds a lot of complexity. As Freshmeat said I'm using multiple micros, with comms between them over I2C. The problem there is that the stock Arduino Wire library is hilariously slow, and trying to offload processing like that could easily just leave you with an even bigger time deficit. I ended up using my own I2C implementation (based on Atmel's application notes) and it's working OK, but it took me a while and I haven't yet taken the time to package that work up in to an easy library.

I have been idly toying with the idea of writing a new plugin with a lighter weight and extensible serial protocol. But that will be quite some time away.

[Freshmeat]

6 hours ago, stibbons said:

You might be able to optimise this even more by tracking the current value the LED is displaying. Then you only need to update it when the associated VData variable has changed.

After that, yeah, all of the floating point calculations are really hurting you.  The last time I checked, an ATMega 2560 was roughly ten times slower with floating point calculations than integer operations. If you can cast the AP and PE to longs and get the dV calculations done that way it would probably help a fair bit.

Tracking VData ought to have crossed my mind. Thanks for the suggestion.

I have been looking a bit into conversion. The initial problem is that a lot of the values exceed 10^9 or are less than one, but that ought to be doable by changing units. Really missing doubles here. So at least one operation per float. And I will need to take a square root and a couple of cosines, so that will be a snag.

 

[Freshmeat]

I never got around to talk about it, but doing the calculations at intervals worked out nicely, and I proceeded to the next piece of work:

Autopilot functions.

Right now it is a very limited function (altitude control), but I have been able to make a plane fly at 1500m +/- 50m for 30 mins while I had dinner before crashing into a mountain. I hit stage, throttle to the max, and retract wheels as the only interaction. However, the ride is rather bumpy.

The code behind it is a matter of a lot of try and fail, but it ended up with a desired pitch proportional to the error in altitude. The the change in angle of elevons are made proportional to the error in desired pitch. Additionally, there are safety limiters to keep the pitch below 5-10 degrees. These limiters are unfortunately rather drastic to prevent stalling, but the update rate in KSPSerialIO sets a limit to how fast the system reacts. I need to compromise between jerky controls and large oscillations. Further, the autopilot worked for my test plane, and I need to test it on other planes to see if my models works.

Next up will be a heading control. And once that works, I need to read up on spherical geometry to be able to enter coordinates and have my plane go there automagically.

Edited October 17, 2016 by Freshmeat