stibbons

Do we really need to directly quote the what not to suggest list?

Doing it in an esp8266 looks like a really novel approach, great work! I'm looking forward to seeing how your project progresses. As far as the lag goes, do you know if that's mostly because of the esp8266's wifi performance, network in general, telemachus, or something else?

I've had a little more time this month to work on software. Refactored a lot of the display sketch. It's a little neater, a little bit faster, and has less duplication and seedy hacks. I was still struggling to figure out how to reduce the size of the KSPSerialIO data packet though. Right now all of the axes that are sent (15 of them!) are 4 byte floats holding a number that can be either 0-360 or -180-180. My first thought was to convert those to a smaller fixed point representation, so I spent a fair bit of time wrapping my head around how fixed-point calculations work. Eventually got a prototype working using 10.6 fixed point numbers, but the accuracy seemed abysmal. I was getting random variations that could go to more than 0.1 away from the original floating point number, unacceptably high. So I put the problem to one side while Christmas happened. Eventually hit upon a possible solution based on how things are done in the real world, while reading Frank O'Brien's The Apollo Guidance Computer: Architecture and Operation in a tent in an outback South Australian town over Christmas. The Inertial Measurement Unit in the PGNCS sends pulses to the AGC indicating rotation around each axis, and it's up to the AGC to count them to measure rotation. A full revolution around an axis contains 32768 pulses, which makes sense seeing as the AGC uses 15 bit data words. Essentially, angle on an axis is measured as a number between 0 - 32767. At first I found it curious that the AGC's angular resolution of just over 0.1 degree was quite close to the error I was seeing in my fixed-point representation. But then I realised that if KSPSerialIO maps each axis' angle to a signed 16 bit number then I'd have a range of -32767 - 32767. It'll be a constant error, much better than the variable floating-point gumpf I had to deal with before, and at twice the resolution of the 8balls the Apollo astronauts used. In your face, Neil Armstrong! Now that I'm back home I guess I'll be spending some time reworking my vector code in KSPSerialIO again, converting it to use a standard integer rather than sending degrees. And then reworking my display code to deal with the new format. Hopefully shouldn't take long to restore functionality though.

This is really useful info, thanks!

After a month of busyness at work and then Christmas shenanigans, I finally got a chance to get back to working my controller hardware. Earlier this month I did manage to laser cut a final panel for the display. Today I got almost all of the work done actually mounting it. Started by soldering the arduino, controller and other bits on to protoboard. While trying to figure out how I'd hold the board on to the back of the display, I discovered that I'd accidentally managed to make the mounting bolts fit very closely to the 0.1" pitch on the protoboard. So I was able to just drill out a couple of holes and slip them over the bolts. Very handy! Testing the board after reconnecting everything was a little bit stressful. I started out running an Adafruit test sketch, which resulted in nothing but a blank screen. Took a good half hour of hair pulling and line tracing before I realised that the Adafruit library doesn't play nicely with Teensy. Switched to my other test code and the whole lot fired up first try, much to my relief. Then came mounting the display panel in the controller. I used the bamboo test panel I cut last month as a template to mark mounting holes and an outline on the controller. Then, heart in mouth, drilled out the holes and finally cut a new hole through with a jigsaw. This was done without removing the other panels, which was a little bit awkward. That's why I managed to end up with some scuffs and dings in the paintwork, and some awkward MDF dust wedged under the cover of the annunciator panel. Luckily I bought way too much of the metallic paint - touching it up shouldn't be a problem. Looking carefully makes it pretty obvious I'm getting worse at keeping my edges straight. But apart from that I'm super happy with how this the controller is looking now. Can't wait to fire up the display again soon.

Accidentally accepted two Mun orbit rescue missions instead of just one. Luckily they were in basically identical orbits, and my rescue boats have been carrying Mk1 Crew Cabins for a while (weigh only slightly more than a Mk1 Command Pod, and look much nicer), so I was able to carry off both rescues in a single mission. Both the derelicts were sitting in 10x12km orbits. What they were doing that low is anybody's guess. So I parked in a 50km orbit and dropped down to pick each one out. Here's my intercept for the second rescue. One downside of using the Crew Cabin is that it doesn't have an external door. Getting two kerbals in requires the pilot go on EVA. Some slightly annoying shuffling. After those rescues, I had enough dV to carry out some Mun observations before heading home, completing three contracts and netting over 500k funds for the trip.

...awkward. (written on my phone)

I had a crack at the training mission just now, and yeah, it seems a little rough. My first problem was with the scenario instructing to burn at the Descending Node to align orbital planes. By then, your vessel in the lower orbit has caught up too much with the stranded one and it's really hard to set up a good intercept (without waiting several more orbits to overtake and come up from the rear again). Instead, burn at the Ascending Node. It's only about 6-7 minutes away when you start the scenario, so you'll have to be quick. But you'll have a lot more freedom to set up a good transfer orbit straight away. Here's the maneuver I was able to set up. The first intercept is about 2.5km, which is a good target to aim for. And if all goes well after setting up this orbit you should still have around half a tank of fuel. The tutorial's directions to slow down while you're still 60km away seem kind of janky. For the above transfer orbit, doing that pushed my closest intercept from 2.5km out to >20km, which is very counterproductive. Instead, change your navball to target mode as the tutorial instructs, wait until you're less than 10km away, and burn retrograde to lose almost all of your speed. Once your relative speed is below 50m/s you'll be able to click forward through the tute, which will tell you to carry on and burn retrograde until your speed is 0m/s. From there the tutorial directions look to me to be good enough to let you complete the docking. Docking is one of the harder things to do, and it's definitely worth trying the other scenarios and tutes people have put together here as well.

Sooo... you're arguing a point that you don't actually know about. OK.

No they're not. You're talking about modders being hired to create stock systems.

Nothing does. Mods don't become stock. Squad has a roadmap, sometimes that map coincides with modded features. Sometimes Squad sees enough talent in mods that they bring in the mod authors and get them to work on stock features. That's how Porkjet ended up bringing a lot to the stock aeroplane parts. It's also how Roverdude ended up working on the stock resource and radio transmission systems.

Sure is! Check out the custom flag tutorial on the wiki for full details.

Wow, that's a really nice compliment. I'm glad you got something useful out of it. Feel free to hit me up if you have any questions. And yeah, I see what you're saying with keeping your scope where it's at. Hope the rest of the build goes that well!

The theme is great. Mobile layout is a lot more useful (but the mobile layout editor could use some more features). The single-page responsive design in thread views shows promise, but I'd like it a lot more if it preserved browser back/forward button functionality.

I use a Linux desktop, but the keyboard I use for KSP is a compact Logitech wireless one, with no spacing between groups of function keys. Which probably doesn't help answer your question.

That's one of the limitations that really frustrated me with the Wire library as well. You can change it by increasing the BUFFER_LENGTH define in Wire.h , but you'll probably soon run in to one of the other limitations that really frustrated me. Wire is synchronous - calls to send or receive data block until the operation is complete. Not such a big deal with 32 byte packets, but if you start sending 200 byte VData packets you'll probably run in to even more timing issues. I ended up using Atmel's TWI reference libraries, modified just enough to work with Arduino. That lets me send the full KSPSerialIO VesselData packet across the bus, and it's fully interrupt-driven and asynchronous. On the downside, the library is lower-level, you'll have to do the work to prepare the packet yourself. And I have no idea if it plays well with TVOut. I'd be worried that two time-sensitive interrupt driven routines will result in too much stepping on toes. If you're interested, have a look at my KerbalController code for an example of a master that sends VData. The library files are TWI_Master.[hc], and my code to send packets is all in twi.ino. For a slave that receives that packet, try the KerbalDisplay sketch. The library files are TWI_Slave.[hc], and my code that handles it all is in twi.ino. Reading data from the slave to the master isn't that much more complicated, but you'll want to refer to Atmel application note AVR315 for the master, and AVR311 for the slave. On the master you'd just set the TWI_READ_BIT to true instead of false, and point TWI_Start_Transceiver_With_Data to an empty buffer. And on the slave you'd use TWI_Start_Transceiver_With_Data to pass in a data packet ready for the master to pick up.

Have a read of the KSP Unofficial Official Computer Building/Buying Megathread, which is almost as exhaustingly informative as the thread title. Lots of advice and info about what other people are buying.

Don't stop the enter key inserting a paragraph break (in the WYSIWYG editor). But do please consider tightening up the paragraph and line spacing.

At least the hyperbole is still alive and well.

Thanks. I put two holes on the right there just because the buttons I bought came in a lot of five, and I figure I'll find a use for them at some point. I do, though, have a lovely five-position rotary switch salvaged from reclaimed medical equipment that wound up in my maker space. You can see it on the left in this old picture: I already have a use for that in mind, but I suppose it could be integrated with the navball panel somehow. Hrmn. I've been putting off finishing the hardware until those buttons arrived, but they've just come in today. The Christmas period is starting to get busy for me, though, so I have no idea if I'll be able to make much more progress on the assembly until the new year. Still tinkering away with my software, too, but with nothing terribly interesting to show for it. I think I've written all the code required to render vector icons, but got distracted trying to convert it all to fixed-point numbers and haven't actually tested if it works yet. Um.

Are you running on Linux? The Linux build has a long standing bug where it does not properly show the build number. You can tell because there have only been two 1.0.5 releases - 1024 and 1028, yet the Linux install always shows 1.0.5.0 at the start screen. You can verify which version you're running by looking at the buildID.txt file in the KSP directory. The default Steam install location is `~/.local/share/Steam/steamapps/common/Kerbal Space Program`. Here's how I just checked it in a terminal on my Debian linux machine running XFCE: I'm running build 1028, the most recent one, from Steam.

That's right. Don't worry about it, I found the squadcast eventually.

Thanks for posting a link to the 'cast. Wait that isn't a link to the 'cast. OK.

Early in my 1.0.5 career, I let a couple of tourists convince me to take them to a Mun orbit.

The indicators in the bottom left show the control inputs that are affecting your ship. In the screenshot you posted, it's trying hard to yaw to the left. It's impossible to say if thats because of SAS, or something else and SAS just isn't able to correct it. What happens if you disable SAS? If the yaw indicator moves closer to the centre then SAS was breaking things. If it moves farther away then something else. What happens if you disable all trim?