The Planning Game

We don't know much, but we do know enough to start thinking about the product. We can think about boundaries, for instance. What is our job, and what is the robot team's?

From a certain point of view, I think our job is easy. We will write a program that sends signals to the robot. We will plan with the robot team to coordinate what each signal is going to do. For example, a simple text interface might look something like the following:

Options
1. Move Forward
2. Move Backward
3. Turn Right
4. Turn Left
5. Stop

Please enter your choice:

So on our interface program, the user types "1" and hits Enter. Our program sends a "1" signal to the robot program, and the robot program acts accordingly (their job). There are plenty of potential challenges, but we won't know how real those challenges are until we learn more about the tools we'll have access to. For instance, sending a Bluetooth wireless signal to the robot might be very easy if we have the right tools, or very hard if we don't.

Sending wireless signals over Bluetooth aside, I am wondering what platform we will be running our interface program on. Graham suggested that we might write the interface using Visual Basic: I don't know if he was serious or not, but it might be a good idea if we want a GUI.

The robot that we're developing for is known as a "Mindstorms NXT robot." There is a lot of information about it available on the web, including software and source code, for example. ~David Sharpe

I believe we should use an interface, but we'll know more once we get the lectures on bluetooth programming. One huge bonus to using VB would be fast/easy programming of things like queue's (for commands, lets say you want to move the robot forward 10 increments and left then right etc etc). For that sort of system to work we would need to coordinate with the robot team and set up some global standards (in this case, how much the robot should move in said direction). Also worth considering, do we need to make the robot able to rotate a certain number of degrees? If so, VB would make it easy to represent a rotation tool. Just some food for thought. ~Dave Fawcett

A GUI would make for a more impressive final product, and because I've never made a GUI before, I like the idea of Visual Basic streamlining the process. A command-line interface might make a good prototype, but maybe our first prototype should incorporate a GUI anyhow, to save us the trouble later.

As for robot movement, I suggest that movement should simply be either "On" or "Off." That way, we'll have greater flexibility (e.g. what if we want the robot to move less than "1 movement increment"). Consider a car's movement: imagine how awkward it would be to steer if every time you hit the gas pedal, the car moved five meters forward!

You mentioned queues though, and that is something I've been wondering about too. Should control of the robot be active, like a videogame, or instruction/queue based (e.g. Forward 5, Left 90d, Forward 2)? This might end up being one of the key questions of design, active or passive control. ~David Sharpe

If we choose to use Visual Basic there is a resource that gives a step by step guide for getting Visual Basic source code to execute on the robot here. The examples give lots of interesting ideas as to how we can implement movement. If the control of the robot is interactive, I would lean toward tying the robot movement to up/downstrokes of a key or mouse button (ie: while the left mouse button is held down the robot moves forward but when it is released the robot stops.)

Also in most of the examples, it appears the base station is directly telling the robot what to do through preprogrammed function calls, for example:

PBrickCtrl.SetFwd MOTOR_C // move motor to the forward direction

PBrickCtrl.On MOTOR_C // turn the motor on

If such calls are already available for us, I'm not sure I understand what additional functionality the robot team will need to program as it seems these functions (a list is available here) would suffice for the project requirements... ~Brett Peake

Well, now that Robert has posted the project requirements, we certainly have a better idea of what he wants. He does mention active control ("the interaction with the robot may be also real-time"), but as most of his project requirements concern passive control, that is motion plans, I assume we're expected to implement it.

Please post your availability if you haven't already. The project plan is due in a week, so we had better get cracking.

I'm not sure, Brett, but that list of functions might be outdated. RCX was the first generation of Mindstorms robot; NXT, the generation we're using, is the latest. Lego Mindstorms on Wikipedia. ~David Sharpe

RCX vs. NXT

 

---

 

My Visual Studio download is now 80% done, and I'm recharging the NXT brick after two months of non-use. I've successfully installed the Bluetooth adapter, not that that was any challenge, but I'm looking forward to establishing a connection. I don't know what I'm going to do if Visual Studio doesn't work out for me--I can't imagine why it wouldn't, but it's possible--maybe I'll try "Visual Basic Express" or something? I hear it's "easy" and "fun" to learn. ~DS

 

This is painful. I can't get the Lego Software "MINDSTORMS Edu NXT" to connect to the NXT brick using the Bluetooth dongle we were given. My research shows that it may be an incompatability between the software and the dongle, not an incompatability between the dongle and the brick, so I'm still hoping that Visual Studio will be able to send messages to the brick. I'll be able to test that theory in about 20 hours. ~DS

 

5 hours to endgame (i.e. download complete). ~DS

 

Success! Commencing annoying beeping of various pitches. ~DS