R/C Naval Combat

Engage your imaginations, those who have one:

http://www.meetrovio.com

Available at Wally World for
Interesting opportunities abound:

- "Raffle"/auction time slots to allow guest control as a club fundraiser.
- "Live" battle-cam views on a club web site (stored "highlights", too; YouTube fodder).
- Enable access to disabled persons who otherwise might have trouble using standard R/C gear.

JM

Interesting... That is certainly do-able. Hmmm. Web controlled Tirpitz.

Neat! Officially.

Very cool. Might be cool to implement

Try it and let us know how it works.

I seem to remember a web site in Japan which does web controlled rc tank battles using the tamiya 1/16 scale tanks. I'll see if I can find the web site again after I get home tonight (USA morning).

I've seen something simmilar before. an individual was building a 1/144 scale yamato for big gun combat and was using a wifi card hooked up to a lyxmotion controller and was using his laptop as the controller. I'll find the web page shortly

all right the link is: http://flickr.com/photos/67912578@N00/236890279/ this seems that it would be an awsome setup if one could get it to work

In my R/C combat Tank group we have a person who runs his Tank with a computer on his back. We can him Rocketman due to the large pack on his back.

Marty

trick is how to make it waterproof. I have one of those linksys routers. Maybe I will give it a try as well.

I think we can pretty much stipulate that the technology is available right now. Waterproofing (& shockproofing as well) of shipboard systems is a given - not that it can be ignored; it can't be.

Knowing that something can be done is one thing. Doing something with it that's actually useful is something else again. Is it enough of a reason to do something like control a ship via web just "because it's cool"? Is there some real, practical use for the technology or is it just good for the sake of "geeks"?

That's what I'm hoping to find out: What are some useful applications of the technology?

JM

How bad is the controller's lag?

One use... Remote viewing. You could visit other people's battles, record your own, or show off a 'battle in progress'.

quote:

---

Originally posted by JustinScott

One use... Remote viewing. You could visit other people's battles, record your own, or show off a 'battle in progress'.

---

I'm a little disappointed that there haven't been more responses in this thread. So, to try to move things along a little more, let's pick on Justin! (Sorry, nothing personal; you're just unlucky enough to have posted something useful!)

Show of hands: Who's familiar with Root Cause Analysis (RCA)?

RCA is a general class of problem-solving methods most often used to identify why something failed. Often most visibly, it's used to figure out why something very bad happened, like an airplane crash, etc. In such cases, the larger problem is pretty obvious: It came down a little too hard, and/or in the wrong place. RCA techniques are used to define the problem in greater detail. The objective is to reduce a large, complex problem into a collection of relatively simple ones, & from that determine what specific event(s) are/were the primary or root causes of the problem. In other words, if not for _____, the problem would not have happened.

So, what does this have to do with web-based control of ships, or R&D at all, for that matter? If there is no problem, then what is the problem?

RCA techniques can be used for purposes other than strictly finding the basic reasons for disasters. Several of the basic RCA methods can be used to uncover the "roots" behind our thinking, & expose our reasons for making some of the choices that we make. Everything we do, we do to solve some problem. Now, a "problem" doesn't necessarily have to mean something bad; it's just something to be solved. The classic example is a math problem. A math problem doesn't necessarily represent something bad that must be overcome. We solve it to achieve some particular goal.

What I'd like to do is use a simple RCA technique to explore the chain of problems & solutions that lead to "Remote viewing" as a solution. The technique that I'd like to propose is the "5 Whys". Basically, we just keep asking "Why?" until we get back to the root (simplest possible) explanation of how it is that we ended up at the point we did. We'll keep asking the question "Why?" iteratively (i.e. over & over) until we get to the bottom. 5 times is just a rule-of-thumb; it might take more, or it might take less. Once we get to the bottom, we may very well find that there are many other "paths" that could be followed back upward, to try to solve the same basic, root problem(s). Each of those paths could potentially lead into more R&D problems for people to solve, fodder for more R&D topics to discus, & more fun for all concerned!

So, without further ado, who can answer: Why remote viewing?

Another way to express it is, what is the problem , to which "remote viewing" is a solution? What, exactly, might somebody want to achieve, that could be achieved by remote viewing?

Answering that is just the start. We'll repeat the question "Why?" for all the answers. Then, ask "Why?" all over again of those answers, repeating the process until we find the true, root reason behind it all. I, for one, am pretty interested to see where this all leads & what might eventually come out of it all.

Up front, let's eliminate "Because we can" as a potential reason "Why?" we might want to do anything. Unless, that is, somebody really wants to go there. Pretty much any technological solution can potentially lead back to "Because we can" as one of many reasons why it's done (sometimes that's enough for a true "geek" [;)]). Therefore, "Because we can" potentially applies to any problem, & once its roots have been defined, that definition can apply universally.

JM

remote viewing
why
to record the event from the boat's view point, without having an onboard recorder
why
to place it on youtube & to reduce the amount of electronics on the boat
why
to bring attention to the hobby & to reduce potential loss & size and weight considerations
why
to bring more people to the hobby & to save cost & to have a feasible ship design
why
to have more friends to play with & to have more money to apply elsewhere & to be able to fight




Wow, that got out of hand.

quote:

---

Originally posted by JustinScott

remote viewing
why
to record the event from the boat's view point, without having an onboard recorder
why
to place it on youtube & to reduce the amount of electronics on the boat
why
to bring attention to the hobby & to reduce potential loss & size and weight considerations
why
to bring more people to the hobby & to save cost & to have a feasible ship design
why
to have more friends to play with & to have more money to apply elsewhere & to be able to fight

Wow, that got out of hand.

---

Yeah, that can happen, especially when you try to jump to the end so quickly. The point isn't to try to blow through the exercise fast, it's to thoroughly consider why we're wanting to do a thing. But I didn't state that up front, so that's my fault.

I was also hoping that this would be a group effort, with several points of view represented at each stage.

This particular collection illustrates how problem/solution chains can "branch". A given problem may have many possible solutions. Also, it can be a real plus if a solution can address multiple problems. All the possibilities can really get out of hand if it's not organized. It's a lot like keeping topics in threads on this forum. Imagine if there weren't topics, & all postings were just lumped together. Even with the topical organization, it's a challenge sometimes to keep it all straight. That's another reason to go slow, 1 "level" at a time.

It's a good idea to validate chains of cause/effect, problem/solution, etc., too. The easiest way to do this is to retrace the chain "forward". Everything should make sense regardless of which way we "read" the chain. In other words, if your lower-level problem objectives are well stated, it should be reasonable to follow the logic forward & reach the same solution(s) as we started with. So, let's work the chain forward & see where it goes.

We need to decide whether or not ALL of the low-level problems are mutually inter-dependent. That is, must we try to solve ALL of them together, or is it OK to try to solve EACH of them individually? Whatever choice we make, we should apply at all levels. Making them inter-dependent is going to simplify the process considerably. "To have more money to apply elsewhere" could go in a lot of different directions, for example. Normally, I'd probably want to consider each low-level problem separately, but for the sake of simplicity let's assume that they're all inter-dependent.

So: Can we logically start with "to have more friends to play with & to have more money to apply elsewhere & to be able to fight", through each successive level, & end up with "remote viewing"?

I'm having a hard time making it work. Most of the problem, I think, is because the terms are very loosely stated. That's largely a function of trying to blow through the process too quickly. Once an incomplete definition is accepted at any level, any subsequent reference to it is going to be flawed, even if it happens to be well-defined itself.

Example of a loosely-defined problem/objective: "To have more friends to play with" as a low-level objective. What, exactly, does that mean? How might I know if I've solved/achieved it? Is 1 more enough? If I have 4 friends now, would a 5th satisfy the objective? Since it says "friends" (plural), maybe that means 2. Assuming some project is taken on eventually, to try to achieve the objective of having 2 more friends to play with, at some point decisions will need to be made regarding cost-effectiveness. This might be a lot of work & cost a lot of money, just to get 2 more people involved.

I hope everybody can see where I'm trying to go with this.

Let's see if we can back up a bit & pick this apart 1 level at a time. We might want to further define our top-level solution: Remote viewing. Are we all clear on exactly that means? To me, I'm thinking something along the lines of being able to see (i.e. visually; what about audio or other means of communication?) a battle without actually having to attend one.

I'll pick 1st. Others, feel free to join in as well.

Q: Why remote viewing?

A: To record the event from the boat's viewpoint, without having an onboard recorder.

Here are problems that I see with the answer:

1. Where does "record" come from? How do we get from "record the event" as a problem to "remote viewing" as a solution? That seems backwards, to me. I don't see how something could get recorded, without having been viewed/viewable 1st.

2. "...from the boat's viewpoint" also doesn't follow, as a problem for which "remote viewing" is a viable solution. A big part of the problem might be with where we're starting. Although the name of this topic is "Web-Based Control", the link from there to "remote viewing" may not be as well-defined as it should be. There isn't a good, logical path leading from "...from the boat's viewpoint" through "remote viewing" to "web-based control". I think we need to fix that. "Web-based control" is the ultimate end solution to whatever our TBD collection of lower-level problems ends up being. I think maybe we should restart there.

3. "...without having an onboard recorder", again, is a problem that I don't see being solved by "remote viewing".

So, let's reset & start over again. The top-level solution (or event, if we were doing a RCA trying to find the cause of a plane crash, etc.) is: Web-based control. Does that need more work? Are we all clear & in agreement in terms of what's being controlled & what "remote" means? We might expand it to say control of a warship in a combat game, as well as include an action verb such as "provide", "allow", etc. The top-level question then becomes:

Why (provide) web-based control of a warship in a combat game?

Let's see how thoroughly we can answer this 1 question before going any further. We're in no hurry to get to the "bottom", so let's take our time. We've got all winter, at least. It's not like trying to be 1st to answer a trivia question; there's no "prize" for answering quickly. There are no "right" answers, either, but there is a proper methodology. No cutting corners. Instead of trying to do less, let's try to do more. Words are free, so feel free to use as many of them as we need to make sure we're expressing ourselves thoroughly & precisely. What we really want to do is to shake out a lot of different possibilities, in the hope that some of this might turn into ideas for people to develop later. Some things may seem obvious, but let's try not to assume anything. I've got my own ideas where this might lead, & I'm sure plenty of others do, too. But I don't want to just list my own predetermined conclusions, or anyone else's for that matter. I'm hoping that some people will be stimulated to think in some new ways, not just regurgitate what we think we already know. This is a voyage of discovery, after all, & we're not going to discover much if we think we've already seen everything.

JM

I know this seems to be a lot like the "BS" some of us have to do at work. Ask yourself this, though: Why do that ask you to do this sort of "BS" at work? Are they just making up something to do, for the fun & amusement of "Dogbert"? Do companies today have so much extra cash, that they can just ask people to spend time & effort for no good reason? Is efficiency so high, with costs so low & revenues so great, that they can afford to play "BS games"?

The reason is that development efforts need direction, & engineers aren't always the best people to provide it. There was a time when I never thought I'd utter such a thing, but "sales weenies" have a valuable role in the development of products.

When we talk about "Research and Development", it is the development of products that we are talking about, exactly, even if nothing ever goes into actual "production" & nobody ever makes a dime off of them.

When engineering-types are in charge of deciding what gets developed, you often get stuff that rates high on the "coolness" scale, but isn't very practical for everyday users. Web-based control of warships, while obviously cool, may or may not be practical for any reasonable purpose. That's what I hope to find, by drilling down: What are the core purpose(s)?

If all we want to do is "save money", we can save a heck of a lot of it by just not doing anything at all. I haven't kept track (some things, I'd just as soon not know), but I have no doubt that I've got somewhere between US$12-15,000 invested so far. I could have saved all that by never getting into R/C warship combat in the 1st place. Instead, I want to plow even more money in, but I'd like to be somewhat frugal about it. I know what I think, but it's more important to me to find out what others think (emphasis on "think ", not just recite).

Why (provide) web-based control of a warship in a combat game?

JM

I would offer one option.

How does one open up rc warship combat to those folks that are physically disabled to a degree that prevents them from being pond side... but still are able enough to control a computer and/or build at home...

interesting idea, but maybe far fetched. I think it might also lead to people only building ships and people only fighting them, which i believe isnt in the best interest of the hobby.

quote:

---

Originally posted by BoomerBoy17

interesting idea, but maybe far fetched. I think it might also lead to people only building ships and people only fighting them, which i believe isnt in the best interest of the hobby.

---

I disagree, whats wrong with that.

A group of people building ships for many other people to captain. I would have been their first customer.

I have been in the hobby for 2 years and have yet to get a ship on the water as I have had to learn how to work on ships with very little local support.

So bring on the Builders!!!

how will you learn to build a ship if everyone else does it for you? Then it'll be like RC airplane hobbies, just buy a kit and put it together. Not as much fun as actually building one.