[Solved] Commands 65, 66, 67 seem hobbled.

Questions about using encoders with the Roboclaw product line
GeeklyGrey
Posts: 42
Joined: Thu Oct 08, 2015 11:41 am
Re: Commands 65 and 66 seem hobbled.

Post by GeeklyGrey »

I'll follow your lead here.
- I think you are right with your comment "it is outside of the data".
- How the data is sent is using my Visual Basic 5 interpreter/compiler which uses MSComm32.ocx the normal comms interface for that program and many others. I never had any issues with output and I have developed commercial software using that program over many years. Now it is just for hobby use.
I did think about the speed issue here and did a full compile and ran the exe version. That would do everything I expected except the 65.66.67 commands, so... no different to the interpretive /debug mode. The comm port is communicating without issues at 38400, have not had to slow it down or do anything as a work around for anything. A small delay after sending the roboclaw command has resulted in reliable reading of the feedback of "FF".

1 Have not used RealTerm really. downloaded something like it a while back when we were trying to solve a USB comms issue and I was going to try and watch the flow. Then that issue seemed to resolve itself and went away. But let me say up front that I am not proficient and will need to do some homework on that. Might need a couple of pointers in order to ramp up quickly.
2 Will send data via RealTerm as discussed and see what happens. I am running a log of things I have tried out to keep track of events best I can together with the command line in the hex form I have shown you. Maybe send a copy - perhaps by email to avoid burdening this thread?
3 Will document the settings as well.

Settings
I tried using the 'default settings' in IONmotion. then 'save settings' to see if it would clear out any blockage but no change. That removed all the S1-S5 settings and I saw no improvement. I tried to minimise the startup file that runs but it seems some of it needs to run to provide minimal settings.

I appreciate your comment that the commands are probably getting loaded and that there is no timeout possible after sending the 'FF'. That helps to complete the picture and remove some of the grey areas for me.

To finish with your last comment re home sensor.
At present the motors are sitting on my desk with some wires attached to S4,S5. My normal setting is Home(user) so the motors never need to do a 'home run' unless I am testing that user based function. When I am testing that section of software I need only touch the wires to achieve the home sensor signal and that works fine for my needs at this time. So my default is Home(user) and there is no machine sitting in a home switch activated position. Well not yet anyway! And in none of the tests was the home switch activation any part of the mix.

So I will set out to do the 'RealTerm' thing and try using a minimum set of startup settings added onto a 'default settings' base and see where that takes us.

Re calling in. I am located in New Zealand, about 4 or 5 hours behind you and a day ahead. I appreciate that you want to repair anything we can identify. So far I have not got into Skype but that might be a way to spend a bit of useful time on this. I have a day at home on my Wednesday. To have a chance to do anything I will need to load up both RealTerm and Skype and learn to use them by then if you think that would work.

Edit - Now got Skype and RealTerm.
mabrouk
Posts: 11
Joined: Wed Aug 26, 2015 8:52 am
Re: Commands 65 and 66 seem hobbled.

Post by mabrouk »

I tried command 67 many times but it does not work that's the motors do not start.

Also could not upgrade to the 4.1.15 - tried many times but ionmotion seems to have trouble upgrading the firmware. I even tried doing it via the bootloader but no luck either. IONMOTION version i have is 1.6.4
GeeklyGrey
Posts: 42
Joined: Thu Oct 08, 2015 11:41 am
Re: Commands 65, 66, 67 seem hobbled.

Post by GeeklyGrey »

Hi Mabrouk - thanks for making contact. Seems there is something affecting commands 65, 66,67. Recommend you monitor this thread and be available to contribute info on your settings. 'acidtech' will be assisting with this issue soon. Perhaps you could prepare some info about -exactly- what your settings are, what pins you use and what commands you use other than 67. Thanks
GeeklyGrey
Posts: 42
Joined: Thu Oct 08, 2015 11:41 am
Re: Commands 65 and 66 seem hobbled.

Post by GeeklyGrey »

Looking like commands 61 and 62 for setting positioning PID, also associated with positioning, are not working for me. Refusing to be accepted actually, and I seem now to have 67 not being accepted as well.

Sample command code for command 61 - use version without spaces or use realterm version below
Command 61 - x7 of 8 byte terms plus crc
P= 5000 I= 0 D= 0 MaxI=0 dedzn=0 minpz=-100 mxps=57600 CRC
803D 00001388 00000000 00000000 00000000 00000000 FFFFFF9C 0000E100 90C7
803D0000138800000000000000000000000000000000FFFFFF9C0000E10090C7
803D0000138800000000000000000000000000000000FFFFFF9C0000E100 (test this for CRC = 90C7 -ok)

or drop this into RealTerm
$80 $3D $00 $00 $13 $88 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $FF $FF $FF $9C $00 $00 $E1 $00 $90 $C7
Would not work for me.
My tester for RealTerm working is this command -runs motor2 and stops. Probably depends on suitable quad counts on encoders too.
$80 $2D $00 $00 $07 $D0 $00 $00 $07 $D0 $00 $00 $06 $D6 $01 $2F $87
Current profile S3=default, S4,S5=disabled, swap LIPO,MODE buttons, baudrate= 38400, batt cutoff 6v/15v main and logic. Current QPPS= 2000, Position PID= 2000,0,0 MinPos = -100, Maxpos = 57600
I use accel/decel 2000 or 3000 and speed 2000. Some of the commands have been x4 2000 for simplicity during this 'testing time'!

I have noticed that something is changing the Position-P and Position-D values. I keep finding that Position-P has been made to 0 and Position-D has been changed to 4.88281 Always that value. Have not yet pinned down what or when that is occurring but I have no values like that and I am gradually bypassing all the setup stuff in an attempt to find if any of my commands are involved. Usually occurs on startup of IONmotion but all the other values are retained correctly.
Although it seems motor accel, deccel and speeds are not saved or loaded. That could be helpful addition as I often have to reenter them when I restart IONmotion, that's frequently at present.
GeeklyGrey
Posts: 42
Joined: Thu Oct 08, 2015 11:41 am
Re: Commands 65, 66, 67,61,62 seem hobbled.

Post by GeeklyGrey »

Hi acidtech - got something here for you to have a look into.
I have cut and pasted a part of my debug log on this project and I think that I have narrowed the field down to only five haystacks .er commands! that are linked in their functions and their problems.
Current situation is that I now seem unable to get 67 and additionally 61,62 to enter into roboclaw.
Commands 65,66 enter but will not work.
Sorry it is a bit long again but it should help with understanding my narrowing down process.
From my log...

Have found that in IONmotion Position P and Position D are being altered by something. Position-D ends up with value like 4.88281 and Position-P ends up as 0.
Set the values as wanted - disregard accel,decell and speed, they seem not to be saved currently.
Click on Device/Save Settings.
Click on Device/Disconnect and close IONmotion.
Start application.
On startup of the application the commands used are:-
Command 21 - read firmware version
Command 57- set main batteries min and max to values 60 and 150 (6v/15v)
Command 58-set logic batteries min and max to values 60 and 150 (6v/15v)
Then on clicking the initialisation button the following is occurring:-
Command 22 - set Encoder1 value to 11520
Command 23 - set Encoder2 value to 11520
Command 28 - set motor1 velocity PID,QPPS. Values used in order are:- PID,0,0,0 QPPS=2000
Command 29 - set motor2 velocity PID,QPPS. Values used in order are:- PID,0,0,0 QPPS=2000
Command 61 - set motor1 position PID,MaxI, DeadPos,MinPos, MaxPos. Values in order are
2000,0,0,0,0,-100,57600
--------------------------------------------
At this point I happened to have a temporary exit from the sub after command 61 and before 62
I noted that only motor1 was affected by 4.88281 value on the last run through.
Command 61 looks like:-
' 61 2000 0 0 0 0 -100 57600 CRC
803D 00001388 00000000 00000000 00000000 00000000 FFFFFF9C 0000E100 90C7
803D0000138800000000000000000000000000000000FFFFFF9C0000E10090C7
$80 $3D $00 $00 $13 $88 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $FF $FF $FF $9C $00 $00 $E1 $00 $90 $C7
It fails to be accepted

Dropped the application, started IONmotion. Device/connect -click position settings - screen loaded with value 4.88281 in motor 1 Position-D and Position-P was set at 0. All other values ok- this was a fresh load of IONmotion. So where does that value come from? THEN click on Device/Read Settings and correct value comes up. Click on Device/Default settings and they all turn to zeros. So 4.88281 does not come from there.
It seems to be a clue that something is writing to a wrong location.

Corrected the values and device/save settings. Device/disconnect closed IONmotion.
Relocated the temporary exit from my initialisation sub to below command 62
Now going to be doing BOTH command 61 and command 62
Result get command 62 failing as well
' 61 2000 0 0 0 0 -100 57600 CRC
803E 00001388 00000000 00000000 00000000 00000000 FFFFFF9C 0000E100 91CC
803E0000138800000000000000000000000000000000FFFFFF9C0000E10091CC
$80 $3E $00 $00 $13 $88 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $FF $FF $FF $9C $00 $00 $E1 $00 $91 $CC

Drop the application, load IONmotion - device/connect -click position settings.
THIS time BOTH position-P=0 and BOTH position-D = 4.88281

Got to be a connection there. Will try again and leave motor 1 out. device/load settings - correct values appear.
Device/save settings. device/disconnect. Close IONmotion.

Start application, run same initialisation excluding command 61
Command 62 fails, close application, start IONmotion. Roboclaw remains on and RAM memory probably unaltered. - device/connect -click position settings.
HAAAA - = THIS time ONLY motor2 position-P=0 and ONLY motor2. position-D = 4.88281
This seems repeatable and controllable.


It looks like a memory location is being written over during attempts with command 61 and 62. And this may be a cause or symptom of something else. Then when device/read settings is used the STORED values are dragged out into the same location and all looks well until that memory is written over again.

THEN I went through the first part of the initialisation again checking that the early commands were not seeming to be involved. They were not.
Seems it is only command 61 and 62 involved in producing this effect on the PID tables.
------------------------------
So that is what I have identified and hope it helps.
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Commands 65, 66, 67 seem hobbled.

Post by Basicmicro Support »

1. I cant remember if you said you are using our arduino lirbary or are coding your own from scratch. Please confirm one or the other. If you are coding your own please show the code you use for commands 61/62

2. If looks like your SetM#PositionPID arguments are in the wrong order(baseed on your binary data being sent). The SetM#PositionPID packet serial commands take the PID arguments in D,P,I order(this is an old holdover form a long time ago but we have never changed it because we were worried it would break old user code). Our arduino library takes those arguments in P,I,D order(because the D,P,I order was causing a fair number of tech support calls from aruduino users we made the arduino library functions use P,I,D order) and then properly sends the values to the Roboclaw in D,P,I order(as documented int he manual).

3. Remove the PID settings from the equation. Set the values using IonMotion and save them to the roboclaw. Remove the commands 61/62 from your program and retest please.

Thanks, I'll be waiting for your replies.
GeeklyGrey
Posts: 42
Joined: Thu Oct 08, 2015 11:41 am
Re: Commands 65, 66, 67 seem hobbled.

Post by GeeklyGrey »

Hi acidtech
Very quick reply as I have to get to work.
I use my own code, it is all in the sequence PID
--oops I see the manual is DPI. WILL change that and test later. How confusing is that?!

Not really practical to send you code as my system parses a command structure that manages all of roboclaws commands. The output string that I send you is what is being sent to roboclaw.
Per my last posting:
803D0000138800000000000000000000000000000000FFFFFF9C0000E10090C7
$80 $3D $00 $00 $13 $88 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $FF $FF $FF $9C $00 $00 $E1 $00 $90 $C7
First line is the actual sequence of bytes, The second line will operate RealTerm. Lines are produced together in my code. These will now be in error as noted above.

Will retest with correction and look for downstream effects on cmd 65,66,67

EDIT - Did a quick fix of commands 61,62 and they seem to have operated ok.
Believe other issues re 65,66,67 still there but I need to do more checking. (Just completing a major structure reshuffle since we last traded posts but it is now much easier to work with.)

Will be in touch again later tonight.
GeeklyGrey
Posts: 42
Joined: Thu Oct 08, 2015 11:41 am
Re: Commands 65, 66, 67 seem hobbled.

Post by GeeklyGrey »

Appears I had the PID values for Position in PID order instead of DPI that should be used for command 61,62.
Again some notes from my log. We ARE getting somewhere now but read to the end for the result!

Now I seem to have the 4.88281 value showing up in the Position-P fields. Position-I and Position-D are 0
On the Position panel in IONmotion the panel came up with those values straight from roboclaw after trying to use command 66 that is still not working. Accel and deccel still showing 0. Sliders can make some motion and speed is very low. Suspect some other values are wrong but where?
Needed a value in P that is a LOT bigger than 4.88281, so I put back the 5000 values and save.
Drop IONmotion.
On starting up my application command 63 is now reading a value of 5120000 for Position-P. This is a factor of 1024 different. That is not a number I use in my system but it is certainly a computing number.
Drop application and start IONmotion - read position-P - still on 5000. Change it to 4000 and save it.
Drop IONmotion and start my application again.
On starting up application command 63 is now reading a value of 4096000. This is a factor of 1024 different again. Either the command output is wrong or the manual is wrong? The 5000/4000 and 5120000/4096000 values are still exactly proportional and the factor 1024 is not being generated by my application. So there is a distinct difference between the values being read and saved in IONmotion and those being generated by commands 62,63.
Now compare with set commands 61,62 - saved the value 5000 into Position-P for motors 1 and 2. Dropped application, started IONmotion. Position settings panel comes up with 4.88281 in both motor 1 and 2.
5000 / 1024 = 4.88281
Proof of which program is using a 1024 factor comes from RealTerm.
From the application command log for command 63 for reading motor 1 sent (in RealTerm version) $80 $3F
The response in RealTerm was "00 00 13 88 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF 9C 00 00 E1 00 61 2A"
Spaces removed we get this line that is completely identical to the input received by my application.
0000138800000000000000000000000000000000FFFFFF9C0000E100612A
Broken to 4 byte blocks and converted to decimal we get:
5000 0 0 0 0 -100 57600 CRC16
00001388 00000000 00000000 00000000 00000000 FFFFFF9C 0000E100 612A
Which is exactly what was sent to RoboClaw by my application in the first instance.

Set my application to send values of PID 5000,100, 32200 just to see what saves and what IONmotion sees.
Check the result received by RealTerm from RoboClaw -
00 00 13 88 00 00 00 64 00 00 7D C8 00 00 00 00 00 00 00 00 FF FF FF 9C 00 00 E1 00 12 06
000013880000006400007DC80000000000000000FFFFFF9C0000E1001206
00001388 00000064 00007DC8 00000000 00000000 FFFFFF9C 0000E100 1206
5000 100 32200 0 0 -100 57600 crc16 decimal conversions
Which again are exactly the values sent to RoboClaw by my application.
Now to look at what IONmotion says:
IONmotion Position settings now read:
Position-P both motors - 4.88281
Position-I both motors - 0.09766
Position-D both motors - 31.44531

So... IONmotion is using an undocumented value conversion of 1024 both saving and reading Position PID's. This could account for the great difference in results being achieved. In using values as determined in IONmotion it will be necessary to for my application and RoboClaw to have numbers 1024 times bigger than has been apparent.

Where we seem to be at is: RoboClaw, the current manual, my application and RealTerm are all in agreement.
Position PID values displayed and used in IONmotion are factor of 1024 smaller than in any of the above.

Your move...!

EDIT - Have just entered Position-P values of my 5000 value *1024 =5120000 into my application and from there to RoboClaw. Then Commands 65,66,67 all worked immediately!!! Some acceleration issues to sort yet but those PID values are the main problem in a nutshell.
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Commands 65, 66, 67 seem hobbled.

Post by Basicmicro Support »

That is correrct. The position PID values have to be * 1024 before sending to the Roboclaw. The Velocity PID values have to be * 65536 before sending. This is assuming you are using the values you determined from IonMotion. IonMotion displays the floating point equivalent of the fixed point numbers Roboclaw actually uses.

The Roboclaw Arduino/Python/C# libraries we provide does this conversion for you.

Does that mean this thread is solved now? If not let me know if I missed something.
GeeklyGrey
Posts: 42
Joined: Thu Oct 08, 2015 11:41 am
Re: [Solved] Commands 65, 66, 67 seem hobbled.

Post by GeeklyGrey »

It does look like we can call this solved.

It would, however, have saved me an enormous amount of time and effort if that little fact had been made a LOT clearer up front. The values 1024 and 65536 do not appear in the revision 5 manual, and do not appear in the forum notes except in this thread in these last few posts. So how could I or anybody have known about it. Not impressed.

Moving on...

In the manual you have commands. One could assume that if any one is reading about a particular command it is because they actually need to know about it, and need to transmit correct values. If someone is using a library they wont be looking at the manual for the direct coding version of the command don't you think.

Since I am considering your customers I want to see a remedial note included in the manual.
A statement placed in the manual just before commands 61, 62, 63, 64, 65, 66 and 67 to explain the need to 'scale ' the values would do the trick. I am not aware of any existing statement to that effect in the manual but stand to be corrected if I am wrong.

Something along the lines of:
"Scaled values in IONmotion.
IONmotion is useful for preliminary tuning of Position PID values that can then be utilised in applications.
Please note, however, that values displayed and utilised within IONmotion for the Position-P, Position-I and Position-D values are scaled. The actual numbers sent to and stored within RoboClaw are equal to displayed value * 1024.
When using Commands 61, 62, 63, 64 directly in your application to read or set PID, or using motion commands 65,66 or 67 please use 'displayed value * 1024'. If using a library this adjustment may already be included."

If velocity PID values are also affected in this way then appropriate notes should be applied there as well.

And please include a note in each of all the affected commands to the effect:
"Refer to scaling note on page xx for actual PID values sent to RoboClaw."

Obviously you will massage this to suit yourself but I sincerely hope you will commit to including it.
You may respond hopefully to acknowledge an acceptance of this resolution and to sign off this thread.

Post Reply