It has been awhile since I looked at this code, so I am a bit rusty with it.
The idea is that we build our packet and note if anything has changed in the packet from the previous time. If it has we wish to display the updated information. But especially with the RC version we had only so much time before we had to send out the next packet. So we only updated pieces of the display each time through the main loop. First maybe the Left Joystick, then maybe the right…
Not as much an issue with XBEE, but to make sure I sprinkle the call for CheckandTransmitDataPacket around different outputs to the display. In addition to this, We have a couple of different display modes. The one that shows all of the joystick/keyboard/slider data and one that only shows the thing that is changing, which allows the 2nd line to be used to display messages sent back from the robot. That is what the bTDataLast is keeping track of, as If we change which group we are displaying we update the display with title strings for it… So if you can display all three sliders in the same display, you don’t need to change that variable as the group number stays the same.
While waiting for the Botboarduino .2 version to arrive and new faceplate for the Arduino DIY remote to arrive… I was thinking about making some changes to my communication protocols for the XBEE code, to see if it speeds it up some. Currently the code works, by the robot requesting data, by sending a request packet. When the remote receives this request, it sends out the data packet, which with my new remote the data is 12 bytes of data, plus the packet type, plus the RAW data packet stuff… On the robot side, in most cases we may not see the overhead of receiving the bytes as we are using HSERIAL, although once it starts to see the first bytes of a packet it may sit and wait for the rest of them… But for sure on the Remote side, the XBEE won’t send the packet until the complete data for a packet is sent…
What I am thinking of trying, is to add a new Request packet, that says, give me the delta data, which the remote may return 3 different types of packets:
Old Packet - If more than N fields have changed since the last request.
Delta Packet - If less than N fields have changed (may try like 4 fields changed…) where first word is a bitmask of the which bytes of the packet changed, followed by those bytes.
Nothin Changed Packet - One byte packet that says nothing changed…
Thoughts? Is anyone else interested in trying this out, once I have it up and running? If not I will probably start with Arduino DIY remote, plus Beta version 2.x phoenix code for T-Hex and Phoenix. Else will also update the BAP28 version DIY remote code as well.
I’m not sure if I follow you on all the different packets. What do you mean by fields?
Anyway, any method that makes it a little faster is better. I don’t see the point in sending a packet that hasn’t changed. It’s rather rare that more than 4 - 6 packets (fields?) changes at the same time.
As long as its rather easy to update the robot code I’m in to some changes that can make it even more versatile.
Me too
I’m also planning to make an extra DIY remote based on a cheap RC transmitter. I do also have the 20x4 LCD and want to ad more sliders/pots. I’m thinking of using the ARC-32 board (up to 20 A/D’s) and 2 UARTs.
That is when a transmitter with the new code is running it will send out a packet that tells the robot that it supports the new format. Then when the robot wants data it sends a different data request packet. Before I send, I check to see which bytes have changes. If none has changed, it sends a simple 1 byte packet. If 1-4 bytes changed, it sends a packet with the packet type, a word with a mask of which bytes changed followed by the changed bytes. So for 2 byte change the packet size is (1 + 2 + 2), otherwise sends the old format packet(1+12). All of the above packets have the additional overhead of XBEE packets, but I think this could speed stuff up a little…
So far I have the code changes in place for the Arduino DIY remote. I was starting to work on the Phoenix code on Bap/Arc32, will then do the DIY remote for Bap…
I have the Delta packet mode working (I think). I have tried to make it, such that, it will only send out the new packets if the client sends out a new request (different packet type number). The clients only send out the new request packets, if they receive a new message from the transmitter saying that they are a new transmitter… So hopefully we should be able to mix and match.
Note: the above does not work around the fact that many of my earlier clients were pretty stupid, in that if they receive a message with more data than they want to handle, the punt and don’t process any of the data. So if you have a new remote that sends out additional information, like the Knobs, or third slider, or additional button data, they plain don’t work.
I also uploaded a Version 2.1 beta Phoenix 2.1 code base that uses this for an Arc32 Phoenix. That is up on the thread: viewtopic.php?f=8&t=7658
I played a bit with my DIY last night. Had the XBEE modules to find each other. Navigating trough the menus was a bit hard since I’m using the push-dail button instead of the 4 push buttons. I decided to drop by the local electronics shop to get the extra row of buttons. It’s easier to have the same hardware. Do have to find a way to close the push/dail hole. LOL
On panels I have built in the past when I needed to fill a hole that was no longer needed, I used a piece of tape on the front of the panel and turned the panel over. Then, I filled the hole with some 5-minute epoxy. Once set, I removed the tape from the front, burnished/sanded it if necessary and touched up the paint. In most cases, the result was indistinguishable.
Kurt,
I’m finally cleaning up my code so i can see what is being displayed on my 4X20 LCD. Still a few ghost running around, but caught most of them, between butchering my fingers while cutting out my new face plate. I ordered a uled 1.7 from sparkfun(they dropped the price) since the robotshop still has mine backordered (Approx 25 Oct). Since I’ll have a spare will one of these. Will these work with the BAP ?
I’ve got a question about your current I/O layout. I would like to add the Z-axis potmeter and the 4 command buttons to the remote. They will need 2 additional analog inputs and one digital input. I know we talked about this but I can’t remember the outcome. Did you drop some of the current functionality like the speaker or battery voltage to get them connected? Can one of you send me the used I/O layout?
Also, is it hard to port the XBEE code to the ARC. (Got one )
The comments/defines in the code are pretty current for which IO pins are used for what:
;==============================================================================
; [IO Definitions] Lets define what each IO line is used for.
;==============================================================================
; p0, left vertical joystick
; p1, left horizontal joystick
; p2, right vertical joystick
; p3, right horizontal joystick
; in4 - Col1 on keypad
; in5 - Col2 "
; in6 - Col3 "
; in7 - Col4 "
Display con 8 ; LCD Display
'Speaker con 9 ; Speaker; Disable speaker when used extra pot meter
Row0 con 10 ; Row 0 on keypad
Row1 con 11 ; row 1 on keypad
Row2 con 12 ; Row 2
Row3 con 13 ; Row 3
; P14 RXD ; HSERIAL
; P15 TXD ; hserial
RowB con 9 ; Cmd buttons new row , XP: ex-speaker
; p18 - Left slider
; p19 - Right slider
; p16 (AX0) - XP (eXtra potmeter), Left potmeter
; p17 (AX1) - XP (eXtra potmeter), Right potmeter
Note: in the above I removed the #ifdef for the extra pots as both Zenta’s and my remote are configured this way. So as you can see we used up every IO pin including the speaker.
It should not be too difficult to convert to Arc32. A quick look at the code shows that all of my support code for BAP40/Arc32 is still in #ifdefs in the two helper files in the project. That would give you the 16 analog pins and several more digital pins. No built-in sound support, but I have simply added Radio-shack speaker without any support circuit and usually works OK (I have only melted one ) I should try it out sometime. I may have one of the version 1 prototype boards sitting around someplace. Maybe someday I will get another one…
Again 16 Analog inputs and tons of digital and the prototype shields give you the speaker plus other stuff. But a tight fit… But that is a different subject
I’m glad I asked… In this same topic, post 46 you came up with the idea about how to connect the extra command buttons. The only thing is that the drawing shows an extra column on P17. And the commend in the code (like above) shows an extra row on P9. This got me confused.
But row it is then. A row doesn’t need an extra resistor though.
A Arduino Mega would be cool to try. But since you guys are still in the prototype stage I’m thinking of a solution for in the meanwhile.
Yep, Zenta moved the extra row to P9 so he would have the Analog capable pin P17… Yep, did not need extra resistor.
As you mentioned, the Arduino version is a prototype, but aren’t they all As I mentioned, it should not be hard to to convert to Arc32, but have not tried.
I’ve got the buttons connected and am able to scan, and actually find, the other modules.
I’m still a bit confused about the function of the buttons and the structure of the menu. But I’m sure you (or Zenta) can clarify it for me
The 4 buttons are marked X, Y, Y and Z. If I got it right the layout is:
bit 0 = W = esc
bit 1 = X = enter
bit 2 = Y = down
bit 3 = Z = up
Here come my noob questions:
If I’m in the home screen and push the down button I loop trough the following entries
home -> Cal Joystics Move Full Ranges -> Current My: 0000 -> Current DL: 0003 THEX New: -> Select By Name -> Right: 128 128 ->home
home
Home screen showing normal values
Cal Joystics Move Full Ranges
How does this work? I can move all joysticks, buttons but nothing happens. Only if I hit X (enter) I get *** Error ***s
Current My: 0000
This screen is a bit mixed up. I’ve got a lot of non-ASCII chars in there. No idea why. Maybe it is reading something for memory which is corrupted?
Current DL: 0003 THEX New:
This shows the current selected XBEE module. Can it do something else? What’s the “New:” for?
Select by name
This is where I can scan for modules and select the XBEE module
A - Scan modules
D - Delete
RJoy - scroll found XBEE modules
Enter - Select XBEE module
Right 128 128
What does this menu item do? It seems to show the left or right joystick values. Both my left and right joysticks are not totally stable in the home position so this screen keeps jumping between left and right.
Calibrate… You need to move both joysticks to their sort-of max extents in both X and Y directions. Note: I often don’t diagonalsnals here as I want the straight up top to be the maximum value… You also need to move the sliders to their minimums and maximums. The code checks to see if all of these values are above or below some certthresholdsolds.
Current My: is whatever 16 bit hex value you want. If you are seeing corrupted characters on this display, it is probably because the interrupts are screwing up the text… Will need to look sometime. Note: 0 usually works fine.
Current DL: This was originally the only way to choose a robot. You had to know it’s hex MY value and then enter that into the keypad. But for the most part, I use the Select by Name for the majority of the time.
Right 128 128 - Is often the standard display. That is, if you move the right joy stick you will see values for the right joy stick. If you move the Left joystick, the word right will turn to left and show the values for the left joystick. Likewise for sliders. This freed up the 2nd line of the display to show things, that are sent back from the robot, like what the new gait is or the like.
Calibrate: If I got it correctly I only need to move both joysticks to the maximum positions to calibrate them. No need to confirm the movements then. Can you tell me why enter gives me an error?
Current my: Clear, this is the XBEE MY setting (16-bits source address). Need to check the interrupt stuff for the display mixup
Current DL: Clear, works like a charm!
Right 128 128: this doesn’t work for me since the display is still blinking to “left”. This might need a threshold.
