Page 1 of 1

After firmware update RC is not working as expected

Posted: Wed Oct 24, 2018 2:55 am
by Joe
After longer time I decided to update my RC2x30 firmware from 4.1.24 to 4.1.27 due to the possibility of saving different profiles. After update all settings on my RC were gone. :o
I tried to configure everything again, but RC is not working as before with 4.1.24 firmware. For example motors running in the wrong direction related to the encoders. Encoders are not sending position over serial connection to an Arduino. Voltage and temp is not tansmitted over serial after moving commands and so on.

I tried to reset the device and also did the update procedure again. With 4.1.24 everything worked fine. What should I do?

Auto Tune

Posted: Wed Oct 24, 2018 8:03 am
by Joe
Why does auto tune M2 affect the values (PID) of M1?

Re: After firmware update RC is not working as expected

Posted: Wed Oct 24, 2018 9:48 am
by Basicmicro Support
I merged your two posts becasue they are all related(eg problems after your firmware update).

Motor direction may have changed depending on the model of the Roboclaw you have. However you can change the relative direction in General settings now. Check the M1 Reverse and/or M2 Reverse check boxes to change the motors relative direction to control inputs without needing to change the physical wires.

The only changes for 4.1.27 was primarily the name change from Ion Studio to Basicmicro Motion Studio. We also removed the leaky integrator and added a back calculator instead of intergral windup. No changes where made to packet serial commands them selves.

Im looking at the Auto tune M2 function.

Since you seem to be having a number of problems no one else has reported and I havent seen myself I'd like to have you call in to the 800 number so I can work with you live to try to determine the cause of the problems.

Re: After firmware update RC is not working as expected

Posted: Wed Oct 31, 2018 10:13 am
by Basicmicro Support
I just tested a Roboclaw with RC signals and have seen no random changes of direction. I power cycled the unit a dozne times and also disconnected and reconnected the RC signals while running, on both channels. I never saw the motors reverse the direction relative to the RC control inputs.

Note, there has been no changes to RC control mode since 4.1.25 so I would not expect anything specificly in RC control to have an issue.

However, we did add a software option to reverse the motors(setting is in General Settings). I recommend you reset the Roboclaw to defaults(Device Menu in Motion Studio) and setup the unit again for RC mode just to be sure no bad data is in the settings from a preivous version. Depending on how old your previous firmware was the default relative direction of each motor channel may not be the same as that older firmware version but you can use the software setting to change the relative direction to whichever direction you want now(unlike previous firmware versions).

Also keep in mind RC mode by default auto calibrates the center(stopped position). If your RC radio isnt powered on or doesnt start sending RC pulses at the center point on power up that can cause the stopped position to drift(eg the motors start moving when in RC mode because the Roboclaw saw a different "stopped" pulse than normal during power up). Some RC receivers have a "safe" mode where if they do not have a connection to the remote control, they will instead output a preset RC pulse which isnt always centered. This can cause the autocalibrate to be wrong as well.

You can test if this could be an issue by disabling autocalibrate. Check the MCU check box setting to disable autocalibrate. After this the Roboclaw assumes 1.52ms pulses are zero/stopped. This is the default center position on most commercial RC radios(assume your trim is centered). Re-test and get back to me on your problem.

P.S. There is a bug in the Motion studio PC application where the Velocity Autotune M2 button is sending the values returned from Autotuning to the M1 PID edit fields instead of the M2 edit fields. This has been fixed and will be in the next release. You can email support for the pre-release if you want it sooner. Until then the values are valid but will need to be manually moved to the M2 PID fields.