stibbons

Oh, the new autopilot callback registers look pretty cool. And if it works the way that thread describes then it would make this plugin config a lot simpler (and I can throw away that last PR ). Sure, I can probably knock up a prototype for that in the next couple of days.

Adding wheel control is pretty straightforward. I've got the changes sitting in my fork now, but probably won't have time to test it properly and send another pull request until the end of the week. If you're keen, https://github.com/phardy/KSPSerialIO/tree/wheelcontrol EVA control isn't impossible, but it isn't exposed the same way other fly by wire stuff is and looks pretty daunting to be honest.

EVA control is something else I'd be keen on, but I'm not aware of any control for it. But the community API docs for FlightCtrlState are woefully lacking. I was thinking about adding some introspection to a test module and seeing what popped out.

Space pants.

I believe you're talking about particle board, commonly referred to as chipboard here in Australia. Shame you didn't get much of the assembly done, I'm looking forward to seeing how it looks.

The error you're getting is because CKAN still registers the old ATM entry installed - just removing the folder isn't enough. I also uninstalled the mod via CKAN. That was a mildly annoying exercise because nothing I did got it to list in the GUI. From memory, running `ckan list` on the command line did list the currently-installed ATM mod though, and I used `ckan remove` on the commandline to remove it. Installation of the new mod went find after that.

zitronen, I've been looking at your git repository, and the most recent commit says it's for 0.16.0. Is 0.16.1 not uploaded yet? (also, yeah, that pull request was totally me. keen to know what you think about it. ) I was a little disappointed to find that the plugin doesn't provide any control of rovers and did a little digging. Looking at the kOS source, it seems the FlightCtrlState object has wheelThrottle and wheelSteer fields (see here and here). I'd be keen to add rover control, either as separate controls, or just emulate the default keybindings and set wheelThrottle and wheelSteer when modifying pitch and yaw?

The documentation at https://github.com/taraniselsu/TacLifeSupport/wiki/Description says that maxing waste resources has no effect. They're just dumped overboard and you lose the chance to recycle waste back to useful resources. If it was indeed CO2 that killed them, I'd consider that a bug.

You're a much braver person than I. I'm enjoying my build a lot, but there isn't enough money in the world to convince me to ever do more than one.

I don't want to start on the enclosure proper until I've got a better idea of all of the panels that are going in to it, but at the same time Ido want to start writing code for and using the panels I've finished. So today I knocked up a second small enclosure for the panels I have ready to go. Of course, the only 5mm acrylic I could find was clear. So, this evening I'll be working on getting these boards wired up and installed, and writing some code to use them. Looking forward to trying these sticks out.

Oh nice. I was thinking about using that for my enclosure, figured it would be lighter and easier to work with than wood. And if it looks as good as your panels I'm sold.

I'm poking and prodding a 50x50 sheet right now and, no, it's got way too much movement. I don't think I'd even trust a single midway support once the panel has holes cut in it. 5mm might not be too bad for what you want. But I think you're going to have to start looking at adding support posts wherever you can. EDIT: The base I'm using right now is 10mm perspex, 320mm by 250mm. Even that has a little bit of flex, although It'd probably be OK in a more rigid box.

Apparently I'm good enough at trigonometry, but fail at basic arithmetic sorry. That should be distance = radius/tan(x/2) For the DTS-M1 at Kerbin that comes to 1075.5km.

You're close! tan(A) is opposite over adjacent, so for dish cone angle x, tan(x/2) = radius/distance. So distance = tan(x/2)/radius.

That's a shame. If my KSP hacking time wasn't already all tied up I'd think about learning some C# and seeing if I could knock the dust off it.

Glad you like it. I'm using Zitronen's KSPSerialIO mod to let the game talk to my arduino over a USB connection. It's geared more towards microcontrollers, probably not the best choice if you want to write an autopilot in a higher level language. I've dabbled with kOS, an in-game scripting system. Then there's Telemachus for web-based control and kRPC is worth a look too.

Thanks! They're 3mm translucent perspex. I paint one side with grey primer, then cut and etch in a laser cutter. The final enclosure will include backlighting for the panels.

After a couple of iterations I finished my attitude control panels. Two joysticks and toggles for RCS and SAS. I seem to have already run out of (or probably lost) the bezels I bought for mounting LEDs, hence holes that will remain empty until I order some more. I've still got two or three more panels I want to add to the board. Current plan is to at least get designs for them on paper, so I can get an idea of what I need for the enclosure.

I am a lowly system administrator who generally thinks in gigabytes not bits, so take my thoughts with a reasonable grain of salt. Also, nitpicking, but the flow rate is specified as bits per second, not baud. The Arduino core library allocates 64 bytes for the Hardware Serial receive buffer. Boards that ship their own cores can increase this apparently, but I have no idea how many do. (similarly, my five minutes googling says that if you want a bigger buffer for your Mega2560, you'll be hacking up a slightly modified core). This means that, at 38400bps, you need to have polled and started reading (64*10/38400) = 0.016 seconds after the packet started to arrive, otherwise the buffer overflows and the packet is corrupt. And after you've read that 64 bytes, you've only got another 0.016 seconds to come back and check again for the next 64 bytes. It'll take a minimum of three batches of reads to get the full packet, possibly more depending on how much time the controller is spending on other tasks. At 57600bps, the buffer overflows in 0.011 seconds. And at 115200bps, you've got 0.005 seconds before the buffer overflows. Even though you've got a lot more idle CPU time, you need to keep individual tasks quite short because you literally need to poll for new serial data every 5 milliseconds. You can relax some of those. I'd be happy letting processing and display update tasks run longer than 5ms after a new packet has arrived on the assumption there won't be another one for 70-odd milliseconds. But to do it without a significant number of dropped packets I think would require much more careful structure. I've been approaching this from the other direction. I've put a lot of thought in to how long I'd need to poll my inputs, run business logic, update displays. And a fair bit of effort in to optimising how well they run and how often they need to run, so I'd have plenty of idle time for serial IO. Haven't yet done any analysis of how busy my arduino is and how many packets are being dropped from the CPU. But I was planning on integrating a second microcontroller soon, and using that to benchmark the main processor's performance sounds like an excellent plan.

Not a lot of progress over the last couple of weeks. The holiday season and trying to get ahead in a new hard-mode career game in 0.90 have kept me busy. :-) I've been trying to make some headway designing new inserts for those analogue panel dials. It's coming along slowly, partly because I suck at driving Inkscape, and partly because I can't decide whether they should be true logarithmic scales (with some fudging around 0), or closer to a more traditional radar altimeter like so: I wanted a couple of digital joysticks for RCS translation control - my intention is to use my existing analogue USB stick for most rotational control, with simple digital sticks on the panel for translation while docking. After trialling a couple of eBay buys I found a nice, compact little stick that doesn't look too arcadey. But the mounting holes are offset from the corners a little oddly and there's no dimensional drawing. It took me a full day of measuring and testing before I was able to laser cut a piece of cardboard to mount them in. :-)

I like how you're implementing a full DKSY interface. The display I've been working on is configurable, but to nowhere near the same extent. Nice work. :-)

Best I've seen for that style of meter is analogue edge meters. Get a voltmeter that measures to 5V to make sure it's easy to drive with an Arduino. But they don't seem to be especially cheap.

I've been swapping between Leonardo, Uno and Mega boards quite a bit while developing stuff, never had any problems what weren't just because of my lousy code. It could be worth checking to make sure that the drivers for your board are still OK and that it's appearing as a serial connection. And I did find that setting a default serial port in KSPSerialIO's config file helped when I was unplugging / replugging the arduino to upload new code without restarting the game.

I've been playing hard mode with the rewards dialled back up to 100% since career mode came out. Even that results in a very very long slog to even start unlocking space centre upgrades in 0.90. Looking forward to scaling the costs back a little with this, thanks!

Oh that's nice. My goal is to be able to do an instrument landing on the Mun, with the monitor switched off. Still a ways off though.