locked
SOOOO easy... Help. RRS feed

  • Question

  •  

    I have Visual studio 2005 to run some of the canned demos with my NXT.

    I also had some luck with the VPL and the NXT. But now I want to dig deeper.

     

    I decided to try the most simple thing I could think of.

    I have a Microprocessor that has 1 LED and a button connected to it.

    If I send (RS232-9600baud 8-n-1) the ascii Charactor '1' then the LED turns on.

    if I send '0' the LED turns off.

     

    If I Push the button the Microcontroller sends a '1' back and when I let go it sends '0'.

    Thats all there is to my hardware.

    I can easily make my "Robot" work with Hyperterminal.

     

    My trouble is how to write a service to handle the communications.

    I have read 2 books

    Programming Microsoft Robotics studio - Sara Morgan  (Chapter 7)

    and

    Professional Microsoft Robotics Developer Studio -Kyle Johns & Trevor Taylor (Chapters 13 & 17)

    Both are very indepth but I am mostly a hardware person so the verbose 'manifests', 'contracts' and other

    contrsutcts seem to be very complicated.  I plan on re-reading them until this system sinks in but

    in order to get started fast I am willing to seek the consel of those more enlightened than myself.

     

    I understand that the complexity  has to do with multiple 'services' running in parallel.

    But until I get a mental map in my head of how this whoe thing fits together I am stumped.

    I am a very visual person and when people say, "Do I have to draw a Picture for you?"

    I say, "Yes, and I want it in color."

     

    Could someone point me to a 'Bare-bones' example that is similar to what I am trying to do.

     

    (I would not so no to a picture also, in color of course.)

     

    Thanks

     

    -Mike

     

    Wednesday, October 8, 2008 3:31 PM

Answers

  • Hi Mike,

     

    This question about talking to a serial port comes up from time to time. Sometime in the next couple of weeks I will try to put together an example. We are right in the middle of final testing for V2.0 at the moment, so I don't have any spare time.

     

    However, the Integrator and Hemisson robots in Chapter 17 of ProMRDS both use serial communications. You might be able to follow the code from these examples. It is reasonably generic (look in IntegratorControl.cs and/or HemissonControl.cs).

     

    The problem with providing an example of serial comms is that every device is different. I am not referring to the actual commands, but whether the device sends an acknowledge message, how it handles errors, whether it needs inter-character delays (like the Hemisson does), whether it sends a carriage return / linefeed at the end of a response, etc.

    It might seem like "send a character, get back a response" is a simple command structure, but there are many variations and very few devices can operate without some sort of parameters. So at the lowest level you will always have to write some code.

     

    Trevor

     

    Wednesday, October 8, 2008 4:11 PM

All replies

  • Hi Mike,

     

    This question about talking to a serial port comes up from time to time. Sometime in the next couple of weeks I will try to put together an example. We are right in the middle of final testing for V2.0 at the moment, so I don't have any spare time.

     

    However, the Integrator and Hemisson robots in Chapter 17 of ProMRDS both use serial communications. You might be able to follow the code from these examples. It is reasonably generic (look in IntegratorControl.cs and/or HemissonControl.cs).

     

    The problem with providing an example of serial comms is that every device is different. I am not referring to the actual commands, but whether the device sends an acknowledge message, how it handles errors, whether it needs inter-character delays (like the Hemisson does), whether it sends a carriage return / linefeed at the end of a response, etc.

    It might seem like "send a character, get back a response" is a simple command structure, but there are many variations and very few devices can operate without some sort of parameters. So at the lowest level you will always have to write some code.

     

    Trevor

     

    Wednesday, October 8, 2008 4:11 PM
  •  

    Thanks for getting back so fast Trevor,

     

    I fully appericate the 'No one answer' challenge.

    Every hardware interface I write is unique. It is amazing how many ways the 'wheel' can be re-invented.

     

    That is why I started with such a simple interface.   I remember the part of your book where you mentioned the debates over 'standard' bricks as well as other issues that tend to spark debate.

     

    While several different 'standards' may be in use, I was disipointed that none were included.

     

    I would have been happy with 2 different 'standards' offered as examples to contrast the different methods.

     

    I will review the code you mentioned and see if I can sift out how to turn my LED on and off.

     

    thanks

     

    -Mike

     

    Wednesday, October 8, 2008 4:30 PM
  • I'll just add my two cents. I can't tell you how important I think this issue is. It is the exact problem I struggled with for weeks (I still don't have it working perfectly). I think many people give up on MRDS because they can't get past this point.

     

    Examples of turning an LED on and off (setting or resetting a bit on a microcontroller) through a serial port and responding in any way to a pushed button would be invaluable.

     

    Thursday, October 9, 2008 4:13 PM
  • Hi Joe and Mike,

     

    Thanks for the feedback. I will try to put an example together. Would it be sufficient to have a service that just sends a byte array (or a string) and sends back every character it receives as a notification? This introduces some overhead in the processing of received data, but often the results from the serial device are a simple acknowledgement so the received data is only a couple of characters, e.g. servo controllers.

     

    Where it gets messy is if the device sends a lot of data from sensors. Then there are definite "packets" of data that should really be accumulated before returning the packets as a notifications. If you have control over the robot code, then you can use something like a carriage return to indicate the end of a packet. Alternatively, all packets can be a fixed size.

     

    What do you guys think? I'm open to suggestions on this and we can see if we can come up with a useable serial implementation. My only concern is that it might not actually fit any real situations. However, as an example people might be able to modify it themselves.

     

    Just bear in mind that some microcontrollers cannot do full duplex properly and only have an input buffer of one or two characters. So if the microcontroller is busy, it might drop characters. You protocol needs to take this into account.

     

    Trevor

    Thursday, October 9, 2008 5:22 PM
  • Don't let it get messy. The complexities of multiple sensors can be worked out later. What's needed is just something to get started.

     

    1. Send a message to the micro controller that just assumes that the microcontroller will know what to do with it. The message can be as little as one byte (that's what I did).

     

    2. Show how to handle the results, a. The microcontroller echoed the message, b. Nothing came back because the microcontroller was busy doing something else, c. The microconroller sent back an acknowledgment, or d. The microcontroller echoed the message and sent an acknowledment

     

    None of this really has anything to do with MRDS. You could do this without using MRDS at all. The thing is, it's very hard to get interested in all the things that make MRDS powerful when you can't get it to do anything at all. You have to work up to the full power of MRDS but the first step is the hardest.

    Monday, October 13, 2008 5:14 PM
  • Hi Joe,

     

    1. This is easy (as you no doubt know already). Sending will block, but if the baud rate is high enough the time delay is minimal. You might want to implement a queue, but it is probably not necessary if your code always waits for a response anyway.

     

    2.

    (a) You can read a character from the serial port. This ties up a thread so the only trick is to make sure you have enough available threads. However, if there is no reply then this will hang forever. That's why (b) is more sensible.

    (b) Read with timeout. The Serial Port will do this for you too. So either you get a timeout or you get your character.

    (c) Not a lot different to (b) except maybe more than one character.

    (d) Same as (c) - it's just a bunch of characters.

     

    What needs to be done is to wrap some serial port code in a service. There should be a request to send a byte, maybe another request to send a string.

     

    You could make the request wait for the response from the microcontroller, provided that the time interval involved is short, say a second or less. Then it can send back whatever is received as the response.

     

    The responses could also come back as notifications. This gets a bit tricky. You send a message and get an immediate response to say it has been sent. Now you get notifications (at some time in the future) either for each character (which might be an unnecessary overhead) or as a whole message in the case of (c) or (d) above. A timeout can also be sent as a notification.

     

    Your service now has to maintain a state machine so it can track the commands and responses (notifications). You can use ports internally and wait on a port so that your mainline code basically does a send, wait, process the ack/nack.

     

    I know this looks like a lot of words, but I think it is important to get the design right. A bit of time spent now will save a lot of time later trying to fix a broken design.

     

    Trevor

    Tuesday, October 14, 2008 5:04 AM
  • Hi,

    I have the exact same problem as people above and think the proposed example is getting to complicated already:

     

    1) I consider myself a robotics expert

    2) I have no problems with serial communication etc.

    3) I am totally confused by the shear amount of STUFF necessary to get something to work in Robotics Studio.

     

    4) I tried to understand the "Tutorial 6: Remotely Connected Robots". The few lines of serial stuff is easy, the problem is all the other stuff in random places, random files. Too much in one tutorial.

     

    Example code:

    *****************

    1) I think the example proposed at the beginning with JUST sending 1/0 over serial port is great, since the problem is not the serial ***, this is easy, but the RS side which uses it.

     

    2) I would like an example which does not use dozends of files, manifests, XML definitions etc. but is VERY VERY VERY simple. I am not a web developer and have no idea what all that suff is.

     

    3) Can there be a REALLY simple project, which may uses common files needed, but is otherwise not split up into tons of files but a single .cs file which contains very few lines of code. Like someone mentioned above, literally the "barebones", all the fancy nice stuff can show up in a later example.

     

    I think there is a communication gap between people who view the thing from the embedded systems side (like myself) and the WebService side.

     

    Thanks a lot,

    Tappo

     

    Thursday, October 30, 2008 5:26 PM
  • Oh, I forgot,

     

    @Trevor: It would be great if you could provide and example! Could it be even simpler than what you described? Sending a byte sounds good. Receiving a byte also, but maybe a simple receive only, which just overwrites the last byte received with a new one, to keep it short.

     

    Something like a service which offers the 2 things only:

    a) SendByte(byte Data). Sending a byte over serial port. Nothing else

    b) byte GetCurrentByte(), which retrieves the last received byte over serial port. So, whenever a new byte is received over serial port, it gets stored in an internal variable in the service, and is overwritten by an new one no matter whether somone read it it out or not.

     

    This would help me a lot to see how somethign simple like this is then beeing interfaced with the rest of Robotics Studio.

     

     

    Do you think this could be useful?

     

    Tappo

     

    Thursday, October 30, 2008 5:42 PM
  • There is not a lot of difference between sending a single byte and sending a byte array or a string. A single byte is just an array with one element.

     

    I had been thinking of constructing a byte array with the received bytes. When a specified number of characters has arrived, or a particular "end of message" character, say a carriage return or a linefeed, then the service could send a notification. The problem with just keeping the last byte is that you need to know when it has changed, and it is not efficient to keep doing a Get. Notifications solve this problem and they are not really complicated to use.

     

    I think a useful example might be a "chat" service that just displays incoming and outgoing characters. This would send what you type, and display what is received. Maybe it is overkill.

     

    I'll see what I can put together. I just need to set up two back-to-back serial ports somehow.

     

    Trevor

    Friday, October 31, 2008 4:32 AM
  • Greetings!

    I am trying to make a little tutorial switching LED using MRDS and PIC Hardware. I want to post it here. I will publish it in PDF.
    How can I post it? And I need Sir Trevor to review it first since I am also a beginner in MRDS.

    Thanks.
    Thursday, March 11, 2010 7:53 AM
  • You should probably start a new thread abou this.

    You will need to write some code to run on the PIC that talks to a PC running RDS.

    There is no mechanism to post code on these Discussion Forums. If you have a web site of your own, you can host the code there. If not, you can create a project on one of the many open source repositories, e.g. CodePlex.

    I don't review code, but thanks for the kind comment :-)

    Trevor

     

    Friday, March 19, 2010 1:37 AM