Alfa release Phoenix Code

[kurte]

@Xan

Hi Kurt,

I can also slow up the sequence to zero and reverse it at the same speed. But if I check Zenta’s last video, his sequence runs much faster and I have the same sequence! So I think there is no difference when going over 100.

Sounds like we need to run an experiment like I mentioned… May get to this late today…

@Xan

Yes I’m really happy to join you guys on the XBEE stuff. I went to an local RC shop to check if I could get the left gimbal to auto center. But the guys there simply return the remotes to the factory when something breaks. So they didn’t have any parts. I also disassembled the gimbal itself to see what components I needed and what the options are to get the extra pot on there. But I’ve no idea how I could can remove the brackets at the inside of the stick to clamp it in a lathe. Probably the best way to go for me is to order 2 of the 4 function gimbals from servocity. Sadly enough they only ship to Canada or the US… :’(

I got the other gimball by purchasing a cheep receiver on ebay. Don’t see the one I have anymore, but saw some up there for about $12 but shipping charge was something like $28 as I think they ship from Hong Kong… They servocity ones look interesting, may have to try them out sometime, but would probably need a new top plate as they mount differently.

Kurt

[robotdude]

@Xan

Yes I’m really happy to join you guys on the XBEE stuff. I went to an local RC shop to check if I could get the left gumball to auto center. But the guys there simply return the remotes to the factory when something breaks. So they didn’t have any parts.

Let me see if I can dig up something to get your left stick to center.

[xan]

@Robot Dude

@Xan

Yes I’m really happy to join you guys on the XBEE stuff. I went to an local RC shop to check if I could get the left gumball to auto center. But the guys there simply return the remotes to the factory when something breaks. So they didn’t have any parts.

Let me see if I can dig up something to get your left stick to center.

Should be great! Do you need a picture of the parts I need? It’s a lever a spring and a bracket with screw to tension the spring. Let me know.

Xan

[robotdude]

It would be helpful. Pretty sure what you have, but just in case.

[xan]

Sure you know!
But here are some pictures to help our robot guru

[kurte]

OK, I did a quick and dirty program to try out different speeds and I am not sure how well the SM command is working. I had the program do similar testing like Zenta originally added to see when the step changed and I had it toggle an IO pin (12), I also used TImerA to keep time without interrupts or asm. The program allowed you to enter the sequence number and SM using S_IN and then it ran the sequence and then printed out elapsed time. The times are not making any sense to me… serout cSSC_OUT, cSSC_BAUD, "PL0", 13] ;Stop the sequence now SSC Ver: SSC32-V2.06Alpha1B-EGP Enter sequence Number:1 Speed multiply -200 to 200: 100 Sequence took: 7471 Enter sequence Number: 1 Speed multiply -200 to 200: 100 Sequence took: 7471 Enter sequence Number: 1 Speed multiply -200 to 200: 128 Sequence took: 5505 Enter sequence Number: 1 Speed multiply -200 to 200: 128 Sequence took: 5505 Enter sequence Number: 1 Speed multiply -200 to 200: 150 Sequence took: 5505 Enter sequence Number: 1 Speed multiply -200 to 200: 150 Sequence took: 5373 Enter sequence Number: 1 Speed multiply -200 to 200: 200 Sequence took: 5373
Timings are in ms… Will probably post this and code under a thread in SSC-32…

[xan]

Hi kurt,

Thanks for checking this out. The times really don’t make any sense indeed. The odd thing is that the last 2 runs (150 and 200) even take longer then the 128 sequence. And it also doesn’t make sense that the two 150 runs have different times.

Hopefully mike can fill us in here.

Xan

p.s. Zenta did you test the software from kurt? (can be found here)

[zenta]

If I get time to it tonight I’ll do some testing too. So far I’ve only tested speed up to 128 from the basic code. I felt that was fast enough. Btw, did you also test the GP player in Visual SEQ?

[kurte]

@zenta

If I get time to it tonight I’ll do some testing too. So far I’ve only tested speed up to 128 from the basic code. I felt that was fast enough. Btw, did you also test the GP player in Visual SEQ?

Nope. I just did some extract from the current code to a test program, which hopefully I did not make any stupid mistakes with The program does run differently than our current code base as I only output the SM at the start where in the phoenix code we may update it when the user moves the joystick. I thought I would keep it simple… I also did not run this code on a robot, but on some test boards, where it was easier to hook up test leads and the like.

I also wondered if my test program that sat on the Serrout/Serin to the SSC-32 may cause issues, so added a delay, which did not appear to change anything, other than the accuracy of the timing outputs (IE if I do a pause 50), the resolution that my timings will be around 50ms so some of my toggles may show some timings longer and the next shorter… If you know what I mean. I thought about maybe changing the test program to scale the pause depending on the value returned as how much time (in 100ms increments) is left in the current step and not pause if the value is 1…

But for now kept it simple. Could also save and upload Logic Analyzer output showing the different speeds so you can see the differences for each step, if that would help.

Kurt

[zenta]

Hi,

I can confirm your findings.
I didn’t try Kurt’s test program but did my own testings using Visual SEQ and LynxTerm. The GP player in Visual SEQ seem to only output +/-100% speed (probably SM= +/-100). Using LynxTerm to manually set the SM show a “normal” behavior of the speed up to 128. I could clearly see a difference between 100 and 128. Speeds between 128 - 200 didn’t give any visible speed difference.

So this is probably a bug or does SM only support sbyte size?

Btw, can Mike read these posts or should they be moved over to Kurt’s other public thread?

[robotdude]

Here is fine, just tell me where to link to and I will send it to mikes email.

Jeroen, I have a single aurora gimbal here that you can use. It will bolt right up to your radios top panel. We can send you another matching one when I have them in stock. Then they will both be the same. Let me know.

[kurte]

Hi Jim,

Here is a link to the other thread: viewtopic.php?f=2&t=7348

The thread contains a simple program to reproduce the issue.

Kurt

[xan]

Hi Guys,

I’m kinda happy you had the same results as I had. I was already doubting my programming skills
I’m sure Mike will find te issue.

@Robot Dude

Jeroen, I have a single aurora gimbal here that you can use. It will bolt right up to your radios top panel. We can send you another matching one when I have them in stock. Then they will both be the same. Let me know.

Sound great jim! This will help me out for now. Any idea when you can ship it out? Thanks!

Xan

[miked-6]

Here is the update for the SM>100 bug. Sorry about the trouble.

ssc32-V2.07Alpha1A-EGP.abl (43.2 KB)

Mike

[kurte]

Thanks Mike,

No problem, I have had a few (thousands) of bugs in my code over the years

I downloaded and updated my test board and ran the test program again:

SSC Ver: SSC32-V2.07Alpha1A-EGP Enter sequence Number: 1 Speed multiply -200 to 200: 100 Sequence took: 7471 Enter sequence Number: 1 Speed multiply -200 to 200: 101 Sequence took: 7471 Enter sequence Number: 1 Speed multiply -200 to 200: 128 Sequence took: 6422 Enter sequence Number: 1 Speed multiply -200 to 200: 150 Sequence took: 6029 Enter sequence Number: 1 Speed multiply -200 to 200: 200 Sequence took: 5505 Enter sequence Number: 1 Speed multiply -200 to 200: 200 Sequence took: 5505 Enter sequence Number: 1 Speed multiply -200 to 200: 150 Sequence took: 6029 Enter sequence Number: 1 Speed multiply -200 to 200: 128 Sequence took: 6422 Enter sequence Number: 1 Speed multiply -200 to 200: 100 Sequence took: 7471 Enter sequence Number:
Looks better. The times appear to be consistent and they do go faster when I have values > 100.

Thanks again
Kurt

[xan]

@miked

Here is the update for the SM>100 bug. Sorry about the trouble.
Mike

Thanks for the quick fix mike! I hope to check this out tomorrow. Kurt already tested it so, would be pure fun!
Don’t worry about the bugs. Second Kurt about the bugs. I’m sure I’ve spread some bugs around the world as well. LOL

Jim, I received the XBEE modules and a new straight set of phoenix legs. Thanks! I had no idea they where already shipped so I had a fun surprise when I got home.

Xan

[zenta]

@Xan

Jim, I received the XBEE modules and a new straight set of phoenix legs.

Sounds like you’ve some fun hardware work ahead. What do you plan to use the new phoenix legs, another project? Or was the old one not 100% straight?

I’m also almost finished with reassembling my old phoenix. But I do consider to replace the odd servo horn femur’s though. Maybe some black LM Phoenix femur’s?

[xan]

@zenta

Or was the old one not 100% straight?

It was not 100% straight. And I remember you pointing that out when you visited me.

[robotdude]

The first set of parts were water jet cut. The current line is laser cut. The water jet parts were not as nice as the laser cut parts.

I intended to ship the joystick with the rest, but well it got missed. I will ship it soon. Sorry…

[kurte]

Quick update on switch to new Arc32 and Arc32 version. First I found the wire that was shorting out and fixed it. For awhile I thought I must have had another issue with connections as the sequences I downloaded using my Extras and the VB app were not running right. But then I found I had introduced a new bug into the GP playing code which I fixed and it now is working again

FYI - Looking through my magnifying light and the like I did verify that the OLD arc32 had a 32k bit EEPROM, so I am having more luck saving out additional sequences.

Kurt