text:
Talk:Apollo command and service module

Page Title
Does anyone have any objections to me renaming this page Apollo Command and Service Module. This seems to be a more accurate description of what the spacecraft was, with two separate parts.--enceladus 02:16, 25 Oct 2004 (UTC)

 * My personal opinion is, why not go back to having the Apollo Command Module and the Apollo Service Module? They really are two different things... Tuvas 17:40, 25 May 2006 (UTC)

I support (now years later ;-) the rename suggestion. Here's why: Eric Jones uses the phrase "command and service module" is his phenomenal historical work, available online as the Apollo Lunar Surface Journal. See for example, http://history.nasa.gov/alsj/alsj-CSMdocs.html and http://history.nasa.gov/alsj/apollo.engin.html. (sdsds - talk) 04:00, 12 July 2007 (UTC)

 * Support per Sdsds and WP:SLASH. -- G W … 08:42, 29 March 2009 (UTC)

Any reason this hasn't been done? From what I can see most sources (especially contemporary ones) use "Command and Service Module", or "Command Service Module". Not only is the slash inconsistent with the MOS but it often implies "either/or", either in terms of the actual hardware or just the name, which clearly gives the wrong impression here. ChiZeroOne (talk) 09:19, 7 February 2011 (UTC)

 * On a related point the "Apollo" seems a tad redundant. The name of the craft is the Command and Service Module (hence CSM, not ACSM), Apollo is simply what some sources use to disambiguate, but then I'm unaware of any other programme which used a vehicle called anything similar so it seems a bit unnecessary. ChiZeroOne (talk) 23:35, 7 February 2011 (UTC)

Support Apollo Command and Service Module - the current '/' implies alternate names. Since/if they only flew together (apart from reentry) a single article seems fine (but it is tempting to name it with a final 's') - Rod57 (talk) 11:26, 14 May 2018 (UTC)

Crew Capacity
The article lists the crew capacity of the Apollo CSM as being 3. While it did carry three crew members in all the manned missions, it actually had the capacity to carry five. The stowage area behind the crew seats could be configured for two additional crew members. This was considered for space station use, but no capsules ever flew in this configuration. Skylab Rescue was the only capsule ever to be configured in this manner, but it never was used.

I think it is worth mentioning that it had a higher capacity if used in LEO missions for crew transport. It just never was used in this manner. DrBuzz0 (talk) 03:59, 9 February 2010 (UTC)

Yes, the extra seating capacity for the Skylab Rescue is worth mentioning, and should be added to the "Modifications for Saturn IB flights" section. Consideration for space station use would require a source for verification; I would guess that fell by the wayside with the "Apollo X (expansion)" plans which preceeded Skylab. JustinTime55 (talk) 16:38, 17 August 2012 (UTC)

training modules
Why not list the location of training apollo command modules along with the actual command module locations? Many where used in naval bases and is an exact 1 to 1 replica of the real command modules externaly and in weight.

Apollo Subsatellite
It would be nice if information about the Apollo subsatellite (from Apollo 15) can be added to the article.

 * Yes, there is definite value in documenting the Scientific Instrument Module, but I don't believe it belongs with the Service module sectors subsection. It is really a payload and not actually part of the spacecraft which is what this article is meant to cover, so it interrupts the flow.  I plan to move it to the Apollo Program article, under Mission types section where I think it really belongs, when I edit the sectors subsection to improve the wording flow a bit. JustinTime55 (talk) 16:29, 8 February 2010 (UTC)

 * Try PFS-1 (Apollo 15) and PFS-2 (Apollo 16) ... Not in Apollo Program so I've added Apollo subsatellite -> PFS-1
 * Would be nice to see more detail at Scientific Instrument Module - mentions on 3 last lunar missions but does not say if/how contents varied. - Rod57 (talk) 11:43, 14 May 2018 (UTC)

Service Module section
This article is going nicely, and I believe has potential to make a Featured Article. But I see some things in the structure of the Service Module section that could be improved:
 * Paragraph cohesion: a well-written paragraph should be about a single topic, but there are some paragraphs about two or three things bundled together. Also, information about the same topic is sometimes spread out over several paragraphs.
 * Ordering: the topics seem to jump around. Also, there are two paragraphs down below the Service Module Sectors section which should be up in the text above it.

There are also a few minor style / link issues.

Basically, the information that's there is all good, but I've made a pass at rewriting it with improved organization. I haven't removed any of the existing information. JustinTime55 (talk) 13:57, 10 February 2010 (UTC)

Scimitar antenna
What the heck is a scimitar antenna, you ask? It's an antenna shaped like a scimitar. Both the CSM and LM had them to communicate with each other on the VHF band. I'm going to create this new article and link to it shortly. JustinTime55 (talk) 00:16, 11 February 2010 (UTC)

Oxygen and Hydrogen need to be switched
These seems to need to be corrected: '' The cells were fed by two spherical 26-inch (0.66 m) diameter tanks, each holding 326 pounds (148 kg) of liquid hydrogen, and two hemispherical-cyllindrical 31.75-inch (0.806 m) diameter tanks, each holding 29 pounds (13 kg) of liquid oxygen (which also supplied the environmental control system). After the Apollo 13 accident, a third oxygen tank was added.''

The dimensions of the containers makes no sense, in fact it would need 77 cubic feet to store 326 lbs of LH2, and CSM only has less then 20 cubic feet in both bottles combined. Put it simply the smaller tank does not hold 10 times as much of less dense LH2 as the bigger tank holds the more dense LO2. It only makes sense if you conclude the labels were switched and the bigger tank holds 29 lbs of LH2 and the smaller tank holds 326 lbs of LO2. --BerserkerBen (talk) 06:11, 8 March 2010 (UTC)

 * You're right; the words "hydrogen" and "oxygen" are switched. I'll fix it soon. JustinTime55 (talk) 22:36, 10 March 2010 (UTC)
 * I've now fixed this to be the way I intended, with the hydrogen tanks before the oxygen. I apparently didn't finish my cut-and-paste. JustinTime55 (talk) 13:44, 11 March 2010 (UTC)

Category
I wonder why this article is listed in the Category:1971 in space exploration? I'd think it would be either listed in 1967, or in every year that a CSM combination flew...? RadioBroadcast (talk) 13:31, 23 March 2010 (UTC)
 * I think it doesn't make any sense to categorize it under any year, since it refers to hardware and not an event or a spaceflight. (And it was designed and flown before 1967, anyway.)  It should be replaced with Category:Space exploration (assuming that exists) or Human spaceflight. JustinTime55 (talk) 14:31, 23 March 2010 (UTC)

Apollo 13 picture doesn't represent the EPS
It's a misguided idea to represent the power system by the Apollo 13 picture which exposes it. The picture is very blurry and does not serve to illustrate what the system looks like in its normal (undamaged) state. This serves no encyclopedic purpose, and could only serve to inflame the Apollo 13 controversy, which this article is not about. So I am reverting it. If you could find another picture of the complete fuel cell bay, say during assembly, that would be another matter. JustinTime55 (talk) 15:34, 12 May 2010 (UTC)

 * This is the second strike for 70.187.150.207 (talk). You cannot make controversial edits without discussing them on the talk pages. I am going to remove the Apollo 13 picture one more time and if you put it back, then you are edit warring and I will seek page protection or other action. (I see you've done this type of thing at least once before.) JustinTime55 (talk) 18:18, 13 May 2010 (UTC)
 * I think the Apollo 13 picture does have a place. Didn't the explosion originate in the electrical system? It should not be the main illustration of course. Since Apollo 13 was such an important event, it certainly should be mentioned on this page. If the explosion did in fact originate in the electrical system I think that ought to be mentioned in the corresponding section. Martijn Meijering (talk) 05:58, 14 May 2010 (UTC)

 * There is a reference to Apollo 13; it's one sentence mentioning the addition of a third oxygen tank, and there is a link to the article, which contains the picture. Would you be happy if that sentence were expanded to say the EPS was damaged? It's still not encyclopedic to put the picture in this article. JustinTime55 (talk) 15:36, 14 May 2010 (UTC)
 * I don't have strong feelings either way about having the picture in this article, but an explicit mention that the problems with Apollo 13 originated with the electrical system seems appropriate in the EPS section. Why are you opposed to having the picture? Do you think it is somehow critical of Apollo? It doesn't look that way to me. Martijn Meijering (talk) 15:42, 14 May 2010 (UTC)
 * Two reasons for not having the picture here:
 * A matter of scope: Apollo is extensively documented in Wikipedia by a main article on the program, articles on each mission (including Apollo 13), and each major piece of hardware, of which this is one. The picture, as I stated, does not serve to illustrate the hardware so is irrelevant to this article, as would be other pictures of, say Michael Collins flying Columbia while Neil and Buzz walked on the Moon. Yes, the picture is notable and encyclopedic, in the context of the Apollo 13 article, where it is located.
 * Critical of Apollo: I don't see it that way either, but criticism can be in the eye of the beholder. There has been a recent controversy (see Talk:Apollo 13) about whether or not the O2 tank rupture was actually an "explosion" (the NASA scientific investigation did not classify it as such), and this picture has been used in that argument ("evidence of massive damage"). I see no reason to spread that can of worms into this article. JustinTime55 (talk) 18:22, 14 May 2010 (UTC)
 * I think the article is just fine now. If someone still wants to add the Apollo 13 picture they should offer a rationale first. The picture is already on the Apollo 13 page. I say let's leave the page as it is. Martijn Meijering (talk) 18:34, 14 May 2010 (UTC)

Apollo CM sold to Chriet Titulaer for $1
Dutch astronomer and TV presenter Chriet Titulaer famously bought an unfinished CM for $1 from Rockwell after the Apollo program was scrapped. He stated this in a 1996 interview (which is from WAVE, a former Wired-like Dutch magazine, and is in Dutch) and on this forum thread at CollectSpace.com (in English) there is a picture of which is claimed to be the module at a space exhibition in the Netherlands (which Titulaer organized). More discussion at this thread. Apparently someone posting in the first thread contacted Titulaer and he said it was CM 21 but another poster there doubted it. So does anyone have any information about this, about which one it might be? SpeakFree (talk) 14:16, 12 August 2011 (UTC)

 * I have a couple of thoughts about this:
 * Besides the obvious verifiability issue (sorry I can't help offhand with that), I wonder if it's really notable enough to include. I wonder how "famous" it is, since it somehow escaped major attention in the US. (When exactly did he buy it?)
 * This raises the issue of verifiability of the current list of CSM's produced; notice several Block I numbers are missing; what happened to them, and can we tell whether a CM 021 was even produced? Is there an authoritative source for this? (Hence, I tagged the section.) JustinTime55 (talk) 16:34, 12 August 2011 (UTC)
 * I'm not considering including it here, I created the Chriet Titulaer article and I'm interested in adding the exact model he bought (backed up by reliable sources of course). It must have been in the early to mid '70s BTW, not much later after the program was axed. SpeakFree (talk) 17:08, 12 August 2011 (UTC)

Awkward Wording
"But the Apollo 1 flight was cancelled by a cabin fire which killed the crew and destroyed the Command Module during a launch rehearsal test"

Was the Apollo 1 flight really cancelled or was it... destroyed? Also, this should be changed to something to the effect of "The Apollo 1 flight was cancelled by a cabin fire which killed the crew and destroyed the Command Module during a launch rehearsal test" (without the 'but'). 69.174.58.132 (talk) 16:55, 12 June 2012 (UTC)

 * "Apollo 1" was a mission/flight, not a vehicle, thus it doesn't make sense to say it was destroyed when the mission didn't even occur. The mission was cancelled by the loss of the crew so this would seem the best way to explain it.

 * I agree about the use of "but" to begin a sentence, an alternative while retaining the intended tone could be "The Apollo 1 flight was cancelled however by a cabin fire which killed the crew and destroyed the Command Module during a launch rehearsal test". ChiZeroOne (talk) 17:15, 12 June 2012 (UTC)

Specifications: Citation and clarification needed
We really should have citations for the CM and SM specs listed. And there's some confusion about the CM RCS: the engine massis given as a single number; is this for only one engine, or for all 12? (I would guess the latter, since 880 pounds is extremely large; this times 12 is 10,560 pounds, close to the entire Command Module mass! Dividing this by 12, 73.33 is more reasonable.) Also, it doesn't make much sense to include all 12 engines in a meaningful thrust number, since all 12 were never fired at once; they were fired in pairs. For this reason, it's more consistent to report the mass as twelve x 73.3. JustinTime55 (talk) 16:48, 17 August 2012 (UTC)

Subcontractors
The article would probably be improved by giving the reader a better sense of the breadth of the sub-contractor base North American Aviation drew upon. Chariots for Apollo covers this pretty well at http://www.hq.nasa.gov/pao/History/SP-4205/ch4-2.html, in the chapter called "The Team and the Tools." Collins Radio, AiResearch Manufacturing, Honeywell, Radioplane, Lockheed, Marquardt, Aerojet, Avco, Thiokol; all are mentioned. Probably best to distribute these into the article in the subsections covering the subsystems the subcontractors worked on? (sdsds - talk) 05:29, 22 July 2014 (UTC)

Technical Questions-need for section - CM-SM umbilical connection
Since a heat shield separated the service and command modules, how were things such as controls and communication lines routed between the two? — Preceding unsigned comment added by 70.211.71.217 (talk) 18:33, 27 July 2014 (UTC)

 * This is covered in the Service Module section; search on the word umbilical. The umbilical housing is described in the paragraph on the forward faring. Is this not highlighted sufficiently? JustinTime55 (talk) 14:14, 28 October 2014 (UTC)

 * Hard to find before realise it's called CM-SM umbilical connection. Would be great to have a subsection heading under CM ? - Mention the early and late versions. Also includes 'plumbing' - O2 ?, water ?, any other fluids ? - Rod57 (talk) 11:12, 14 May 2018 (UTC)
 * shows images of the only CSM umbilical left - with cover removed. - Rod57 (talk) 12:09, 1 June 2018 (UTC)

 * I think it would be disproportional to dedicate a section to this. I re-wrote the introduction to mention the connection between the modules, which should help make it clear. I also added wikilinks to umbilical cable and did some copyediting where the umbilicals are mentioned in the CM and SM. The differences between the Block I and Block II umbilical designs are highlighted in Major differences between Block I and Block II. JustinTime55 (talk) 15:37, 1 June 2018 (UTC)

 * It would be good to have "umbilical" appear in the Contents. It was called the Umbilical Assembly or Umbilical Structural Assembly. There were about 100 electrical connections, including Bus-A and Bus-B DC power, and some fluid connections, including go-and-return for primary and backup water-glycol cooling circuits. Block II was flown and still exists. - Rod57 (talk) 16:18, 28 December 2020 (UTC)

What lift to drag ratio during reentry
I thought this would be the most likely article to give the L/D ratio of the CM but I couldn't find it. - Rod57 (talk) 01:09, 7 December 2014 (UTC)
 * Space capsule says "the Apollo CM had a lift to drag ratio of about 0.35" but no source. Lift-to-drag ratio says "Hillje, Ernest R., "Entry Aerodynamics at Lunar Return Conditions Obtained from the Flight of Apollo 4 (AS-501)," NASA TN D-5399, (1969)." says Apollo 4 measured at 0.368 - Fig 9 shows it slowly rose from ~0.27 to a brief peak ~0.37. -Rod57 (talk) 01:51, 7 December 2014 (UTC)

Mistake in specifications ?
page shows Launch mass	32,390 pounds (14,690 kg) Earth orbit 63,500 pounds (28,800 kg) Lunar, I suspect these numbers are backwards, and that the larger number is the earth orbit number. — Preceding unsigned comment added by 12.218.0.70 (talk) 19:01, 9 May 2016 (UTC)

 * No, your suspicion is mistaken. The fully fueled CSM weighed about 63,500 lb, and the full fuel load was carried on the lunar missions. The Earth orbit missions didn't require nearly as much fuel as the lunar missions, so carried approximately half the fuel load (there were two sets of tanks, and one was left empty), yielding around 32,390 lb. The CSM engine had to perform the Lunar Orbit Insertion braking maneuver, the trans-Earth injection maneuver to get back home, plus midcourse corrections, and on the later missions, also the Descent Orbit Initiation maneuver, plus a little reserve. For the Earth orbit missions, besides making a few orbit changes for testing purposes (and the rendezvous maneuvers for Skylab), it only had to provide the retro-fire to deorbit the spacecraft. JustinTime55 (talk) 00:56, 28 May 2016 (UTC)

"Depiction in Film and Television"
Should there be such a section here? There were several films made that showed CSM or at least CSM-like spacecraft. The Lunar Module article has such a section. — Preceding unsigned comment added by 110.146.139.203 (talk) 04:52, 14 October 2017 (UTC)
 * No. TJRC (talk) 00:19, 17 October 2017 (UTC)

Skylab Apollo Command module half white half unpainted
The image caption says the Skylab command module was painted white. Only the side facing the sun was white. Details here with photo that shows it clearly in NASA Spaceflight.com forum. Not sure where to go to find out more but it's obviously right.

The photo used in this article must be taken at just the right angle to show the white side only. Robert Walker (talk) 05:13, 17 December 2017 (UTC)

Location of CSM-107
I have no idea how to make the changes, but figure it's safe to request help here, CSM-107 is not currently where the wiki says it is (at NASM),  it is on tour and will be at the St Louis Science Center starting 4/14/2018 as part of the Destination Moon Traveling Exhibit. Thanks for fixing. 75.100.175.2 (talk) 18:58, 9 April 2018 (UTC)

What happened to the service modules
Can't see it here or in Apollo program. When did the SMs separate from the CMs (as late as possible - after targeting the CM landing area) ? Presumably the SMs all burned in earths atmosphere, but how accurately were they targeted (after separation from CM ?), and where did they burn up (or crash) ? How far from the CM reentry ? Where any SM reentries observed ? - Rod57 (talk) 12:21, 14 May 2018 (UTC)

CSM-105 on display
We need to find a source to see if the Apollo-Soyuz Test Project exhibit on display at the National Air and Space Museum includes the SM-105. This craft never flew, so it's possible the Service Module is included. JustinTime55 (talk) 21:06, 30 May 2018 (UTC)
 * It looks like it is,, and I made a bad revert to the IP addition of it. TJRC (talk) 22:18, 30 May 2018 (UTC)

Requested move 26 November 2018 - to lower/sentence case

 * The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: moved. This proposal hinged upon the application of the MOS:CAPS and NCCAPS guidelines. According to those guidelines, Wikipedia avoids unnecessary capitalisation. Specifically, MOS:CAPS says "only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalised in Wikipedia". The evidence brought to the table by the nominator, and also by other participants in this discussion, such as Mandruss, makes clear that this term is not consistently capitalised in a substantial majority of independent, reliable sources. Those opposed to the move largely ignored Wikipedia policy or guidelines in their reasoning, instead relying on appeals to "historical importance", and personal feelings. As none of them were able to refute the evidence or policy-based argument presented by the supporters of this proposal, I believe that there is a consensus to move this article as proposed. The question of the stroke (slash) was not adequately discussed in this RM, and so I would suggest either a new RM, or an RM/TR technical request to deal with that issue. RGloucester — ☎ 03:48, 12 December 2018 (UTC)

Apollo Command/Service Module → Apollo command/service module – Sources overwhelmingly treat these as not proper names; so per MOS:CAPS and WP:NCCAPS, we use sentence case. Dicklyon (talk) 01:18, 26 November 2018 (UTC) --Relisting. bd2412  T 00:04, 4 December 2018 (UTC)
 * Oppose Andy Dingley (talk) 01:34, 26 November 2018 (UTC) Because this is self-evident to any competent editor, and yet DickLyon has a track record of falsely and deceitfully claiming that not opposing his requests is the same thing as supporting them. This will form part of the evidence in the imminently inevitable call for him to be TBANed from making any such rename requests. Andy Dingley (talk) 13:24, 28 November 2018 (UTC)
 * Disagree with @: the argument is not self-evident. And I am really not a big fan of seeing personal attack instead of discussing issue. Xinbenlv (talk) 20:17, 9 December 2018 (UTC)

 * Support as nom per evidence in sources, e.g. as summarized in n-grams. Dicklyon (talk) 02:17, 26 November 2018 (UTC)
 * Support Agree with @ because most source shows the naming is lowercase. A quick Google search shows dominantly lower case. Xinbenlv (talk) 20:17, 9 December 2018 (UTC)

1. I don't know why other sources should be given equal weight to NASA itself. It stands to reason that other sources are far less attentive to such trivial details (only Wikipedia takes this stuff so seriously, and we don't have deadlines), so we would be basing our decision on a collection largely composed of haphazard writing and spotty editing as to this capitalization. So what does NASA say? Recognizing that their treatment has likely evolved over the past 60 years, NASA web pages with dates within the past year appear to clearly favor capitalization (without being 100% consistent). 2. It seems to me that a common name, being generic, must refer to more than one type of thing by definition. If it's a common name, there should be at least a couple of other uses of "command/service module", or even "command and service module". How about some examples of command and service modules in other fields, or even in aerospace for that matter? ― Mandruss  ☎  04:35, 28 November 2018 (UTC) Note that I've seen no evidence that any of them treat single copies any differently than the collective term; i.e. e.g. "Apollo 14 command and service module" would be seen in those that don't capitalize. And, FWIW, "command and service module" appears to be far more common than "command/service module" in these books. 1. "Apollo - The Race to the Moon", Charles Murray & Catherine Bly Cox, 1989. As far as I'm concerned, the definitive history of Apollo, 510 pages extensively footnoted. Uncapitalized. 2. "A Man on the Moon", Andrew Chaikin, 1994. Uncapitalized. 3. "Failure Is Not an Option", Gene Kranz, 2000. Capitalized. 4. "Flight", Chris Kraft, 2001. Uncapitalized. 5. "Digital Apollo", David A. Mindell, 2008. Uncapitalized. ― Mandruss  ☎  22:01, 29 November 2018 (UTC)
 * Strong oppose This is preposterous. These aren't just words, they're actual spacecraft designators. Should we move Lunar Excursion Module to lunar excursion module? Contemplate that for a moment, & if you think it's a good idea, find a mirror.   Tom Snyder  Wikipedia, go ahead  11:29, 26 November 2018 (UTC)
 * Ah, yes, I see that refs 8, 16, and 22 on the Apollo Lunar Module article capitalize Lunar Module. But the rest do not.   The older term Lunar Excursion Module is mostly used to define the acronym LEM, but is still only capped half the time (often in titles and headings); in sentences, it's not treated as a proper name.  So where is your strong oppose coming from? Dicklyon (talk) 15:54, 26 November 2018 (UTC)
 * You don't respond, and you comment again later with a different signature, suggesting we go with what NASA used back in the day, while not paying attention to what that was. Why not review the evidence and change your response in light of it? Dicklyon (talk) 05:37, 3 December 2018 (UTC)
 * Oppose, space, the final lower-case frontier? Per Trekphiler, "actual spacecraft designators". The historical importance of these names should also be predominate in Wikipedia's title choices as the leading encyclopedia on the planet (and soon to be beyond the planet as humans again go to the Moon and play among the stars with internet access). Randy Kryn (talk) 14:31, 26 November 2018 (UTC)
 * So you guys aren't even going to look at the fact that most sources don't cap these? As for "actual spacecraft designators", perhaps some like "Apollo 13 Command Module" are, but there were many other Apollo command modules. Dicklyon (talk) 15:35, 26 November 2018 (UTC)
 * Mild Oppose - Best to treat as a proper name, especially in the combined name, even though many sources do not. - BilCat (talk) 02:46, 27 November 2018 (UTC)
 * OPPOSE...Is it just me, or is this page suddenly the subject of a lot of trivial nonsense?--RAF910 (talk) 02:55, 27 November 2018 (UTC)
 * Oppose (Defected to Support below) - We should consider that the relevant guidelines are not carved in stone, may need some work, and are descriptive not prescriptive. Or, we can simply rely on WP:IAR, which I will do now, indefinitely.
 * I agree with you that "ignore all rules" is about the best argument that can be made for this one. Not good, but the best. The existence of other things called command and service module is not relevant here; the line of modules in the Apollo program are enough to show it's generic; there were many numbered specific ones that we can capitalize within that range. Dicklyon (talk) 06:22, 28 November 2018 (UTC)
 * IAR is not the argument, it's merely the policy that lets me make an argument inconsistent with the letter of the guidelines, and not have my argument immediately thrown out by the closer. I disagree with your assertion that "Command/Service Module" became generic when NASA built the second copy. And so does NASA, apparently. ― Mandruss  ☎  06:40, 28 November 2018 (UTC)
 * No, it became generic long before that, as you can see from all the NASA design and planning documents. Dicklyon (talk) 16:00, 28 November 2018 (UTC)
 * Support. This is a basic WP:NCCAPS and MOS:CAPS case. Independent reliable sources do not consistently capitalize this, nor does NASA's own documentation. (The opposers' "I like it", specialized-style fallacy, and blatant cherrypicking to just single out a few cases where NASA did capitalize it, and ignore the many examples where they did not, is just plain shameless.) The article's lead sentence is wrong and confusing (even to commenters here): "The Apollo Command/Service Module (CSM) was one of two principal components of the United States Apollo spacecraft, used for the Apollo program which landed astronauts on the Moon between 1969 and 1972."  This is a misstatement that badly misleads readers into believing there was a single CSM used for 3 years and all missions during that time.   There were at least 20 CSMs, of varying designs. I looked at the first 50% of the cited sources, one by one, and they are consistently using lower-case for this, except: a) in headings/titles written in title case or all-caps; b) in names of specific actual CSM models, e.g. Apollo 4's Command Module 017, which are proper names (the same way M1126 Infantry Carrier Vehicle is but US military armored personnel carriers is not); and c) "sources" we should not be using at all, like Encyclopedia Astronautica, a WP:UGC site – and even that one uses lower case at least half the time. Aside: Even if NASA had been consistently capitalizing it (which they were and are not), we wouldn't care much per WP:INDY, WP:OFFICIALNAME, and WP:UNDUE. And because WP has its own style manual; it is not written in the bureaucratese of the GPO Style Manual that NASA and other US agencies follow.  — SMcCandlish ☏ ¢ 😼  20:11, 28 November 2018 (UTC)
 * Collateral damage: the same logic can be used on Apollo Lunar Module, even though n-grams support upper-casing. When the lower-casing editors get a foothold into an area they tend to give it a shake-up. This attempt to downgrade the upper-casing of Apollo mission details comes, not so ironically, in the lead up to the 50th anniversary of Apollo 8's historic trip to the Moon, which occurs in a few weeks. The Apollo 8 article, which will obtain large viewership leading up to and on the anniversary, is full of upper-cased Command Module and Lunar Module mentions. To want to change this long-standing correct upper-casing on the eve of a major anniversary of this historical event is quite something. Randy Kryn (talk) 16:16, 29 November 2018 (UTC)
 * Note that Randy made his bolded oppose already above, so this bolded response looks like a double-vote kind of thing. Dicklyon (talk) 05:42, 3 December 2018 (UTC)
 * Obvious argument to emotion fallacy, and sourcing misrepresentation. As has been pointed out to you many times before, the N-grams you attempt to rely on at RMs are faulty, as they do not exclude title-case headings, titles, captions, and other such cases which would be capitalized even if they were "Cup of Coffee" or "What I Did During Summer Break". You've had  of people informing you how to use the tool correctly, and I've done so again at your talk page.  If you do a proper N-gram search, you find the usage entirely mixed; the lower-case uses add up to about the same as the capitalized ones, and the capitalized version virtually never occurs except in a contextually specific reference to a particular module in a particular mission (even then, lower-case is very frequent). The over-capitalizations "an Apollo Lunar Module" and "Apollo Lunar Modules"  ever indexed by Google; these  appear in lower-case form (other than "Apollo" being capitalized, of course).  Our articles are about the Apollo lunar modules, and Apollo command/service modules (as classes). The confusion you are suffering (or pretending to suffer to try yet again to force capitalization on Wikipedia that is not used by most sources in the real world) is the exact same one that leads to not understanding that "Florida-class battleship" is not capitalized beyond the proper name it contains; you are failing to distinguish between a class of vehicles and a specific vehicle. PS: A problem with a search like this, on any topic like space craft, dinosaurs, sharks, pets, robots, and other topics that appeal to kids, is that many of the books indexed by Google are works intended for children, which are not reliable sources and which have a strong tendency to over-capitalize for emphasis. Same goes (especially for a topic like this one) for American primary- and secondary-school textbooks. If it were possible to winnow the N-grams of such material, you'd find the capitalization frequency even lower. We know this already, because few of the actually reliable sources we're citing in the articles and have vetted are applying the capitals other than to specific vehicles like Apollo 4, Command Module 017.  — SMcCandlish ☏ ¢ 😼  18:43, 29 November 2018 (UTC)
 * Support - It occurred to me that I actually own some books on Apollo. These will be more carefully edited for such minor detail than news pieces or even NASA web pages. While n-grams are opaque, requiring faith that what's being summarized is all relevant, these books are something I can actually see and touch. And they surely beat evidence-free arguments that capitalization is "obvious". I don't feel the need to look any further. Four out of my five books don't capitalize this, which is good enough for me.
 * Of course your good faith change is your choice, as most, but not all, editors accept decisions and comments in good faith. My concern is that if this lower-casing of a long-term title is, sadly, accepted, just a few weeks short of the historic Apollo 8 Moon orbits and eight months short of the 50th anniversary of the first humans walking on the Moon, then someone may take that as permission to automatically change the Wikipedia pages Apollo Lunar Module and Lunar Roving Vehicle, which both have n-gram majorities for upper-casing. Can you please take a look at the same books and see if those are capitalized or lower-cased? Thanks. Randy Kryn (talk) 22:29, 29 November 2018 (UTC)
 * Although this NASA 50 year retrospective of the Apollo Lunar Module may cover my question as well as provide another source for the upper-casing of Command Module. Randy Kryn (talk) 23:09, 29 November 2018 (UTC)
 * The outcome here is not relevant to other cases. The instructions for moves are clear that RM should be used if the move is likely to be (or "may be", I'm not sure of the exact wording) controversial. As it's crystal clear that such a move would be (not may be, not likely to be) controversial, doing it without an RM consensus should be strong grounds for a WP:DE complaint, which I would support if I were aware of it (I don't generally watch ANI). It would give you and others the ammunition you seek. That said:
 * LM: All but Kranz uncapitalize, as you would expect. Kranz is an unpredictable mix, which reduces my opinion of the editing there, almost making it a case of four-out-of-four on CSM. Of course LM or LEM is used far more frequently in all books, for brevity.
 * LRV: Kranz and Murray/Cox, "Lunar Rover". Mindell, "lunar roving vehicle". Craft and Chaikin, no index entry. ― Mandruss  ☎  23:13, 29 November 2018 (UTC)
 * Kranz is the most important, as he was the head of the project. And if you didn't check out the NASA link I left above, please do so, both for this discussion and because you like the Apollo information - I'd suggest watching the NASA vintage Apollo 5 15-minute documentary linked to youtube on that page, I just saw it and learned a lot about the Lunar Module (they correctly call it a spacecraft). After reading the link and watching the video you may up your estimation of Kranz's upper-casing the terms, and maybe consider having another switcheroo. As for me complaining about anyone to some kind of formal tribunal, I've never done that or would do it unless under the most extreme of circumstances. Not my thing. Randy Kryn (talk) 03:30, 30 November 2018 (UTC)
 * I haven't a shred of doubt that Kranz deferred to his editor(s) on this. Any student of the American space program knows that attention to unimportant pedantic detail was not Kranz's bag. My strong guess is that decisions about capitalization of names of spacecraft components were not made by flight directors, anyway; NASA's bureaucracy was far larger than that, and flight directors had far more important things to think about. So no re-switcheroo, sorry. But we're straying far too far into original research/personal knowledge, even WP:FORUM, so let's nip that in the bud. As for the rest of your comment, let's save that for the inevitable LM RM. ― Mandruss  ☎  04:01, 30 November 2018 (UTC)
 * Are you guys looking at a different Kranz book than this one I found while working on refs at Talk:Apollo 8? I see nothing but lowercase modules in Kranz Failure is Not an Option, so I'm happy Randy sees this as "most important". Dicklyon (talk) 05:46, 7 December 2018 (UTC)
 * I'm unable to find the couple of occurrences of "Lunar Module" I'm sure I saw before, and I don't recall how I arrived at them. It would be tedious beyond description, scanning for any occurrence of lunar module, Lunar Module, LM, or LEM on each of the dozens of pages listed in the index entry (the index doesn't separate them, as they are different names for the same thing). I'm already blind enough, and it's possible the capitalized occurrences were fixed in a later edition anyway. Randy is not going to be swayed if it's shown that Kranz consistently lower-cases. ― Mandruss  ☎  06:23, 7 December 2018 (UTC)

 * Support as follows:
 * The evidence at this point consists of three n-grams (, and ) and a sample of good quality sources(?) by . MOS:CAPS states: "only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia." (my underline for emphasis) The n-grams show at best, mixed usage not meeting the requirement a "substantial majority". The books, while only a small set, confirm this. According to the advice of MOS:CAPS, and on this evidence, the article should be moved/decapped.
 * has noted that the opposing comments lack substantive justification. WP:CONSENSUS is not a vote or head-count.
 * An appeal to NASA's "authority" is a logical fallacy. It also falls to specialized-style fallacy.
 * Onomastics does not support this as being a proper name noun phrase:
 * Proper names are not descriptive - this is.
 * A single referent or (discrete set) does not make a name (appelative or "common" name) a proper name.
 * Proper names generally are not modified by articles or other determiners ("the" may be part of a weak proper name). Being able to use the indefinite article clearly indicates something is not a proper noun. I should not be able to say "An Apollo CSM docked to the Skylab space station"
 * A proper name cannot be pluralised or, if in the plural form, singularised (ie the Pleiades but not a Pleiade) CSM is pluralised in the article.
 * In the noun phrase, "Apollo" is acting as an attrbutive noun, to describe the "command module". While not used as a proper name, Apollo is capitalised because it is derived from a proper name. Capitalising part of a noun phrase (particularly an attributive noun such as Apollo) does not confer capitalisation on the whole phase or imply that the appelative to which the attribution applies is a proper name.
 * Regards, Cinderella157 (talk) 00:51, 30 November 2018 (UTC)

 * Oppose. I've looked at the arguments above and they seem to be along the lines of "it shouldn't be" or "some people use lowercaps". Neither of those reasons convince me that the article should be renamed. Regards, Anameofmyveryown (talk) 20:42, 5 December 2018 (UTC)
 * Where are you seeing such arguments? The arguments I see for moving to lowercase are about usage in sources relative to criteria in MOS:CAPS, using evidence from books n-grams, while argument to maintain uppercase are pretty content-free like yours. Dicklyon (talk) 04:43, 6 December 2018 (UTC)
 * When I said "I've looked at the arguments above" I was referring to the arguments above - ie, earlier on the talk page. My comment was moved by somebody else after I made it so they may now occur lower down: I haven't checked. Regards, Anameofmyveryown (talk) 20:07, 11 December 2018 (UTC)
 * WP:COMMONSENSE. That's the policy (or overriding 'above policy' language) which should be the backbone of a close. Randy Kryn (talk) 13:39, 6 December 2018 (UTC)
 * That isn't how this works. "I'm not convinced by your arguments" is not an argument. It's the start of one, but you need to follow with the reasons why capitalization is better, and arguments supported by evidence are stronger than arguments without evidence. For example, my evidence is (at least) four out of five books about the Apollo program. Examples of weak or non-existent arguments: "It's self-evident" and "It's common sense" (and out-of-process personalization of content disputes under the guise of !voting). ― Mandruss  ☎  07:00, 7 December 2018 (UTC)
 * I'm not sure you're correct there. I read the arguments, I wasn't really convinced by them, so I opposed. Regards, Anameofmyveryown (talk) 20:07, 11 December 2018 (UTC)
 * Comment, please be aware that the Apollo 8 page will be featured on December 27, during the 50th anniversary of the first piloted lunar mission. The logical upper-casing of Command Module (there are no other articles named 'Command Module', making it a proper noun) will, hopefully (in my personal opinion which is, yes, colored by emotion - this is humanity's first step away from the planet for Armstrong's sake!) be presented to feature readers in its long-term form. Randy Kryn (talk) 13:39, 6 December 2018 (UTC)
 * Randy, since when did sole existence qualify for "proper noun" status? And I'm not sure you've clearly defined that term. Tony (talk)  00:24, 7 December 2018 (UTC)
 * Oppose I may be contradicting myself, but I see these as proper nouns.  TREKphiler  any time you're ready, Uhura  23:39, 7 December 2018 (UTC)
 * Yes, you are contradicting yourself with respect to sources, but you already registered your Strong Oppose above with signature Tom Snyder. Please strike your re-vote and consider adding an explanation for your oppose since it seems to be so discordant with your "what did NASA call it" comments. Dicklyon (talk) 02:22, 8 December 2018 (UTC)

Please see section below before adding new !votes. Dicklyon (talk) 16:10, 9 December 2018 (UTC)
 * This long-term stable title fulfills all five titling criteria, backed up by long-term significance. This provides the compelling evidence for keeping upper-casing per WP:COMMONSENSE - as does NASA's decision to upper-case the name in releases and videos during the 50th anniversary (as shown and linked to above). Yes, many books and articles have lower-cased Command Module during its actual use, or in later reporting. Yet in present time, as shown by NASA's present use, the Command Module is a proper noun, and Wikipedia commonsense and the occasional exception language should take priority. Randy Kryn (talk) 11:29, 11 December 2018 (UTC)
 * Note to closer: [immediately above] Yes, many books and articles have lower-cased Command Module during its actual use, or in later reporting. This is explicit (though unintended) confirmation and acknowledgement that, per the criteria at MOS:CAPS (specifically wrt and iaw sources) the subject noun phrase (and hence the title of the article) should not be capped. Further, it does not meet the onomastic criteria to be considered a proper name per above (noting also that a proper noun is a single word and not a noun phrase). NASA is not an onomastic authority.

 * On WP:COMMONSENSE: The short-cut is to part of What "Ignore all rules" means (WP:WIARM). It links to Common sense, which "is sound practical judgment". Therefore, to claim a matter of common sense, one must be able, if challenged, to detail how it is a "sound practical judgment". To say: "It is common sense because it is sound and practical; therefore, it is common sense" is a circular argument and therefore non sequitor. Common sense is reasoning that is so apparent and fundamental that it requires no explanation but, should a logical and sound explanation be required, the underlying premises can and should be able to be laid out. WP:COMMONSENSE also links to Editorial discretion, which, in turn, links to WP:CON. In short, editorial discretion is subject to consensus. WP:IAR is for when the letter of a rule is in conflict with the spirit of the rule and for unforeseen circumstances. It is a rule of exceptions to the rule but is subject to consensus. If a rule prevents you from improving or maintaining Wikipedia, ignore it. but, if challenged, there must be a consensus to sustain ignoring the rule. For a consensus, there must be strength in the case to ignore the rule: NASA did it; it is the anniversary; or, I think it is important, are not strong arguements. They are arguements of the type which are specifically identified as weak and even, inconsequential.

 * Citing WP:COMMONSENSE basically alone (withstanding inconsequential references per above), as primary justification in a discussion intended to establish consensus for deviation from the "rules" is circular and non sequitor. Regards, Cinderella157 (talk) 16:45, 11 December 2018 (UTC)

 * Support (and also change the slash to "and"): I am somewhat surprised to learn that the usage in high-quality independent reliable sources supports the lowercase, but so be it. Mandruss, for example, clearly confirms that high quality sources use lowercase. As SmCandlish and Cinderella157 point out especially effectively, the term is not a proper noun – the "command and service modules" constituted a set of things, and the Apollo command and service modules were a subset of that set –  the term describes a group of things rather than a single thing. And if reliable sources confirm that lowercase is commonly used, then we have no good reason to use caps. I don't personally care too much what NASA does –  independent sources should carry more weight –  but NASA self-published material does not appear to indicate a need for capitalization either. The Apollo CSMs were really important things, but we shouldn't use caps as a way to indicate importance –  Wikipedia should be a dignified encyclopedia, not sensationalistic journalism. When in doubt, Wikipedia generally favors lowercase –  as it should. To me, the comments given in opposition don't seem to be providing any clear argument. My impression is that those seem to be come from the idea of wanting to use caps for things that are important, which is not the Wikipedia convention. —BarrelProof (talk) 17:36, 11 December 2018 (UTC)

 * Support After realizing I have been emotionally attached to the capitals for going on 60 years, I've become persuaded to follow the consensus that seems to be forming ("be picky about which field you choose to die on"). I think the confusion and attachment to the capitals really stems from the use of CSM, LM, etc. as examples of NASA's attachment to acronyms (or initialisms if you prefer). I don't think we should be persuaded by "what other sources say", but go by our own MOS: WP:Initialisms; specifically expanded forms WP:EXPABBR which says to use capitals only for proper noun phrases (e.g. British Broadcasting Corp.) and not common noun phrases. The Apollo modules really aren't common nouns, though we might have talked ourselves into calling them that in order to distinguish them from really generic forms (such as the "command module" you might find as the tiny computer which controls your car's engine.) JustinTime55 (talk) 19:43, 11 December 2018 (UTC)

Comment
It's very disappointing to see a raft of opposes above with either flimsy stated justification or reasoning, or none at all (like Andy Dingley's ... yet he is a sophisticated editor). Where is the compelling logic, the balanced evidence, that might counter Dicklyon's request? For the record, it's a Support from me. Tony (talk)  01:15, 28 November 2018 (UTC)
 * Because even though the sources are near equal, people know that historically, looking at long term significance, the Apollo Command Module is the Apollo Command Module and not the Apollo command module (that doesn't even make sense, what else is a "command module" aside from the Apollo Command Module?). If you want to look at policy or guideline for this one, exception, pure and simple, with a good dose of common sense - the two things spelled out in the introduction to every guideline. The Apollo Command Module is a thing, a proper noun, and there's really nothing to tell you if you don't know that, and that Wikipedia should not be changing the name of such a thing. Randy Kryn (talk) 01:45, 28 November 2018 (UTC)
 * Randy, the article has 26 references. Can you find any other than number 9 that treat these as proper names?  Why should we if sources (including NASA) don't?  You and BilCat seem to think that "even though many sources do not" is a reason. Dicklyon (talk) 02:36, 28 November 2018 (UTC)
 * So you claim that the only sources available for Apollo are those already listed here? Why?  Andy Dingley (talk) 13:53, 28 November 2018 (UTC)
 * He obviously made no such claim. See Straw man.  — SMcCandlish ☏ ¢ 😼  18:43, 29 November 2018 (UTC)
 * Here's a good NASA page which upper-cases and has a large array of related links (I haven't looked at any as yet). The NASA page I linked to above also upper-cases the relevant terms. Randy Kryn (talk) 12:42, 30 November 2018 (UTC)
 * What I'm suggesting is that the existing references have not been cherry-picked for case, yet only a tiny fraction of them (perhaps only 1) treat these as proper names. Clearly others exist on both sides, but just as clearly the treatment as proper name is a small minority – even more so if you restrict to sources from before the time that Wikipedia started to influence by capping the article title in 2004; most article titles do start capped because people don't know about WP:NCCAPS, but then they get fixed.  This one could have been fixed when it first got a reference to two in 2006–2008, if someone had noticed that the refs didn't cap it, but that didn't happen.  So now we're noticing that the article is a great of mass of overcapitalization, not just in the title, and trying to fix it. Dicklyon (talk) 18:53, 30 November 2018 (UTC)
 * I concur with Tony that eye-roll "not again" comments are not useful in discussions like these (or any other discussions, for that matter). If an editor can't participate constructively and with respect for their opponents, they shouldn't participate. Dicklyon continues to operate fully within the system that he didn't create. And of course Dingley's not-not-vote will be discarded for the reason obvious to any editor with a smattering of experience. ― Mandruss  ☎  04:35, 28 November 2018 (UTC)

 * This is not a new act for DickLyon. He bounces from project to project pushing these dogmatic and frequently clearly incorrect naming changes. It is a waste of their time for other editors to repeat the same complaints against him, as he will simply WP:IDHT. Andy Dingley (talk) 13:26, 28 November 2018 (UTC)
 * I frankly find the references to "sources" a bit mystifying. What did NASA use at the time? Capitals, & that should govern. Just because ill-informed writers since have failed to appreciate these were designations & not merely descriptions does not mean WP should fall into the trap.
 * I'm also a bit curious about the notional flimsiness of reasoning. I wasn't aware it was being graded. Nor do I find my own lacking in some way, or I'd have said it differently. (Excuse my vanity. :D ) TREKphiler  any time you're ready, Uhura  15:28, 28 November 2018 (UTC)
 * Good that you should ask. All the old NASA docs use lowercase.  Let me know if you find counterexamples. Dicklyon (talk) 16:04, 28 November 2018 (UTC)
 * There are lots of scanned historic docs linked here. Unfortunately they're not OCR'd, so tedious to search through. Dicklyon (talk) 05:23, 29 November 2018 (UTC)
 * Actually, it looks like the "sections" linked here are OCR'd and searchable, though the overall file is not. Just search for "module" to see that NASA didn't treat these as proper names. Dicklyon (talk) 05:32, 29 November 2018 (UTC)
 * Turnabout is fair play and : This is not a new act for several "give me capital letters or else" usual suspects. They bounce from topic to topic, monitoring RM for any capitalization case they can jump into, pushing dogmatic, subjective, anti-consensus, and clearly incorrect arguments in favor of over-capitalization, wasting other editors' time with a years-long pattern of WP:IDHT / WP:FORUMSHOP / WP:WINNING, with arguments to avoid, with fallacies like argument to emotion and the specialized-style fallacy, with a wacky idea about proper names that seems to amount to "anything I think is important is a proper name", with outright denialism of proven RS usage patterns, with pretense that WP:NCCAPS, MOS:CAPS, WP:OFFICIALNAME, etc., do not say what they say or that they magically don't apply to some "pet" topic, and with a WP:GREATWRONGS / WP:BATTLEGROUND stance rooted in mid-20th-century traditionalism and in denial that Wikipedia (like every other major publisher) will have and apply its own house style. Repetitive squabbling against lowercase, from a tiny handful of overly emotive (and decreasingly civil) editors, is the number one disruptive waste of editorial time at RM.  People need to make their case without hypocritically attacking other editors, misrepresenting evidence, campaigning against guidelines they've failed to get consensus to change, or recycling the same already-refuted arguments page after page. When consensus keeps going against you, it's time to drop the stick. I have to point out that WP has topic-banned some individuals from particular style peccadilloes (and from MoS matters generally), and even indeffed people who will not stop campaigning against guidelines they don't like.  It's unfortunate, but tendentiousness like this has to stop one way or another. This is not WrittenIn1970sEnglishOrDieTryingPedia.  — SMcCandlish ☏ ¢ 😼  18:43, 29 November 2018 (UTC)
 * , for a good example of an editor who uses insults or attack language, please carefully read your comment over again from an objective point of view. Thanks. Randy Kryn (talk) 22:39, 29 November 2018 (UTC)
 * You frequently claim you're being attacked when you're simply having your behavior and rationales criticized. The difference is that Andy Dingley is actually attacking DickLyon, at a personality level, for doing what the latter should be doing: applying to our content the applicable WP:P&G, along with the cited and other found reliable sources, in ways we're instructed to apply them by those P&G, without emotive regard to the topic, and critical of attempts to side-step this normal process.  By contrast, I'm criticizing your and Andy's behavior for exactly opposite reasons: you ignore, cherry-pick, and distort the sourcing, you ignore the P&G at best and frequently just defy them, in highly non-neutral ways that have nothing to do with writing any encyclopedia on its own terms, but with enforcing your personal traditionalism-based viewpoint (especially about certain topics for which you make fallacious special pleading demands), and you both malign the motivations of your opposition in highly personalizing ways. There's a world of difference.  — SMcCandlish ☏ ¢ 😼  00:25, 30 November 2018 (UTC)
 * You almost had me, and then in the second to last line you couldn't help yourself and accuse me of "malign the motivations of your opposistion in highly personalizing ways." Not that I can recall, and again it sounds to me like you're describing yourself in that line. I just came here to grab the link to NASA's site that I left above, because for some reason you've gone to my talk page to explain your point of view again, and now I have to link the NASA link so my talk page lurkers have some idea of what's going on over here. Randy Kryn (talk) 02:45, 30 November 2018 (UTC)
 * More WP:IDHT and circular reasoning. When I explain to you why criticizing your edits and the pattern they form is not a personal attack on your character, it is not a reasoned response to claim that you're being subjected to a personal attack on your character by having your edits and the pattern they form criticized.  — SMcCandlish ☏ ¢ 😼  03:23, 30 November 2018 (UTC)
 * I'll let the comments stand for themselves. Anyway, I just watched the NASA vintage video of the Apollo 5 mission which was linked on the NASA site I link above, and learned a lot about the Lunar Module (which I hope doesn't become a title issue after this one is decided), which is a named spacecraft. So NASA information does exist that shows upper-casing. Randy Kryn (talk) 03:39, 30 November 2018 (UTC)
 * No one suggested otherwise; whether some NASA materials have ever capitalized these terms has literally never been a point of contention in the debate, at all. Though you're also IDHTing again in other ways: we've already been over the fact that "lunar module" is not a named spacecraft, but is a class of spacecraft all of which had more specific names.  — SMcCandlish ☏ ¢ 😼  05:02, 30 November 2018 (UTC)
 * Apparently the LEMs were considered spacecrafts, which, of course, makes sense because they took off from the Command Modules and were either tested in space (Apollo 5) or flew as a separate spacecraft to the Moon's surface six times and then flew back to the Command Module. An aside, I met the project leader of the team who built the LEM, he lived in a retirement hotel near my home awhile ago. Small world. Randy Kryn (talk) 12:37, 30 November 2018 (UTC)
 * Who said they weren't spacecraft?  — SMcCandlish ☏ ¢ 😼  11:30, 1 December 2018 (UTC)

As pointed out in the first section of the talk page, these are really 2 separate spacecraft types, with the LEM being the third one which is already not included here. Perhaps it might be more appropriate to discuss splitting the article in 2, anf leave the title discussions for a later date? - BilCat (talk) 11:43, 1 December 2018 (UTC)
 * I think the CSM is usually considered one spacecraft, with the SM being a part that gets discarded before reentry. The SM is never used alone, the way CM and LM are.  Dicklyon (talk) 16:12, 1 December 2018 (UTC)
 * As for the suggestion from way back then, I'm OK with that, as long as we get the case fixed. Dicklyon (talk) 16:19, 1 December 2018 (UTC)
 * I'd support replacing the slash with " and ", but I think that should be a separate RM after this one completes. They are different issues with different considerations. I doubt I'd support splitting the article into CM and SM, per Dicklyon (although I never say "never"). ― Mandruss  ☎  20:17, 1 December 2018 (UTC)
 * Not me. We're back to "what did NASA call it"? (And my reading, which I confess isn't extensive, has always seen caps.) On no slash, AFAIK, NASA never said "Command and Service Module": it was always treated as a joint vehicle, except in ref its functions. WP should not, yet again, be creating a convention used nowhere else.  TREKphiler  any time you're ready, Uhura  03:47, 2 December 2018 (UTC)
 * Nowhere else except (at least) all of my five books on Apollo, listed above. As for NASA never said "Command and Service Module", NASA's website appears to disagree. We can debate the relative strengths of different evidence, but this is not a good place to make claims with no evidence at all to back them up. ― Mandruss  ☎  04:29, 2 December 2018 (UTC)
 * A search like this can shed light on what's in old docs, to refresh one's memory. I don't find the "slash" version back then; not sure when that came in, or when the caps started. Dicklyon (talk) 06:37, 2 December 2018 (UTC)
 * – have you had a chance to look at sources yet, so you can follow up on your desire to stay closer to how NASA originally did it, by supporting this move proposal? Dicklyon (talk) 21:31, 7 December 2018 (UTC)

More sources analyzed
See Talk:Apollo_8 for an analysis of all the sources cited in Apollo 8, a pretty big list. Lowercase module is the overwhelming majority. Dicklyon (talk) 04:43, 8 December 2018 (UTC)

Also let's look specifically at the sources this article was built from (I just editted out everything but the refs to make this snapshot so we refer to them by number):

Which ones use lowercase module, and which use uppercase? I've annotated all by number, with bold for the one that treats as proper name. Dicklyon (talk) 17:27, 8 December 2018 (UTC)

1. lowercase "the command module, service propulsion module"

2. lowercase "the command module" and "the lunar module"

3. lowercase "An Apollo service module mockup"

4. lowercase throughout (except in some table headings and where the acronyms are defined)

5. no modules

6. lowercase "the command module"; no service module

7. lowercae "the command and service module (CSM)"

8. lowercase the Apollo command and service modules and the lunar module"

9. uppercase "The Apollo Command Service Module" (but is Mark Wade's defunct astronautics.com website a reliable source?)

10. lowercase "command module"; mixed "service module" and "Service Module"

11. lowercase "the Apollo command and service modules", "command module", "service module", etc.; same astronautics.com site as 9, but different page

12. lowercase "within the service module" and "the command module computer (CMC)"; no others except caption ("Service Module Sectors") (I OCR'd it to search)

13. lowercase "The Apollo command service module"

14. lowercase (same doc as 13)

15. lowercase (same doc as 12)

16. lowercase "the command and service modules"

17. no "module"

18. can't find online

19. Skylab doc; uppercase "the Command Service Module (CSM)" and "Command Module (CM)"; nothing relevant to Apollo here

20. no source here

21. hard to search (protected so Acrobat won't OCR it) mostly tables and figures, not sentences

22. can't find source via Wayback Machine

23. lowercase "Apollo 11 command module Columbia" (but also capped in sub-head sentence)

24. lowercase "NASA's last Apollo command module"

25. lowercase "The Apollo command module"

26. lowercase "NASA's last Apollo command module"

And I didn't come across any that use the slashed "command/service" naming. Dicklyon (talk) 20:47, 8 December 2018 (UTC)

 * Compelling evidence. Thanks, Dicklyon. And yes, please remove the slash when the time comes. Tony (talk)  06:55, 11 December 2018 (UTC)

Getting rid of the slash
If nobody objects, I will replace the slash by "and" after this closes, unless the closer does. The slash is exceptionally rare in sources, and has no reason for being used in Wikipedia. Dicklyon (talk) 21:01, 10 December 2018 (UTC)

 * The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Pointless bold face
A user recently broke the 3RR on this page, undoing my removal of bold face from the text "Command Module" and "Service Module" in the lead section. They didn't bother to give any rationale for their reverting. The closest they came was a false claim that the MOS is generally ignored.

The WP:MOS says of bold face:
 * The most common use of boldface is to highlight the first occurrence of the title word/phrase of the article in the lead section. The title of the article is Apollo Command/Service Module, and that text appears in bold face.
 * This is also done at the first occurrence of a term (commonly a synonym in the lead) that redirects to the article or one of its subsections, whether the term appears in the lead or not. Neither are synonyms, though "Command Module" indeed redirects to the article. "Service Module" does not. However, the first occurrence of each of these phrases is in the very title of the article, "Apollo Command/Service Module", which is already in bold face in the first sentence.

So what reason is there to bold this text? For emphasis? Avoid using boldface for emphasis in article text. Because they are new terms? Avoid using boldface for introducing new terms. The only reason advanced by the user who broke the 3RR was essentially "just because".

When there is a clear unambiguous guideline, it should be followed (and when there is a clear unambigious rule like the 3RR, it should not be violated). Ignoring style guidelines, in general, makes articles look sloppy and amateurish. So there should be a very good reason to ignore them - such as, applying them would make the encyclopaedia look even more sloppy and amateurish than not applying them. Putting text in bold face just because you really want to is not a good reason. So, I suggest the clear and unambiguous guidelines be followed here, unless someone has an actual strong reason to override them. 46.208.152.45 (talk) 01:57, 1 December 2018 (UTC)
 * Generally as little bolding as possible at the opening, please. It very soon dilutes the meaning of the highlighting, and looks ugly. Andy Dingley, why are you being so dogged? Tony (talk)  08:00, 1 December 2018 (UTC)

 * The IP has been blocked for disruptive editing and socking. DNFT is probably good advice here. Once they've grown bored of this tangent, perhaps we can revisit the issue then? Thanks. - BilCat (talk) 08:42, 1 December 2018 (UTC)

 * If an IP-somebody has a problem with it, take it to MOS talk, or something. It may be a bit odd, in this instance, but it's not the only case where lead bolding is a bit odd, & this page is not the place to settle the matter     TREKphiler any time you're ready, Uhura  03:47, 2 December 2018 (UTC)

Verify the accuracy of the list of CMs and SMs
I spotted some errors in the "CSMs_produced" section for CMs and SMs -014, -017, -020 and corrected them based on some (IMO) decent sources. It would probably be a good idea to go through the rest of the list and fix any errors/add relevant details based on those sources. — Preceding unsigned comment added by AlexHajnal (talk • contribs) 05:15, 25 December 2018 (UTC)

Split
I think this article would benefit from a split. It would be much easier to write better articles if we treated them separately. --- C & C (Coffeeandcrumbs) 06:37, 26 July 2020 (UTC)
 * Weak oppose – I don't see the benefit of splitting this article. CSM is often treated as a single spacecraft rather than a part of a spacecraft. --Soumya-8974 talk contribs subpages 07:28, 2 August 2020 (UTC)
 * Oppose. The CSM is a single spacecraft. To the extent certain mechanisms are deserving of additional focus (as, for example, Apollo Docking Mechanism), they can be detailed in articles specific to those mechanisms. I could imagine, for example, an entire article on the Apollo service propulsion system. But we should not artificially split an article on a single spacecraft into two based on function. TJRC (talk) 18:03, 2 August 2020 (UTC)
 * Oppose. How exactly would the article benefit from a split? The Command Module was not designed to fly in space by itself for more than an hour or two at the reentry phase of missions; the combination was commonly known as an integrated spacecraft. JustinTime55 (talk) 15:28, 3 August 2020 (UTC)

what was the contents of the service module on apollo 11
I was wondering what the contents of the service module on apollo 11 where, particularly, the part where experiments and cameras are stowed, i did multiple searches but i couldnt find it. 85.97.28.38 (talk) 07:45, 28 November 2021 (UTC)
 * It sounds like you're talking about the orbital scientific instrument package, which was not carried until the last three missions, Apollo 15, 16, and 17. This was not carried on Apollo 11. JustinTime55 (talk) 22:10, 18 February 2022 (UTC)

Ringslot vs "ringshot" parachute
Ringslot is a descriptive term for a parachute, one whose slots are cut like rings. Ringshot is a typo. https://www.ebay.com/itm/223907191657 RPellessier | Talk 07:53, 5 August 2022 (UTC)

https://airborne-sys.com/wp-content/uploads/2016/10/aiaa-1999-1700_evolution_of_the_ringsail.pdf

See image: http://www.collectspace.com/review/spaceaholic/para/cmpilot_data-lg.jpg

See page 5: https://www.scribd.com/document/49197880/The-Apollo-Parachute-Landing-System

 * Thanks for providing sources. I found both terms on Google and couldn't tell which one is correct (must be a widespread error). Can you take the time to fix Apollo command and service module, and add "ringslot" to Parachute to eliminate future confusion, or should I? That will give something to wikilink in the Apollo article. JustinTime55 (talk) 10:43, 5 August 2022 (UTC)
 * I'm surprised Parachute doesn't even mention the ringsail, which as I understand your AIAA source paper is descended from the ringslot. JustinTime55 (talk) 10:49, 5 August 2022 (UTC)
 * I take it from the crickets, that the answer is no, you're too busy to fix this and document ringslot parachutes in Wikipedia. Sigh...I'm willing to roll up my sleeves, but you sound like you're a parachute expert, which I tagged Parachute as needing. JustinTime55 (talk) 21:27, 10 August 2022 (UTC)

Size of RCS thruster cluster
In the RCS section of the SM section, the article states that "Each quad assembly measured 8 by 3 feet (2.44 by 0.91 m)". What exactly does this refer to? It surely does not refer to each of the 4 thruster clusters, as 2.44m is nearly 2 thirds the entire diameter of the CSM, and from the picture at the top of the article it is clear that a single thruster cluster is far smaller than that. Nebisan (talk) 18:25, 11 September 2022 (UTC)
 * That size figure obviously is the dimension of each of the four panels which hold the complete system, including the propellant and helium pressurant tanks. The term "quad" is usually used to refer to just the box and the four engine nozzles attached. It should be reworded to be less confusing. JustinTime55 (talk) 13:47, 12 September 2022 (UTC)
 * Or at least the 8-foot length does. Three feet must be the width of just the quad, as the engine nozzle is quoted as one foot diameter. I have a scale drawing, and can get the dimensions of the thruster quad box and the panel. I'll fix it when I get a chance. JustinTime55 (talk) 13:58, 12 September 2022 (UTC)
 * In fact: each quad measures 33.6 inches long by 26.6 inches wide; each RCS panel measures 99.1 inches (8.25 feet) by 33.8 inches (2.82 feet). JustinTime55 (talk) 00:28, 13 September 2022 (UTC)

CSM-115 and CSM-115a
The current version of the page states that the CSM displayed with the Saturn V at JSC is CSM-115a. This is apparently a longstanding edit, and is sourced to Jim Gerard's A Field Guide to American Spacecraft. After some searching, I can find no other prominent sources for this claim, I believe it originates with the Field Guide and all other sources are copying it.

However, I've come to doubt the reliability of the Field Guide in this matter. The Field Guide states that the author originally read sections of a NASA publication, The Apollo Spacecraft: A Chronology, that had references to both CSM-115 and CSM-115a and interpreted this to mean they were two separate CSMs. But then, after restoration work 'conclusively proved' the command module at JSC was CSM-115a, he concluded the two CSMs were actually one and the same.

All of this, however, goes against a variety of official documentation. A 1970 report to congress clearly lists CSM-115 and CSM-115a separately. A 1972 report also lists them separately, and states that CSM-115a was structurally incomplete when it was placed into storage in Downey, CA. A 1977 report says that CSM-115 will sent to JSC for display with its Saturn V and CSM-115a will be temporarily transferred to the Japan Science Society for an exhibit. The March 1978 listing of major Apollo/Skylab end items says that CSM-115 will be transferred to JSC in April 1978, and that the location of CSM-115a was unknown at that time but believed to be Japan. Finally, this article on Skylab B cites a 1993 NASA report stating that CSM-115 is on display at JSC, and CSM-115a's location is still unknown.

All of which is to say that the Field Guide's statement that CSM-115 and CSM-115a are the same vehicle is demonstratively false, and its claim that CSM-115a is on display at JSC is questionable. The restoration it speaks about is most likely the 2005 one, but there isn't any discussion of that discovery in news coverage. Unfortunately I cannot find any official reference to the CSM at JSC post-2005, which would confirm or deny this occurred. However, a 2015 Ars Technica describing an official tour of JSC states that the CSM on display is CSM-115.

Given the dearth of evidence that CSM-115a is on display at JSC, and the large amount of evidence that CSM-115 is, I've changed to article to state that fact. Voteins (talk) 21:31, 28 June 2023 (UTC)

Jettison the heat shield
Hi there! An excellent article which I am translating into Afrikaans. In the subsection Forward Compartment the author stated the heat shield get jettisoned at 25,000 feet and in the section Earth Landing System he stated at 24,000 feet. Not a big issue looking at the bigger picture but it is there. Or is roughly at that height? Regards from South Africa. Oesjaar (talk) 06:57, 29 August 2023 (UTC)

Service Propulsion Module image
The image in this section labelled "Engineers at Arnold Air Base with an Apollo service module engine" does not actually depict an SPS engine and the source gallery doesn't identify it as such. It appears to be an LR91 engine for the Titan I missile. 121.99.224.5 (talk) 00:24, 27 May 2024 (UTC)

Citation 13 doesn't work
correct link: https://ntrs.nasa.gov/api/citations/19690029435/downloads/19690029435.pdf Ogurecheck (talk) 12:17, 11 June 2024 (UTC)

title: Talk:Apollo command and service module


text:
Tullamore, New South Wales

Tullamore is a small town in Parkes Shire in the Central West of New South Wales, Australia. At the, Tullamore had a population of 369.

It lies in wheat-growing country. Tullamore has a railway station on the Bogan Gate–Tottenham Branch line. It is served by a newly constructed medical centre and a K-12 central school. Tullamore is home to the Tullamore Irish Festival, which is held each Easter long weekend.

Tullamore is the first town mentioned in the original (Australian) version of the song "I've Been Everywhere".

History
The area known as Tullamore was first settled as "Bullock Creek" in 1870. The post office opened under that name on 1 April 1890. It was then renamed Gobondery. In 1895 Jim Tully, whose family came from Tullamore in Ireland, built a hotel and called it "Tullie's Exchange Hotel". The Kerley family, also from the Tullamore area in Ireland, settled on a nearby property and called it Tullamore Station. It is believed that the town obtained its name from this property. The post office was officially renamed "Tullamore" in 1895.

Tullamore Show Grounds
The Tullamore Show Grounds on Cornet Street hosts the annual Tullamore Show each August.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Tullamore, New South Wales


text:
Model predictive control

Model predictive control (MPC) is an advanced method of process control that is used to control a process while satisfying a set of constraints. It has been in use in the process industries in chemical plants and oil refineries since the 1980s. In recent years it has also been used in power system balancing models and in power electronics. Model predictive controllers rely on dynamic models of the process, most often linear empirical models obtained by system identification. The main advantage of MPC is the fact that it allows the current timeslot to be optimized, while keeping future timeslots in account. This is achieved by optimizing a finite time-horizon, but only implementing the current timeslot and then optimizing again, repeatedly, thus differing from a linear–quadratic regulator (LQR). Also MPC has the ability to anticipate future events and can take control actions accordingly. PID controllers do not have this predictive ability. MPC is nearly universally implemented as a digital control, although there is research into achieving faster response times with specially designed analog circuitry.

Generalized predictive control (GPC) and dynamic matrix control (DMC) are classical examples of MPC.

Overview
The models used in MPC are generally intended to represent the behavior of complex and simple dynamical systems. The additional complexity of the MPC control algorithm is not generally needed to provide adequate control of simple systems, which are often controlled well by generic PID controllers. Common dynamic characteristics that are difficult for PID controllers include large time delays and high-order dynamics.

MPC models predict the change in the dependent variables of the modeled system that will be caused by changes in the independent variables. In a chemical process, independent variables that can be adjusted by the controller are often either the setpoints of regulatory PID controllers (pressure, flow, temperature, etc.) or the final control element (valves, dampers, etc.). Independent variables that cannot be adjusted by the controller are used as disturbances. Dependent variables in these processes are other measurements that represent either control objectives or process constraints.

MPC uses the current plant measurements, the current dynamic state of the process, the MPC models, and the process variable targets and limits to calculate future changes in the dependent variables. These changes are calculated to hold the dependent variables close to target while honoring constraints on both independent and dependent variables. The MPC typically sends out only the first change in each independent variable to be implemented, and repeats the calculation when the next change is required.

While many real processes are not linear, they can often be considered to be approximately linear over a small operating range. Linear MPC approaches are used in the majority of applications with the feedback mechanism of the MPC compensating for prediction errors due to structural mismatch between the model and the process. In model predictive controllers that consist only of linear models, the superposition principle of linear algebra enables the effect of changes in multiple independent variables to be added together to predict the response of the dependent variables. This simplifies the control problem to a series of direct matrix algebra calculations that are fast and robust.

When linear models are not sufficiently accurate to represent the real process nonlinearities, several approaches can be used. In some cases, the process variables can be transformed before and/or after the linear MPC model to reduce the nonlinearity. The process can be controlled with nonlinear MPC that uses a nonlinear model directly in the control application. The nonlinear model may be in the form of an empirical data fit (e.g. artificial neural networks) or a high-fidelity dynamic model based on fundamental mass and energy balances. The nonlinear model may be linearized to derive a Kalman filter or specify a model for linear MPC.

An algorithmic study by El-Gherwi, Budman, and El Kamel shows that utilizing a dual-mode approach can provide significant reduction in online computations while maintaining comparative performance to a non-altered implementation. The proposed algorithm solves N convex optimization problems in parallel based on exchange of information among controllers.

Theory behind MPC
MPC is based on iterative, finite-horizon optimization of a plant model. At time $$t$$ the current plant state is sampled and a cost minimizing control strategy is computed (via a numerical minimization algorithm) for a relatively short time horizon in the future: $$[t,t+T]$$. Specifically, an online or on-the-fly calculation is used to explore state trajectories that emanate from the current state and find (via the solution of Euler–Lagrange equations) a cost-minimizing control strategy until time $$t+T$$. Only the first step of the control strategy is implemented, then the plant state is sampled again and the calculations are repeated starting from the new current state, yielding a new control and new predicted state path. The prediction horizon keeps being shifted forward and for this reason MPC is also called receding horizon control. Although this approach is not optimal, in practice it has given very good results. Much academic research has been done to find fast methods of solution of Euler–Lagrange type equations, to understand the global stability properties of MPC's local optimization, and in general to improve the MPC method.

Principles of MPC
Model predictive control is a multivariable control algorithm that uses:
 * an internal dynamic model of the process
 * a cost function J over the receding horizon
 * an optimization algorithm minimizing the cost function J using the control input u

An example of a quadratic cost function for optimization is given by:

 * $$J=\sum_{i=1}^N w_{x_i} (r_i-x_i)^2 + \sum_{i=1}^M w_{u_i} {\Delta u_i}^2$$

without violating constraints (low/high limits) with

 * $$x_i$$: $$i$$th controlled variable (e.g. measured temperature)
 * $$r_i$$: $$i$$th reference variable (e.g. required temperature)
 * $$u_i$$: $$i$$th manipulated variable (e.g. control valve)
 * $$w_{x_i}$$: weighting coefficient reflecting the relative importance of $$x_i$$
 * $$w_{u_i}$$: weighting coefficient penalizing relative big changes in $$u_i$$

etc.

Nonlinear MPC
Nonlinear model predictive control, or NMPC, is a variant of model predictive control that is characterized by the use of nonlinear system models in the prediction. As in linear MPC, NMPC requires the iterative solution of optimal control problems on a finite prediction horizon. While these problems are convex in linear MPC, in nonlinear MPC they are not necessarily convex anymore. This poses challenges for both NMPC stability theory and numerical solution.

The numerical solution of the NMPC optimal control problems is typically based on direct optimal control methods using Newton-type optimization schemes, in one of the variants: direct single shooting, direct multiple shooting methods, or direct collocation. NMPC algorithms typically exploit the fact that consecutive optimal control problems are similar to each other. This allows to initialize the Newton-type solution procedure efficiently by a suitably shifted guess from the previously computed optimal solution, saving considerable amounts of computation time. The similarity of subsequent problems is even further exploited by path following algorithms (or "real-time iterations") that never attempt to iterate any optimization problem to convergence, but instead only take a few iterations towards the solution of the most current NMPC problem, before proceeding to the next one, which is suitably initialized; see, e.g.,.. Another promising candidate for the nonlinear optimization problem is to use a randomized optimization method. Optimum solutions are found by generating random samples that satisfy the constraints in the solution space and finding the optimum one based on cost function.

While NMPC applications have in the past been mostly used in the process and chemical industries with comparatively slow sampling rates, NMPC is being increasingly applied, with advancements in controller hardware and computational algorithms, e.g., preconditioning, to applications with high sampling rates, e.g., in the automotive industry, or even when the states are distributed in space (Distributed parameter systems). As an application in aerospace, recently, NMPC has been used to track optimal terrain-following/avoidance trajectories in real-time.

Explicit MPC
Explicit MPC (eMPC) allows fast evaluation of the control law for some systems, in stark contrast to the online MPC. Explicit MPC is based on the parametric programming technique, where the solution to the MPC control problem formulated as optimization problem is pre-computed offline. This offline solution, i.e., the control law, is often in the form of a piecewise affine function (PWA), hence the eMPC controller stores the coefficients of the PWA for each a subset (control region) of the state space, where the PWA is constant, as well as coefficients of some parametric representations of all the regions. Every region turns out to geometrically be a convex polytope for linear MPC, commonly parameterized by coefficients for its faces, requiring quantization accuracy analysis. Obtaining the optimal control action is then reduced to first determining the region containing the current state and second a mere evaluation of PWA using the PWA coefficients stored for all regions. If the total number of the regions is small, the implementation of the eMPC does not require significant computational resources (compared to the online MPC) and is uniquely suited to control systems with fast dynamics. A serious drawback of eMPC is exponential growth of the total number of the control regions with respect to some key parameters of the controlled system, e.g., the number of states, thus dramatically increasing controller memory requirements and making the first step of PWA evaluation, i.e. searching for the current control region, computationally expensive.

Robust MPC
Robust variants of model predictive control are able to account for set bounded disturbance while still ensuring state constraints are met. Some of the main approaches to robust MPC are given below.

 * Min-max MPC. In this formulation, the optimization is performed with respect to all possible evolutions of the disturbance. This is the optimal solution to linear robust control problems, however it carries a high computational cost. The basic idea behind the min/max MPC approach is to modify the on-line "min" optimization to a "min-max" problem, minimizing the worst case of the objective function, maximized over all possible plants from the uncertainty set.
 * Constraint Tightening MPC. Here the state constraints are enlarged by a given margin so that a trajectory can be guaranteed to be found under any evolution of disturbance.
 * Tube MPC. This uses an independent nominal model of the system, and uses a feedback controller to ensure the actual state converges to the nominal state. The amount of separation required from the state constraints is determined by the robust positively invariant (RPI) set, which is the set of all possible state deviations that may be introduced by disturbance with the feedback controller.
 * Multi-stage MPC. This uses a scenario-tree formulation by approximating the uncertainty space with a set of samples and the approach is non-conservative because it takes into account that the measurement information is available at every time stage in the prediction and the decisions at every stage can be different and can act as recourse to counteract the effects of uncertainties. The drawback of the approach however is that the size of the problem grows exponentially with the number of uncertainties and the prediction horizon.
 * Tube-enhanced multi-stage MPC. This approach synergizes multi-stage MPC and tube-based MPC. It provides high degrees of freedom to choose the desired trade-off between optimality and simplicity by the classification of uncertainties and the choice of control laws in the predictions.

Commercially available MPC software
Commercial MPC packages are available and typically contain tools for model identification and analysis, controller design and tuning, as well as controller performance evaluation.

A survey of commercially available packages has been provided by S.J. Qin and T.A. Badgwell in Control Engineering Practice 11 (2003) 733–764.

MPC vs. LQR
Model predictive control and linear-quadratic regulators are both expressions of optimal control, with different schemes of setting up optimisation costs.

While a model predictive controller often looks at fixed length, often graduatingly weighted sets of error functions, the linear-quadratic regulator looks at all linear system inputs and provides the transfer function that will reduce the total error across the frequency spectrum, trading off state error against input frequency.

Due to these fundamental differences, LQR has better global stability properties, but MPC often has more locally optimal[?] and complex performance.

The main differences between MPC and LQR are that LQR optimizes across the entire time window (horizon) whereas MPC optimizes in a receding time window, and that with MPC a new solution is computed often whereas LQR uses the same single (optimal) solution for the whole time horizon. Therefore, MPC typically solves the optimization problem in a smaller time window than the whole horizon and hence may obtain a suboptimal solution. However, because MPC makes no assumptions about linearity, it can handle hard constraints as well as migration of a nonlinear system away from its linearized operating point, both of which are major drawbacks to LQR.

This means that LQR can become weak when operating away from stable fixed points. MPC can chart a path between these fixed points, but convergence of a solution is not guaranteed, especially if thought as to the convexity and complexity of the problem space has been neglected.

title: Model predictive control


text:
Talk:Baseball rules

North American focus
This page says that "Baseball around the world" follows certain rules, but it only seems to discuss North American baseball. I'm curious as to what rules are used in Japan. I know, for example, that in Japan they always have designated hitters (like in the AL of american MLB), and that they only play a fixed number of extra innings (6, I think, though I may be wrong). I'm not that familiar with Japanese baseball rules, but perhaps someone could add this information, or at least revise this article to point out that there are other sets of baseball rules in use around the world.\ GJL 02:26, Oct 25, 2004 (UTC)
 * How's that? Feel free to edit further.  I think the two areas you mentioned are the only significant differences in Japanese baseball.  --Locarno 14:01, 25 Oct 2004 (UTC)

Balls and strikes (baseball)
I came across the article Balls and strikes (baseball) earlier, and it seems it would be better suited as a sub-category on this article instead. So I have proposed a merger on this page, and the prior, suggesting the info on that page be merged somehow into this one. Thoughts? Objections? raven1977 (talk) 04:33, 2 October 2008 (UTC)
 * I haven't seen any response on this yet, but I was looking at this article to see where the contents of the other article would go. I would think Baseball_rules would be a good place for it. I'll be glad to do this content merge myself, by the way. I just don't want to go to the effort if there are strong objections to it. raven1977 (talk) 17:38, 11 October 2008 (UTC)

"Baseball rules" ?
This article is mostly NOT about the rules of baseball. It's about typical strategies and other points, which partly result from the rules. Take this snippet from "The Infielders":

''"The first baseman's job consists largely of making plays at first base on ground balls hit to the other infielders. When an infielder picks up a ball from the ground hit by the batter, he must throw it to the first baseman who must catch the ball and maintain contact with the base before the batter gets to it for the batter to be out. The need to do this quickly often requires the first baseman to stretch one of his legs to touch first base while catching the ball simultaneously. The first baseman must be able to catch the ball very well and usually wears a specially designed mitt. The first baseman fields balls hit near first base. The first baseman also has to receive throws from the pitcher in order to tag runners out who have reached base safely. The position is less physically challenging than the other positions, but there is still a lot of skill involved. Infielders don't always make good throws to first base, so it is the first baseman's job to field any ball thrown toward him cleanly. Older players who can no longer fulfill the demands of their original positions also often become first basemen."''

"must throw it to the first baseman" and "must catch the ball" are NOT rules of the game. "Must throw it to the first baseman" seems not even to be necessarily the right strategy - with a single runner on third base, throwing to the pitcher is surely more likely?

The rest is all interesting material about the role of the first baseman, but not part of the rules of the game.

Suggestion: delete nothing, but shuffle material (probably into at least two different articles) so that the rules and common strategies are dealt with separately. PeterBiddlecombe (talk) 11:18, 6 April 2009 (UTC)

Simplified Rules
A couple of years ago there was a page called "Simplified Baseball Rules". I worked with a fellow from another country who became a friend of mine and wanted to learn the rules of baseball. This 'simplified Rules' page was the perfect resource for him. Now, there is another friend in the same situation, but I look and see it has been aggregated into this all-too-complicated page that is completely unaccessible to someone who is first coming into contact with the game. "Simplified Baseball Rules" definitely has a place and should be dis aggregated. —Preceding unsigned comment added by 71.202.248.148 (talk) 07:04, 29 July 2009 (UTC)
 * I agree with you. The funny thing is that THIS page is the one that shouldn't exist. The only people who would enjoy reading this or could get anything from it are people who already have a pretty good understanding of the rules, and are either A: coming around to make sure they can't find a mistake, or B: looking for a really specific rule that they may as well be looking in the MLB rulebook to find. This page is basically an attempt to give a less complete version of the MLB rulebook, and add some strategies, and sometimes incorrectly state the strategies as a rule. The simplified version of the rules should be this page. This is a perfect example of pedantry making a page completely useless to those who might need it! Dancindazed (talk) 22:21, 21 September 2011 (UTC)

Forfeit rules
In the middle of the pitching section, someone (revision 307263384 by 67.249.244.64 (talk)) added this fragment:

 * If a team is to forfeit with three outs or less remaining the pitcher must continue to pitch the remainder of the game, to accumulate a fully compromised game

I don't quite understand what this is trying to say (what does "accumulate a fully compromised game" mean?), but I'm pretty sure that whatever it's saying is wrong.

The forfeit rules (4.16-4.18) of the OBR say nothing about forcing a team to complete a game after forfeiting.

Three of the five MLB forfeits since 1970 occurred with fewer than 3 outs remaining, and the pitcher was not forced to continue pitching.

Finally, how could such a rule be enforced if it did exist? All modern forfeits are due either to the game becoming unplayable, or to refusal of one team to play as a protest. In early days, there were a few forfeits because a team could no longer field 9 players, but again, if they're forfeiting because they don't have a pitcher, how could the pitcher be forced to complete the game?

I skimmed through the OBR for anything remotely similar, thinking it was just a poorly-articulated (and probably truncated--notice the missing period) attempt to say something true and relevant, but finally gave up and deleted it. (And nobody forced me to pitch the last 3 innings of the article.) --166.134.228.43 (talk) 08:10, 1 May 2010 (UTC)

"Tie goes to the runner"
Didn't see "tie goes to the runner" mentioned—seems like a basic addition (even if it's to say it isn't a rule, though commonly thought to be one). czar ♔  13:47, 12 October 2013 (UTC)

remember the Detroit Tigers of 1968
Notice this comment about shortstop:

"This position is the most demanding defensively, so a good shortstop doesn't need to necessarily be a good batter."

In 1968, Ray Oyler, regarded as a slick fielder but not a good hitter, was playing shortstop for the Tigers. Late in the season, the manager (Mayo Smith), having 4 good-hitting outfielders, experimented with one of those outfielders (Mickey Stanley) switched to shortstop. Ray Oyler remained available if needed in the game for defensive purposes. — Preceding unsigned comment added by 128.63.16.20 (talk) 16:18, 29 April 2015 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 1 one external link on Baseball rules. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20070628170010/http://www.ncaa.org/library/rules/2006/2006_baseball_rules.pdf to http://www.ncaa.org/library/rules/2006/2006_baseball_rules.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.— InternetArchiveBot  (Report bug) 23:53, 27 October 2016 (UTC)

Equipment
The article would be better if it has some explicit information about the requirements for the playing field, bat, gloves and ball. Presumably the dimensions and materials of these are subject to regulation. Qemist (talk) 07:53, 11 April 2017 (UTC)

Merger proposal
I propose that Safe (baseball) be merged (or possibly blank-and-redirected) into Baseball rules. "Safe" is already described on this page, and does not need a page to itself. JarmihiGOCE (talk) 15:45, 6 July 2017 (UTC)
 * Oppose: my view is that there is enough to be said about the art and culture of calling safe which wouldn't fit within a rules-focussed page. So, I'd improve rather than merge. Klbrain (talk) 08:46, 6 November 2018 (UTC)

Pace of the game
New rules will go into effect this upcoming MLB season. I know this page isn't MLB-specific, but it may be worthing adding to the "Pace of the game" section.Pistongrinder (talk) 19:25, 19 February 2018 (UTC)

Substitute Runner
Can a batsman that hits the ball and makes it to first base. Call a substitute Runner to run the other bases? 111.220.239.121 (talk) 22:01, 25 April 2022 (UTC)

title: Talk:Baseball rules