Extension Development: "This extension is enabled but the container is not running"

As the title implies I am having issues where I upload an extension to BlueOS and I receive an error saying the extension is enabled but the container is not running.


When I check the console logs it also says that it is constantly trying to reconnect.

I had successfully uploaded an extension to read data from the blue robotics bar30 sensor and did not run into this error.

I am fairly new to software dev tools like git and docker so let me know if seeing what I wrote there will help get a better diagnosis.

Hi @DuncanODL -
Welcome to the forums!
It seems like the extension is failing to start, does the view logs button show anything?
What is the goal of this extension? It could be conflicting with existing processes if it’s attempting to do stuff with PWM?
If you can share your github repo for the extension, happy to take a look


Hi Tony,

View log shows nothing when opened.

Im trying to make sense of the software end of our project and wanted to play around with extension development by making a simple pwm sweeper and trying to connect it to the T200 motor I have on hand.

Im a MECHE so let me know if I am making any cardinal mistakes :slight_smile: .

Cheers,

Hi @tony-white ,

Ultimately I am trying to control a T200/M200 motor separately from the rest of the T200 motors that control the ROVs movements. Using a separate extension might not be necessary but I originally tried configuring and controlling the motor through the PWM Outputs tab to no success. Would this method for controlling the motor work? or should I continue trouble shooting the issues with the extension?

Hi @DuncanODL, welcome to the forum :slight_smile:

One of the example extensions includes PWM control, but that’s intended for if you don’t have a flight controller board connected.

From your initial post it seemed like this may have been your situation, but given you seem to be doing this as an extension of an ROV setup it completely changes which options are available, and how straightforward/involved they are.

What kind of control do you want over it (in terms of input and output, especially around gradations / speed levels)?

If you only want a few speeds you should be able to assign it as one of the incrementally controllable servo outputs ArduSub supports, and control it with joystick buttons and/or on-screen buttons in your control station software.

If you want smooth control over the speed then with Cockpit you could control it with a slider (although I’d recommend using a direct servo function over a lights function in this case, just to avoid confusion).

Hi @EliotBR ,

Thanks for getting back to me.

We are going to put together a custom ROV setup and will be using the navigator board so the PWM example wasn’t going to work. For the outputs both a smooth gradient and step gradient works fine.

I had connected the M200 motor to our PCB through the BR basic ESC. The PCB is then connected to the navigator board and the motor is connected to PWM 2. I assumed PWM 2 was mapped to ‘SERVO2_FUNCTION’ and tried testing the sliders below and got no movement.

Can you point me in the right direction to get this set up? I’ve dug around the BlueOS documentation a bit and inferred this was possible but didn’t see much in the way of explicit instructions. But maybe I wasn’t looking hard enough.

At this point I’m just playing around with the software trying to learn how to control the outputs and motors but eventually I will be using a separate motor thats not a M200 for this purpose.

The motor test sliders[1] are specifically intended for the vehicle motion motors/thrusters, which requires the vehicle to be armed (hence the “disarmed” toggle switch). Those sliders are linked to whichever pins the MotorN servo functions are specified as. In this case it looks like SERVO2_FUNCTION is assigned to Motor2, so the slider for Motor2 should be moving a motor connected to servo channel (output pin) 2.

Did the motor beep when you plugged it in? There should be three, short, rising beeps to indicate the three phases are connected correctly, then a low, long beep once a valid PWM signal is detected, followed by a high, long beep once a neutral (1500 ”s pulse-duration) PWM signal is detected, after which the ESC is armed and will allow moving the motor.

If the first three beeps didn’t happen then there’s an issue with the connection of the motor to the ESC, or the ESC isn’t powered correctly. If the last two didn’t occur then there’s either an issue with the signal wire connection, or the signal being sent over it.

Flight controller outputs are the domain of the autopilot firmware (ArduSub in this case), so which ones should be configured, and to what values, will not be found in the BlueOS documentation, which instead just tells you more generally how to configure autopilot parameters.

Unfortunately the ArduSub documentation is somewhat in flux at the moment, because it’s being transferred to a new site and largely rewritten, and ArduSub itself is also undergoing updates which change some of this functionality. For now, this is the old “servo output” documentation, with respect to joystick button functions. There is newer buttons documentation, but it doesn’t yet describe what the functions do.

In short, if you want to use the servo_1_* joystick button functions (which you can assign to your joystick buttons of choice in Cockpit or QGroundControl), you should connect your M200 to servo output pin 9, and set the SERVO9_FUNCTION to Disabled (0) (so it’s not being actively managed by an autopilot functionality).

Lights controls are more versatile, because you can specify them on arbitrary output pins, but then it’s less easy to get a consistent 1500”s neutral signal, which is required before the ESC will allow any motion to occur.

Using a standard motion MotorN function is also possible, but then you don’t have manual control over that motor in normal operation (only in a special motor testing mode), and using the motor requires the autopilot to be armed first.


  1. Note that blue robotics motors and thrusters are designed to be run in water, so they shouldn’t be run at high speeds or for long durations in air. ↩

1 Like

This is exactly what I was looking for!

Cheers,

1 Like