Lynxmotion Tech Support

Hi all,

Small update:
- The PWM values are in the code.
- I made the safety shut down optional. It can be configured in the config file. The voltage level can be adjusted as well.

Only 2 more to go...

Xan

_________________
[b]Share, Use and Improve![/b]
Digging trough: [i]Theory of Applied Robotics: Kinematics, Dynamics, and Control[/i]
Xan's YouTube Channel
http://www.youtube.com/xanore

Sounds great! Let me know if you have a version you wish for someone else to try out

Kurt

Hi Kurt,

I'll make sure I've got an alfa version by the end of this evening.

Xan

_________________
[b]Share, Use and Improve![/b]
Digging trough: [i]Theory of Applied Robotics: Kinematics, Dynamics, and Control[/i]
Xan's YouTube Channel
http://www.youtube.com/xanore

Hi Xan,

Was thinking of a new work item(s).

1) Earlier I converted my code from TImerW to TimerA... Probably not that important, but I was able to reduce the number of interrupts per second. But I had to add a multiplier and divisor to to convert the clock ticks to milliseconds.

1a) I have had a few occasions when a leg would act funny or jerk a little randomly, and found that if the timer interrupt happened while doing serouts to the SSC it could corrupt the output, especially at faster baud rates. So my versions have a set of disable/enable Timer interrupts that bracket the serouts to SSC. (I set which interrupt I am using as a constant as it changes for Bap28 versus Bap40/Arc32). With Timer A you only have about 7 or 8 interrupts per second, so won't lose interrupt during the serout code.

1b) Some input controllers like XBEE may use interrupts (directly or indirectly through hardware serial port). So I also added call outs to the Control code that said, disable your interrupts now/ It is OK for you to Enable them again.

Added: On some robots, that I use the pS2, I also have an XBEE on P14-P15 so I need to move the PS2 to another set of pins. At least half the time on Bap28 and Lynxmotion PS2 remotes the internal pull-up resistor on the Basic Atom Pro is sufficient for the Dat line. This works for P0 and P16, which on the Bot Board 2 is the only reasonable locations to start a group of 4 pins... (P4 does not work as P6 and P7 have lower voltage and did not work. P8 does not work as P9 is used by the speaker... But if needed could probably use the pull-up on that pin as well...

So in my PS2 code I start the InitController like:


Added Maybe? Recent Zentas (with a little help) enhancements to running GP Player. Again XBee code needs to disable interrupts during the issuing of commands and query back from the SSC-32. (Also needed a slight pause). But in addition to this there were call backs added to this code to the controller code such that the it could give additional feedback to the user. Also it allowed the controller to update the running of the sequence.

Along this same line, my versions have some places where the main code may tell the control code about some events, which allows the code to inform the user or the like. My additions may not have been generic enough in that it said XBee Play a sound... But this could be updated to be something like: ControlEventCallBack[EVENT]: Where we could define a set of events like (low power shut down ...)



That's all for now!
Kurt

Hi Kurt,

Thanks for the feedback! Some of the points are new to me so you need to fill me in a little bit. I would be happy to discuss them with you.
Does the rather slower TimerA has an high enough resolution to sync both BAP and SSC? I think it is a good thing to reduce the amount of interrupts. Can you provide me an adjusted version of the alpha release with this new timer?

I've seen the enables/disables but I wan't really sure what they where doing there. So I commented them out. I will uncomment them.

Isn't it a better solution to disable/enable ALL interrupts when going in to critical sections like updating the SSC? This way we don't need to add code in the "core" file which is only used when the bot is controlled by XBEE.

I think you're a one of a kind guy, having 2 remotes on one bot!
No serious. Most of the time I use my DIY remote while programming / testing. Once the software is ready I simply swap receivers and try the PS2 remote. This should be good for debugging / testing but I doubt this has any value for most of the users. But please, let me know if I'm on the wrong track here

Isn't it possible to have the feedback from the bot to the remote defined in the XBEE file? The idea sounds very interesting. Having a predefined set of events that can be used to transfer information from one part of the code to the other. I'm totally in to this but I think it's a good idea to split this idea into a new topic and work this further out. In the mean while we should get our TA base version (v2.1) ready. I think the event stuff should be added later on since we still need to test the idea...

Thanks for the input and let me know what you think!

Xan

_________________
[b]Share, Use and Improve![/b]
Digging trough: [i]Theory of Applied Robotics: Kinematics, Dynamics, and Control[/i]
Xan's YouTube Channel
http://www.youtube.com/xanore

Hi Xan,
Quick first answer will get into more later:
1a) TimerA - with division 8192 gives us a resolution of .512ms, which for any of our code I think is accurate enough. Will give you updated code.

1b) On XBee we do not disable interrupts, that would cause data loss, what I do instead is to change the RTS line coming from the XBee to say don't send me any more data. I could imagine other controllers like Bluetooth or serial or the like might need the same...

2) Not sure, how many out there may have other uses for their hardware serial port... But I agree it is probably a minority of us. But for example I have in the past used the HSEROUT to talk to serial LCD display...

3) Two parts - The current GPPlayer code is self contained, you start it and never get a chance to interact, until it completes. So if we want this functionality we will need some callback or the code reconfigured such that it calls ControlInput and ControlInput checks state or... May not be able to report anything with PS2, but could maybe allow user to manipulate the sequence...

Other feedbacks may be able to be deduced by ControlInput. Like you shutdown the robot due to low power. Might be variables that can be used or the like. Not sure about others, like with TA type code, where this code will live and what feedback can be or should be given back to the user... We will see as we go.

Thanks Xan,

Kurt

Hi Kurt,

Thanks for your answers!

The resolution is more then enough. The less interrupts the better. Thanks for this good update!

Clear! I'll return the "shut up!" command

If it it ok by you, we will leave it for now...

In the current way the GP player works we did not had to read the control inputs since we couldn't interact with the GP player. But with the upgrade Zenta did it is getting a big change anyway. I will wait unit you've got it tested.

Thanks!!

Xan

_________________
[b]Share, Use and Improve![/b]
Digging trough: [i]Theory of Applied Robotics: Kinematics, Dynamics, and Control[/i]
Xan's YouTube Channel
http://www.youtube.com/xanore

Hi Xan,

Quick question for you. Is it possible to use this code on an arc-32? I am thinking it should run with little modification since the arc-32 is BAP based but I wanted to ask to be sure. I do have an ssc32 as well, so really the arc would just replace the botboard and to start I would still use the ssc32 for servo sequencing.

I just want to know if I can get it working like that so I can play around with it and learn.. then maybe migrate the ssc32 functions to the arc32 at some later time.

Thanks in advance.

Yes, the code can run on an Arc32....

If you look at the Beta version 2.1 thread: viewtopic.php?f=8&t=7658 you will find code for the Arc32 without an SSC-32. To help keep things cleaner and remove some #ifdef type code, we removed the Arc32 (with SSC-32) or Bap40 support from the code. It is not hard to add back in. In fact my local machine has such file...

This file replaces the file by the same name in the different zip files I uploaded on the thread I mentioned above...

Kurt

Ahh, okay, I was counting on having to do that myself, but this is better. Thanks. I was more worried about something like the clock speed differences causing a problem, but I guess not. Thanks for the help.

Yep, the different processor does make a difference. In that on the Bap28 it uses TimerA of the underlying H8 processor, but on the Arc32 (or Bap40), it does not have TimerA. It was replaced with TimerB1. The main place that depends on the speed differences is the timing code and there are different multiply/divide constants to convert the ticks into milliseconds...

Kurt

Ahh, got it. This is even better, now I can experiment with and without the SSC-32. Thanks a bunch!

Okay, sorry, another question. I just got my Phoenix walking (And am VERY impressed!) but I have not calibrated it yet, and I can tell it definitely needs it. I just can't figure out how to do that.

I am looking in the config file and see a comment saying "First calibrate the servos in the 0 deg position using the SSC-32 reg offsets, then:" but I'm not sure what that means? I've already searched things like "Phoenix calibrate" but I didn't see anything explaining that. Would someone be able to point me in the right direction?


edit: Oh, I should mention, I'm using an ARC-32.

Hi,

Check out this: http://www.lynxmotion.net/viewtopic.php?f=8&t=6042&p=74384&hilit=+ARC+terminal+offset#p74384

_________________
[b]Kåre Halvorsen, Zenta[/b]
-----------------------------------------
Zenta's blog
http://zentasrobots.com/
Zenta's YouTube channel
http://www.youtube.com/ZentaOlbaid
-----------------------------------------

Ahh, ok, perfect. Thanks.