search

kiddjmadd / motor_shield_w_enc

my attempt at hacking the STEVAL-EDUKIT01 to use the encoder timer function and swing itself up
1 stars 2 forks source link

Pendulum is not starting to swing #1

Open OevreFlataeker opened 3 years ago

OevreFlataeker commented 3 years ago

I tried your firmware for performing a swing-up on the EDUKIT01 but I doesn't seem to work properly for some reason.

If I debug and single-step through the code:

  HAL_TIM_Base_Start_IT(&htim10);

  uint16_t my_del = 40; // 100 works, 108 is KOM
  int16_t my_highest_pt;
  BSP_MotorControl_Run(my_dev,FORWARD);
  HAL_Delay(2*my_del);
  BSP_MotorControl_Run(my_dev,BACKWARD);
  HAL_Delay(2*my_del);
  BSP_MotorControl_Move(0, BACKWARD, 1);

The pendulum starts to swing up but oscillates so much that the cable of the rotary encoder eventually twists (more than 2 full revolutions of the encoder).

If I just let it run uninterrupted I can just hear the motor hum very quickly so as if it is doing very fast and short movements and the whole motor turns veeeery slowly CCW but nothing else happens - no swing-up or anything.

Using the original firmware provided by ST the control loop seems to be very unrobust? When the pendulum is held up-right only very light touches can make it still fall-over and the system does not recover. Is this the same result you see too? There is a video on https://youtu.be/blafvMdfmYU?t=5 which suggests it's very robust.

Can you tell me more about your experience with the kit so far? Thank you!

OevreFlataeker commented 3 years ago

You also mentioned you had to change a GPIO pin of the rotary encoder? I can't seem to see which one is used or what is different. I have still connected everything like shown in the original manual. What is different in your setup?

kiddjmadd commented 3 years ago

Hi, Thanks for your interest! That youtube video is impressive, he must have made some upgrades. Mine was not that robust (still isn't). Good to know the hardware is capable of this.

I think you're on the right track with the encoder wiring. Original out of the box code is closed source, but based on the nucleo docs he must have implemented the encoder in firmware. I decided to use the hardware encoder. The downside to that approach was it needed a pin on the bottom of the board (see attached; this connects to the white encoder wire). That means the board can't be mounted to the top without modification (I just leave it disconnected). The green encoder wire went to pmw2 on the top (not sure if that matched original configuration or not).

The serial connection will provide some feedback. If the encoder is connected and working correctly, the serial connection will print an unsigned integer (I think it was between 0 and 1199) along with some other values.

Project is a work in progress and updating the wiring won't make this perfect, but should get you on track to use the encoder for branching and feedback.

[image: nucleo_bottom.png]

Thanks

On Sun, May 16, 2021 at 7:54 AM daubsi @.***> wrote:

You also mentioned you had to change a GPIO pin of the rotary encoder? I can't seem to see which one is used or what is different. I have still connected everything like shown in the original manual. What is different in your setup?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kiddjmadd/motor_shield_w_enc/issues/1#issuecomment-841806981, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHQHQK24CT4SYC7MDCWKUDTN6W75ANCNFSM446XGSBA .

kiddjmadd commented 3 years ago

Seems inline photo doesn't come up on github page. I'll add as attachment to see if that works better.

On Sun, May 16, 2021 at 8:22 AM Jesse Madsen @.***> wrote:

Hi, Thanks for your interest! That youtube video is impressive, he must have made some upgrades. Mine was not that robust (still isn't). Good to know the hardware is capable of this.

I think you're on the right track with the encoder wiring. Original out of the box code is closed source, but based on the nucleo docs he must have implemented the encoder in firmware. I decided to use the hardware encoder. The downside to that approach was it needed a pin on the bottom of the board (see attached; this connects to the white encoder wire). That means the board can't be mounted to the top without modification (I just leave it disconnected). The green encoder wire went to pmw2 on the top (not sure if that matched original configuration or not).

The serial connection will provide some feedback. If the encoder is connected and working correctly, the serial connection will print an unsigned integer (I think it was between 0 and 1199) along with some other values.

Project is a work in progress and updating the wiring won't make this perfect, but should get you on track to use the encoder for branching and feedback.

[image: nucleo_bottom.png]

Thanks

On Sun, May 16, 2021 at 7:54 AM daubsi @.***> wrote:

You also mentioned you had to change a GPIO pin of the rotary encoder? I can't seem to see which one is used or what is different. I have still connected everything like shown in the original manual. What is different in your setup?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kiddjmadd/motor_shield_w_enc/issues/1#issuecomment-841806981, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHQHQK24CT4SYC7MDCWKUDTN6W75ANCNFSM446XGSBA .

kiddjmadd commented 3 years ago

Sorry, that didn't seem to work either. The white encoder wire should connect to pin PA15 or the Nucleo F401RE. (Ref sheet 32 of https://www.st.com/resource/en/user_manual/dm00105823-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf). Hope this helps!

On Sun, May 16, 2021 at 8:29 AM Jesse Madsen @.***> wrote:

Seems inline photo doesn't come up on github page. I'll add as attachment to see if that works better.

On Sun, May 16, 2021 at 8:22 AM Jesse Madsen @.***> wrote:

Hi, Thanks for your interest! That youtube video is impressive, he must have made some upgrades. Mine was not that robust (still isn't). Good to know the hardware is capable of this.

I think you're on the right track with the encoder wiring. Original out of the box code is closed source, but based on the nucleo docs he must have implemented the encoder in firmware. I decided to use the hardware encoder. The downside to that approach was it needed a pin on the bottom of the board (see attached; this connects to the white encoder wire). That means the board can't be mounted to the top without modification (I just leave it disconnected). The green encoder wire went to pmw2 on the top (not sure if that matched original configuration or not).

The serial connection will provide some feedback. If the encoder is connected and working correctly, the serial connection will print an unsigned integer (I think it was between 0 and 1199) along with some other values.

Project is a work in progress and updating the wiring won't make this perfect, but should get you on track to use the encoder for branching and feedback.

[image: nucleo_bottom.png]

Thanks

On Sun, May 16, 2021 at 7:54 AM daubsi @.***> wrote:

You also mentioned you had to change a GPIO pin of the rotary encoder? I can't seem to see which one is used or what is different. I have still connected everything like shown in the original manual. What is different in your setup?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kiddjmadd/motor_shield_w_enc/issues/1#issuecomment-841806981, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHQHQK24CT4SYC7MDCWKUDTN6W75ANCNFSM446XGSBA .

kiddjmadd commented 3 years ago

It looks like my previous statement about the out of the box project being "closed source" is no longer accurate. When I started with this in October 2020, there was no source available. As of January 2021, it seems the project files for Cube IDE have been posted.

Please see https://www.st.com/content/st_com/en/campaigns/educationalplatforms/motorcontrol-edu/resources.html

It would likely be better to start with those as doing so would obviate the need to rewire for the hardware encoder. Not sure what the licensing is for ST Micro's project, so if I restart using that as the basis, I won't post to github (or maybe I'll just post some of my snippets).

Thanks

On Sun, May 16, 2021 at 8:44 AM Jesse Madsen @.***> wrote:

Sorry, that didn't seem to work either. The white encoder wire should connect to pin PA15 or the Nucleo F401RE. (Ref sheet 32 of https://www.st.com/resource/en/user_manual/dm00105823-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf). Hope this helps!

On Sun, May 16, 2021 at 8:29 AM Jesse Madsen @.***> wrote:

Seems inline photo doesn't come up on github page. I'll add as attachment to see if that works better.

On Sun, May 16, 2021 at 8:22 AM Jesse Madsen @.***> wrote:

Hi, Thanks for your interest! That youtube video is impressive, he must have made some upgrades. Mine was not that robust (still isn't). Good to know the hardware is capable of this.

I think you're on the right track with the encoder wiring. Original out of the box code is closed source, but based on the nucleo docs he must have implemented the encoder in firmware. I decided to use the hardware encoder. The downside to that approach was it needed a pin on the bottom of the board (see attached; this connects to the white encoder wire). That means the board can't be mounted to the top without modification (I just leave it disconnected). The green encoder wire went to pmw2 on the top (not sure if that matched original configuration or not).

The serial connection will provide some feedback. If the encoder is connected and working correctly, the serial connection will print an unsigned integer (I think it was between 0 and 1199) along with some other values.

Project is a work in progress and updating the wiring won't make this perfect, but should get you on track to use the encoder for branching and feedback.

[image: nucleo_bottom.png]

Thanks

On Sun, May 16, 2021 at 7:54 AM daubsi @.***> wrote:

You also mentioned you had to change a GPIO pin of the rotary encoder? I can't seem to see which one is used or what is different. I have still connected everything like shown in the original manual. What is different in your setup?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kiddjmadd/motor_shield_w_enc/issues/1#issuecomment-841806981, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHQHQK24CT4SYC7MDCWKUDTN6W75ANCNFSM446XGSBA .

OevreFlataeker commented 3 years ago

Hi, thanks for that info. I am not really sure I understand why you had to rewire. The setup as described in the original manual on the ST page ("User guide for EDUKIT"), clearly shows where the 4 wires of the encoder have to go and all the firmware files I found so far seem to work like it is. Why did you have to change something at all? Ofc it might be that the first release of the software was not fully functioning and the one I found was. I also found another firmware file that I flashed today and this control is VERY robust. You can hit the arm quite hard and it will immediately recover like shown in the video I linked earlier. I also got the Matlab files to work. Seems they can only be used once the pendulum is already in balance and the firmware starts sending stats over UART - not before. If you want to give me you email I can send you the firmware file. Also would like to continue the conversation via mail then if you like. Thanks!

kiddjmadd commented 3 years ago

That's great they made improvements. I'd be interested to see the new firmware. I wonder if it's compiled from the rev 2 at ST Micro's website.

My rationale for rewiring was based on using the hardware encoder in the 401RE. That functionality is limited to certain pins which is why I had to reassign and rewire. Some background is at http://www.emcu.eu/how-to-interface-the-rotary-encoder-to-stm32-cube-mx-atollic/ and in this video https://youtu.be/GoRYhhdVR3M (in Russian but gets the point across and the C is in English).

Prior to ST Micro releasing the real source, the only alternative would have been to implement the encoder using GPIO which sounded more time intensive than I wanted.

Quite busy at work so it's not clear when I'll be able to look at this again, but I'd be interested to continue the conversation. My gmail ID is jesse.madsen175 if you want to shoot me a note. (Don't want to write the whole thing out for the spam-bots). Thanks!

On Sun, May 16, 2021 at 9:35 AM daubsi @.***> wrote:

Hi, thanks for that info. I am not really sure I understand why you had to rewire. The setup as described in the original manual on the ST page ("User guide for EDUKIT"), clearly shows where the 4 wires of the encoder have to go and all the firmware files I found so far seem to work like it is. Why did you have to change something at all? Ofc it might be that the first release of the software was not fully functioning and the one I found was. I also found another firmware file that I flashed today and this control is VERY robust. You can hit the arm quite hard and it will immediately recover like shown in the video I linked earlier. I also got the Matlab files to work. Seems they can only be used once the pendulum is already in balance and the firmware starts sending stats over UART - not before. If you want to give me you email I can send you the firmware file. Also would like to continue the conversation via mail then if you like. Thanks!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kiddjmadd/motor_shield_w_enc/issues/1#issuecomment-841818057, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHQHQIOD2PBQXBJVVPCT6DTN7C25ANCNFSM446XGSBA .