Inconsistant PWM outputs


#1

We are having issues with the cockpit crashing. We can open it up, but can not get all motors working at the same time. When we were finally able to get all four motors working, the cockpit suddenly crashed. After a short period, the cockpit would re open, but some motors would not work again. some motors would then only work in one direction. We have swapped the ESCs so we have confirmed it is not a throttle curve issue. Does anyone know why the PWM outputs change after crashing? How do we resolve this issue?


#2

My guess is the “cockpit crash” is the beaglebone dropping out from lack of power. What voltage does the cockpit display when it stops updating?

Double check for charged batteries. Are you using the Trust fires or the Lithium Iron batteries?


#3

There are some software issues with motor direction that have been fixed in the final software image, 2.5.1 final. It is important that after installing that update that you also then update the firmware from the setting screen so that the Arduino firmware matches the beaglebone image. If you have already done that then read on:

Are these 2.7 controller board based ROVs (2.7 kits with the Afro ESCs?). We are aware of an issue when testing in air where if you go from full forward to full back, many times the starboard motor won’t actually go in reverse. You then have to push the reverse command on the keyboard again to get it to respond. Let me know if that is what you are seeing.

On earlier version of the OpenROV software, the problem had to do with the command that initializes motor values in the Arduino having trouble communicating those values down to the Arduino. In many cases, a workaround was to go to the settings screen and then close it again using the close arrow. That would resend the values to the Arduino and many time make the motors respond correctly.

If none of the suggestion above match your experience, let me know and we’ll keep plugging at it.


#4

Well, this is actually a custom setup, we are using the open rov 2.6 board to have control and a camera feed. and we are using the 2.7 firmware product page.
We are using castle creations ice2 hv 60 escs with crust crawler thrusters. Our power is rewired, using a 24v system to power the escs coming from two 12v deep cells. Then dropping it down to 12 to power the open rov board. We also have a castle BEC wired in as the escs do not have their own BEC.


#5

Hmm, @Walt_Holm don’t know if you might have some ideas on troubleshooting the power given the custom setup. The drop out is most certainly the 5V regulator powering the beaglebone either cutting off or dropping so low the beaglebone brown out triggers.

Madi, what about the software?


#6

We took the 5volt regulator out and the beaglebone is still powered.


#7

We updated the Arduino firmware yesterday.


#8

Woah. Perhaps some misunderstanding. I am talking about the 5V regulator on the 2.6 controller board that takes the 12V battery in power. Are we talking about the same things?


#9

No. I’m talking about the bec. When it does crash it seems to boot far to quickly for the beaglebone to have reset.


#10

Okay. Interesting. If the cockpit stops updating it is one of three reasons:

  1. The beaglebone reset
  2. The Arduino went off-line
  3. Interruption of communication

If the Arduino went off-line, the lower right corner of cockpit that shows the runtime will reset to zero.

If the communication went down, it usually results in a loss of the middle light on the topside homeplug adapter. But now always.

If the beaglebone went down, the blue lights should have gone back to boot-up mode which ends once the cyclon like blue light starts moving back and forth. (Boot time is a bit over 1 minute)