DIY Remote Control XBee controller for Robotics

I will take a look and see what I can find. Right now, I am just waiting for the Arc32 and RoboClaw controllers to be available here, and then I have to decide which to get.

I have some of each of those in my current SparkFun shopping cart. I don’t know when I will be able to put my order in though.

I want to get this LCD shield and maybe an Arduino Pro to run it as a display controller to tinker with. I also have five 320x240 displays, and one of them has a touch screen. I don’t know how much CPU power it would take to run one of them though.

I think this is the hardest part for me. I would want it to look decent.

8-Dale

Which is why I also bought one of your Hitec radios as well :wink: :blush:

To verify what type of joystick is inside a PS2 controller, I took one apart and yep it looks very much like the sparkfun one :exclamation:Inside-Ps2.jpg

Kurt

Kurte,

Did you get something like this or this for the sticks?

8-Dale

It’s an excellent project, Jim! I didn’t really look at it closely until very recently, but I see now that this is exactly the kind of thing I need for my remote robot controller. I’m probably never going to be real happy with just PS2 control, even when I do get it all working right.

8-Dale

Actually what I bought was some cheap and dirty one. I mentioned it on about page 14 of this thread. hobbypartz.com/4warcratr.html

My updated ones should arrive today :smiley:. I have some non-computer/robot based projects going on now so I might not be able to post any updates on using these for a little while, but will be fun!

Would be fun to play with a touch screen as well, but would still probably want some real physical buttons as well.

Kurt

The idea of the touch screen is to get rid of the need for a keypad, and the touch screen run by a micro would be completely programmable so you could create any kind of GUI and control setup you want for a given application/robot control.

OMG, I just stumbled onto this BeagleTouch, which I am absolutely going to have to get for my BeagleBoard. Oh, I would love to put this with an Arc32 slaved to the BeagleBoard into a DIY controller… :smiley: :smiley:

8-Dale

Hi Kurt (and others :wink: ),

I just wanted to let you know I managed to get RoboRealm sending the image data through a Pipe to your DIY XBee VB application. So today I controlled my robots using a yellow stanley knife! :laughing: I’ve not very much experience with VB programming so I did alot of dirty tricks, but it worked though. I’ll work more on this later, if you are interested I can post the dirty files. :wink: At the moment I’m running the main Pipe loop inside your CommThread_DoWork sub.

[code]Private Sub CommThread_DoWork(ByVal sender As System.Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles CommThread.DoWork

    CommThread.ReportProgress(0)
    XBSW.Start()
    'Dim Counter As Byte

    '=========== From VB Pipe sub Main start =============
    Dim dwOpenMode As Integer, dwPipeMode As Integer
    Dim res As Integer, bytesRead As Integer, varLen As Integer
    Dim varName() As Byte
    Dim varData(1024) As Byte

    Running = True

    'Create the NULL security token for the pipe
    pSD = GlobalAlloc(GPTR, SECURITY_DESCRIPTOR_MIN_LENGTH)
    res = InitializeSecurityDescriptor(pSD, SECURITY_DESCRIPTOR_REVISION)
    res = SetSecurityDescriptorDacl(pSD, -1, 0, 0)
    sa.nLength = Len(sa)
    sa.lpSecurityDescriptor = pSD
    sa.bInheritHandle = True

    Dim op As OVERLAPPED

    Dim eventHandle As Long
    eventHandle = CreateEvent(0&, False, False, 0&)
    op.hEvent = eventHandle

    'Create the Named Pipe
    dwOpenMode = PIPE_ACCESS_DUPLEX Or FILE_FLAG_WRITE_THROUGH
    'dwPipeMode = FILE_FLAG_OVERLAPPED Or PIPE_TYPE_MESSAGE Or PIPE_READMODE_MESSAGE
    dwPipeMode = PIPE_TYPE_MESSAGE Or PIPE_READMODE_MESSAGE
    hPipe = CreateNamedPipe(szPipeName, dwOpenMode, dwPipeMode, 10, 10000, 2000, 10000, sa)
    'Waiting

    res = ConnectNamedPipe(hPipe, Nothing)

    'res = MsgWaitForMultipleObjects(1, eventHandle, 0&, INFINITE, QS_ALLINPUT)

    If res > 0 Then
        'Connected

        imageCount = 0

        Dim bytesWrite = 0

        varLen = 0
        '===== VB Pipe end ======

        Using com1 As IO.Ports.SerialPort = _
            My.Computer.Ports.OpenSerialPort(XBeeCommport, 38400, IO.Ports.Parity.None)
            com1.Handshake = IO.Ports.Handshake.None
            com1.DtrEnable = False
            com1.NewLine = Chr(13)

            While Not CommThread.CancellationPending              ' turn off the thread...
                '=========== VB Pipe Loop start==========
                Do While Running

                    imageCount = imageCount + 1

                    'Processing  & imageCount

                    Do While Running

                        'DoEvents()

                        ' read in variable length
                        varLen = ReadInteger(hPipe)
                        ' if length <=0 on the variable name then we're done
                        If varLen <= 0 Then Exit Do
                        ' read in variable name but if the name is longer than 64 characters
                        ' then grab the first 64 chars only
                        If varLen < MAX_VARNAME_SIZE Then
                            bytesRead = varLen
                            ReDim varName(varLen - 1)
                            ReadFile(hPipe, varName(0), varLen, bytesRead, Nothing)
                        Else
                            bytesRead = 64
                            ' read in first 64 chars
                            ReDim varName(64 - 1)
                            ReadFile(hPipe, varName(0), MAX_VARNAME_SIZE - 1, bytesRead, Nothing)
                            ' skip over remaining chars
                            SetFilePointer(hPipe, varLen - MAX_VARNAME_SIZE + 1, 0, FILE_CURRENT)
                        End If

                        ' read in the variable's data length
                        varLen = ReadInteger(hPipe)
                        ' if the data is less than 1024 read it in now ..
                        If varLen < 1024 Then
                            bytesRead = varLen
                            ReadFile(hPipe, varData(0), varLen, bytesRead, Nothing)
                        End If

                        ' handle this variable
                        ProcessVariable(hPipe, varName, varData, varLen)

                        '***********
                        CheckAndTransmitDataPacket(com1)                ' just loop trying to send packets
                        '***********

                    Loop

                    ' termination signal -1 on attribute length
                    If varLen < 0 Then Exit Do

                    ' process image
                    Process()

                    ' Write out the processed image back to RoboRealm using stdout.
                    ' You can also write back any other variables to use in
                    ' other parts of the program.
                    ' The format is the same as the input.
                    ReturnBytesVariable(hPipe, CStr("image"), imagePixels, CLng(imageWidth) * CLng(imageHeight) * 3)

                    ' Send back the count as an example of how to feed back variables into RoboRealm
                    ReturnIntVariable(hPipe, "count", imageCount)

                    ' write out end of message
                    WriteFile(hPipe, ASCII.GetBytes(""), 4, bytesWrite, Nothing)
                    FlushFileBuffers(hPipe)

                    If bytesWrite <= 0 Then Exit Do

                    ' continue by waiting for next image request
                Loop
                '=========== VB Pipe Loop end==========

            End While

            XBeeTransNotReady(com1)            ' send out a not ready in case it was waiting for us

        End Using
    End If

    CommThread.ReportProgress(99)

End Sub[/code]

There is alot more code added, but this is the main essence… The image data like the cog information are handled in the ProcessVariable sub. I used the VB.net plugin files found here. Maybe there should be another “CommThread” for handeling the Pipe part too? At the moment most of the code are way over my head but I’m trying to keep my neck over the water though.
So to make the Roborealm connection to work the XBee connection needs to be activated (means that I’ve to hit the “connect” button within a short period of time after startup) :unamused: .

Anyway, this was a really fun project to work with! I believe I’ve got to study VB a bit more. :smiley:

Ha Zenta,

I was away for a few days having some fun. Now trying to catch up on the new posts.

Sounds great, Maybe I will have to play around with this as well. From your description, having the pipe on a second thread may be a good thing. Maybe also having the code automatically invoke the XBee connect code if the Roborelm pipe is detected… So when you have a chance you might post the “dirty code”. If I update it, I may try to ifdef it such that it can be used for both our setups (ie I don’t have the two extra controls…).

Kurt

Hi Kurt!

I was a little bit worried about not seeing you here lately, but I’m glad you’ve had a fun time though. :smiley:

I’ve been playing a bit more with your VB project. I did try adding one more backgroundworker and it worked ok. But I had some issues of having a bit to slow fps (around 5-6). I’m not sure if its my rather old and slow (P4 1,8 GHz, XP) PC in my workshop that’s causing it. So I made a new worker that handled both com and pipe, similar to what I posted but with some changes. The two COG X/Y text-boxes are updated using a reportprogress(xx) call just after the CheckAndTransmitDataPacket(com1) call.

The best way to make it work is to first start the VB program. Make sure the USB XBee module is connected and select the correct com port. Then click the connect button. The VB program will then look like this:

Then start RoboRealm, it must be configured with the pipe_program at first though. And after a little while the two programs are sending data to another through the pipe:

Observe that the Cog X/Y values on the VB app are calculated to fit the byte size. At this moment I’m just sending the Cog data through the Right joystick, for testing. Example of how to get the Cog_X values:

ElseIf strName = "COG_X" Then 'Debug.Print(strName) strCogData = ASCII.GetString(data) strCogData = strCogData.Substring(0, dataLen) If imageWidth > 0 Then bData = (Val(strCogData) * 255) / imageWidth End If DataPacket(PKT_RJOYLR) = 128 - ((bData - 128) / 2) fDataHasChanged = True

Using only one backgroundworker increased the fps speed to 15fps. (The camera property is set to this speed to though).

The best way to end this season is to close the RoboRealm first and observe that the VB program terminates the Pipe and makes the com available again:

I guess there are better ways to do this, but its working ok.

I’ve not had time to play much with the roborealm yet, but having this connection working sure opens alot of possibilities!

Here is the code I’m currently working on:
DIY XBee with VB pipe dual thread test.zip (215 KB)

Hi Zenta,

OK, I downloaded your code, I dug through my parts bin and grabbed the Trendnet TV-IP110W camera, which I was going to put on Mechbrat, but have not yet as I have not yet as I am not brave enough for a Lipo battery :neutral_face:, but that is another story :laughing:

I think I setup the same filter/blob/COG/PIPE chain. Probably need to work on configuring them and I need to find a yellow ball…

I also find that my VB code that I did for the download sequence code looks a lot better, so I may try to rethink the placements of the controls and the like.

But in my gut my higher priority is to play with the actual DIY-XBEE protocol and do the conversion to binary, such that we can better integrate the information from the PC, the DIY control and the robot(s).

Kurt

Hi Kurt,

:laughing: Any colored object would do the job I think… :wink:
So, did the Pipe communication part work OK?

Yeah, I remember you mentioned this before. Having the ability to switch between the DIY remote controller and PC/RoboRealm control would be awesome. Also communication between the robots (DIY controller, master robot, slave robot etc) would also be great.
At this moment I’m very satisfied as it is for testing and I need to dig into all the documentations about the different modules in RoboRealm. So much fun! As always at this time of the year I’ve so many other house/garden related projects that keep me away from my robots though.

Hi Zenta,

I know :laughing: Later I may try to build something that looks like a target to hang on a robot to see how well it tracks it…

Yep, it appeared to work just fine. I may want to play around with it some. I have used the Trendnet a couple times in the last few days and each time it appears like not long after that I lose network connectivity and have to reset all of my routers and the like. Maybe I ended up with some conflict in fixed IP address. More to experiment with. Of course it could just be a coincidence.

Yep my thoughts exactly. The current VB app there has been great for experimenting with different things, like can I add support for emulating a SSC-32 enough to then trick SEQ or PEP. If so I was going to maybe try to migrate some of the basic code into PEP to allow you to talk directly to the robot through the XBee interface.

As you mentioned, once we have the ability to easily talk to multiple nodes it could make things exciting. I will probably start off using it to control the robot from the DIY and have the ability for the robot to report diagnostic information to display on the PC without needing the serial port (S_in/S_OUT). Could also have some fun and integrate the roborelm information and maybe the PC sends targeting information to the DIY to display in the LED…

Kurt

Hi again Zenta (and others…)

I forgot to say me too! :laughing:

But I am starting to play around with the communications. I thought I wold do a little cleanup first of the VB code, like removing a lot of duplicate code, IE only one set of code that tries the different baud rates, likewise have all of the packets output through one function.
While I was at it I also setup a define to change the size of the packet (so we can easily work back and forth). Also created a new button, to allow you to use the pipe or not and depending one which one you use it will use the right joystick, added the code so the listbox should automatically scroll when most of the messages are added.

Will next try switching the API mode using the same command formats, so I can learn the differences. Once this works I will work on converting the other code bases as well (Atom Pro, Arc32, Transmitter, and Axon2) with this I will change the command formats as for example the API packet already has a length and checksum, no need for me to add another one inside…

Kurt

P.S - I included the slightly updated version here. No promises that I did not break anything :smiley:
DIY XBee with VB pipe dual thread test.zip (140 KB)

Hi Kurt,

I was also thinking of adding that button, looks like you beat me to it. :wink: Your little update worked fine, and it was very convenient switching the packetsize, thanks!

Looks like you have made yourself a lot of fun work to do… :smiley:

So far I’ve not done much lately, just read a little about the different modules in RoboRealm. Hopefully I’ll do some more testing later.

Yep I am having some fun. I have the first part mostly working. That is the VB is updated to convert the XBEE to API mode and it sets the My/DL using the API mode and it now talks to to the robots using the old format. Still some more debugging to do. I have the phoenix (arc32) walking, but the text messages that the phoenix sends back is not being handled properly yet…

Once I go to next mode, will have to decide if I should change the XBee config program to configure the XBees on the Pros to be in API mode such that it makes the normal communications easier. That is if I don’t, when you first power up the robot, the code will have to change the XBEE to API mode, but if the BAP resets or the like, the XBEE will still be in API mode…

Now back to debugging.

Kurt

Edit: quick update fixed the message display issue…

Another quick update: I now have the Arc32 phoenix working with the XBee in API mode. It is currently still using the same packet formats as before, so it can still talk to the remote control. I was keeping my fingers crossed as I am hoping that the packets that are generated on the remote side by non API code would in fact be packaged up properly and have each of my logical packets be properly packaged up as an XBEE packet. So far it appears like that is working OK. The phoenix code is currently using the logically similar information out of the XBEE packet, instead out of my packet data. This includes, length, checksum and will be packet frame number. Once I get all of the other remaining implementations conversed, I will remove the duplicated data…

Kurt

Hi Kurt,

Thats great news, well done Kurt!

Does the API mode have any con’s compared to the other method you used at first?

Thanks,

Not that I know of. Other than not screwing it up. Now that you can cheat with the compiler and use HSEROUT2 but have it go to the right place on the BAP, I will now re-merge it with the main Bap28 code base for it. Yah…

Been playing some with the roboclaw for the last couple of days… Will get back to this soon!

Kurt

Another quick update:

I think I have most of the different code bases converted over to use API mode and changed the packet format/numbers. That is since the XBEE packets know about and confirm, packet size and checksums, I removed that from my internal packets. Also since for the most part I don’t care which serial number of the packet of DIY data I receive as long as it is valid, I also removed the serial number from my packet. I split up a few of the packets into multiple packets as well. For example I now have a different packet for sending a number versus sending a string…

I have the following code bases converted:

My Bap28 robots - So far I have only done some testing using the CHR-3, need to do more plus test some of the other robots (rover/brat…)

DIY Transmitter - Needs more testing - Like I have not done any testing of the ATND (Node discovery code) yet

VB App - ditto

Arc32 Phoenix - ditto, but may try to merge this back with the Bap28 robot code. Alternatively Nathan has another version of the port that I may instead merge with… Not sure yet.

Phoenix code running in C on Bap28. This just started limping along, needs lots more testing of my C code here. Program appears to be getting valid XBee packets, can start walk and like, but resets… (lower priority)

Brat with Axon2 with C code using webbotlib - Needs more play time…

What’s next - Test/play with all of the above plus:
a) Rework some of the functions again. Example: SendXbeePacket[_bPHType, _bPCBExtra, _pbIN]: Where I give it a packet type, a pointer to any extra data and a count of extra bytes. Currently it will Always send the data to the program(Transmitter, VB Transmitter) that connected to the robot. I will extend this to pass in the DL (ATDL) value and then start off experimenting with sending debug text messages to the VB app while being controlled by DIY remote… Will also modify such that the receiving code will preserve the 16 bit address who sent the message…

b) Rework VB app - clean up some of the interface plus enhance the connect to have a version that is a debug monitor… Maybe if it is told to display a message for the robot not associated with it it will show the robot name… Allow for quick change of who it is talking to… Also want it to keep/manipulate a set of robots like what the DIY remote does.

c) Add some callback function. That is for example if someone wishes to create a new data packet to send, they simply create a new packet type and if my default code does not recognize the packet type it does a call back to some function with: 16 bit xbee address of who sent it, packet type, count of bytes, and maybe pointer to data or maybe it uses global buffer… Could be fun for example to have one robot send a packet to another robot, to tell them do something…

d) merge in my other VB app that allows me to download sequences to a robot like the Arc32. Could be fun to be running the robot, click a vb button to download a new sequence and then click a button on the DIY remote to run it…

Suggestions?

Kurt

P.S - I have not uploaded any of this new stuff yet as I am not sure if anyone would want to play with it yet?

i dont mind helping to test the vb APP. I was playing with the last version you posted seems to find my board only at 9600 baud