Home Community Blog Buy Now

Misty Community Forum

Auto Docking JS skill

Here is an attempt to auto dock from a JS skill using the Charger Pose Detection


In your video, the robot is on the charging pad facing toward the reflectors, whereas the documentation instructs us to have the robot face outward:

Place Misty on the center of the charging station. Position her to be facing out, with her back against the rear compartment of the charging station, and make sure the arrows on Misty’s base are lined up with the arrows on the charging station.

(quoted from https://docs.mistyrobotics.com/misty-ii/robot/misty-ii/#charging-misty-ii)

Can you comment on the difference?

With respect to Misty’s charging status: I just tried this on my Misty. I could not get it to charge if Misty was facing the charger.

Try moving Misty a little further outward from the charger.
Thats why I had to back up Misty in the skill after making contact with the charger’s wall.
Let me know if it works :slight_smile:

It believe it is a circular coil used for charging. So as long as Misty is in alignment with the coil, it must charge irrespective of the direction Misty is facing.

It is great you brought up the instruction that says " make sure the arrows on Misty’s base are lined up with the arrows on the charging station " => The arrow printed on Misty and the charging station is intended to be used when Misty is facing outward from the charger. That marked point is not symmetric about the robot’s length nor is the coils placement and hence in this case when Misty is looking inwards the printed marks would not align for the optimal charging location marked on the charging station.

May be in the next update to the skill, I will try to see if can consistently turn and backup Misty into the charger so Misty is facing outwards.


Indeed, actually this has been clear since I first read the instructions many months ago, but it begs the question: why are the instructions written that way when it is not a requirement?

Furthermore, the robot does not need to be centered. I have an automatic docking routine that reverses onto the pad, and sometimes it is off center but finds a pose where charging begins.

So, this begs another question: how bad is it when the charging pose is not “optimal”? Does it affect anything besides time required to fully charge?

The drop off in charging efficiency is pretty drastic from the sweet spot. Otherwise, there aren’t any adverse effects of which I am aware.

We have another auto charging example in house where we use a 3d printed alignment rail to make hitting the sweet spot easier.

Is there a method to decide from software whether the robot is on the sweet spot?

In my code, I simply check whether the API reports that the battery is charging, but it seems that that does not indicate efficiency. Perhaps I must check the magnitude of the ingress current?

There are two things you can check. You could subscribe to the BatteryCharge event and check the current (positive charging, negative discharging) or lower level you can subscribe to the PRUMessage event which comes directly from the wireless charger and check iout (this will be current coming out of the PRU).

1 Like

I did as you suggested. Moving Misty away from the back wall of the charger did start Misty’s front lights flashing, indicating it is charging.

1 Like

@slivingston & @BoulderAl: I was wrong about the marking mis-alignment on the Docking station and Misty. The printed marks on the pad and Misty both represent the center of the coils; So as long as the printed marks on Misty matches with the printed marks on the dock, Misty will charge in either direction ! Thanks for the catch @arobodude !


@cp_sridhar didn’t mention what I think is one of the most interesting problems he solved with this skill outside of auto-docking itself, which is that if Misty is blocked during her circuit (for example, if you trigger the hazards system by walking in front of her), she’ll stop until the obstacle is removed, and then resume the circuit. This is demonstrated in the video when Misty is blocked by the box.

:robot: :arrow_right:
:robot: :card_file_box:
:robot: :stop_sign:
:card_file_box: :boom:
:robot: :arrow_right:

1 Like

Hi @cp_sridhar, I placed Misty 1.5 meters away from the docker. She was looking to the docker following your instruction. Instead of parking, my Misty reversed first, then turning around, then driving away from the docker. Well, she did not dock. What should I do please?

Many thanks.

Best regards,

Hi @aria.zhenzhenli,

Glad that you are trying it out ! The example assumes that Misty is already on the docker and is charging when the program starts (I should probably add a check there :smiley:).

In the below example Misty starts with undocking (driving back and turns), and then drives through the circuit. You could modify the circuit function to change the path Misty drives.

function loop() {
   _ = undock();
   _ = circuit();
   _ = dock(hasGuideRail = false);

To just dock, you could comment out line-62 that calls the loop function and add

 _ = dock(hasGuideRail = false);

to line63… This should start docking Misty as soon as the skill starts :slight_smile: !
Let me know how it worked out !! :v:t3:

Hi @cp_sridhar, thank you so much for this fast response.

I have tried the two scenarios out:

  1. No modification to the code. I placed Misty on docker at her normal charging position. Misty turned herself around on the docker and stopped because she sees the docker as a hazard.

  2. Comment out loop() and added _ = dock(hasGuideRail = false) as suggested. Misty stayed where she is and no response whatever.

The ideal solution is that Misty can find her docker and dock herself no matter where she is. Is it possible to do that?

I am trying to understand SLAM for Misty but the API Explorer gives me little understanding on what is going on.

Do you have sample codes on how to teach Misty to walk around the office and docker herself?

Many thanks.

Best regards,

Hello all,
I’m new to Misty, just got it last Friday. While playing with autoDock, I encountered stability issues in IR sensor and Wifi connection. I wonder if anyone has insights to this subject.

Specifically, I experienced two problems. One is that ChargerPoseMessage is not consistently populated with IR sensor data (i.e. docker location data). When Misty is fully charged and rebooted, I get data about 9 out 10 times. When I restart the skill, I often get all values to 0. I stop all skills, wait several minutes, and reload the skill, and then sometimes I get docker location data. When the battery level is below 75% (~7.5V), the problem seems to become more prominent. At this level, rebooting does not always help.

Second, WIFI connection gets lost when Misty gets stuck in motion. This happens when Misty tries to move her head to a certain position and gets stuck for some reason. Trying to kill the skill fails because of the lost wifi connection.

I’m running the following versions:
Robot Version:
Sensory Services Version: 1.19.1
Windows OS Version: 10.0.17763.253

Title: stability of IR sensor and Wifi connection

  1. The event data ChargerPoseMessage is not populated by IR sensor.
  2. Wifi connection to the robot is lost when the robot is stuck in certain motion.

How to recreate the issues:

  1. Place and run the function point2Dock() in autoDock.js. Stop and restart the skill. Restart the skill when the battery level is below 75% (~7.5V). Are you getting the docker location data?
  2. Add two more lines of misty.MoveHead(misty.Get(“HP”) + 18, misty.Get(“HR”), misty.Get(“HY”), null, 1); and restart the skill. When it gets stuck, try to stop the skill. Is wifi connection alive?

I hope to find solutions to these issues. Thanks!

function point2Docker() {
    // SI 2020/10/21 "point2Docker" follows the simplified logic from autoDock's dock().

    // Move Misty's head to a predefined position (i.e. 0,0,0)
    misty.MoveHead(misty.Get("HP"), misty.Get("HR"), misty.Get("HY"), null, .5);

    // Required API call to start docker tracking sensor

    // wait a little for sensors to start

    // infinite loop to display docker location data and point Misty to docker
    while (1) {

    // Check if Misty can see docker or try to find it
        //_ = findDocker();
    // findDocker never worked in my Misty, causing unexpected behavior. Needs a better method.

    // 1. Call lookAtCharger function to make xOffset = 0
        _ = lookAtCharger();
    // When IR data is lost, lookATCharger causes undesirable behavior

    // Wait for measurement data to stabilize

    // 2. Get sensor data
        var yRotation = misty.Get("yRotation");
        var xOffset = misty.Get("xOffset");
        var zOffset = Math.abs(misty.Get("zOffset"));
        var lookAtChargerOffset = misty.Get("lookAtChargerOffset");

    // 3. Calculation
    // Calculate inner angle between Misty Z axis and the XY plane of the docking station
        var angleInside = -1.0 * Math.sign(yRotation) * 90.0 + yRotation;

    // Calculate Ground Plane distances along Docking Station X and Z axis to Misty
        var hDrive = Math.abs(xOffset) + 0.035; // 3.5cm correction accounts for offset of Misty Camera frame along X axis from the centre of Misty 
        var vDrive = Math.abs(zOffset);

        misty.Debug("X: " + xOffset.toFixed(2).toString() + " Z:" + zOffset.toFixed(2).toString() + " Yrot:" + yRotation.toFixed(2).toString() + " Look@:" + lookAtChargerOffset.toFixed(2).toString())
        misty.Debug("Angle Inside Cone");

    // 4. Drive to a point in line with docker z axis and face the docker
        if (!(Math.abs(xOffset) < 0.15)) {
            _ = turn(angleInside);
            _ = drive(hDrive);
            _ = turn(Math.sign(angleInside) * -90.0);
            _ = lookAtCharger();

    // 5. Look down and Drive close to docking station 
        misty.MoveHead(misty.Get("HP") + 18, misty.Get("HR"), misty.Get("HY"), null, 1);
    // In original function dock(), this line is repeated 3 times. Misty gets stuck in motion, lose Wifi connection.

    // 6. If xoffset is small enough, drive Misty closer to docker, otherwise exit the loop.
        if (Math.abs(xOffset) < 0.15) {
            if (vDrive - .30 > 0) {
                _ = drive(vDrive - .30);
            else {
                misty.Debug("Sensor data show Misty is close to Docker.")
        misty.Debug("one loop complete")

    // Stop the ChargePoseMessage event monitoring
    return 0

I forgot to mention, though it should be obvious, that the robot must be facing somewhat toward the docker as its initial orientation in order for the point2Dock function to work. This is because I commented out the findDocker function. By the way, the findDocker function is another beast that needs refinement.

Today I started running the autodock function on Misty 2. I commented out the loop() function and inserted the line _ = dock(hasGuideRail = false); in order to test the dock function. The code hangs up after findDocker calls letDockerTrackerStabilize where it gets stuck in a while loop; uncommenting the misty.Debug results in 0.0 for the xOffset, zOffset, and yRotation values which were reset by the resetDockerParameters function. What to do?

function letDockerTrackerStabilize() {

_ = resetDockerParameters();
misty.Debug("Waiting for tracker values to stabilize");

while (!misty.Get("dockerTrackerIsConfident")) {
    misty.Debug("X: " + misty.Get("xOffset").toFixed(2).toString() + " Z:" + misty.Get("zOffset").toFixed(2).toString() + " Yrot:" + misty.Get("yRotation").toFixed(2).toString() + " Look@:" + misty.Get("lookAtChargerOffset").toFixed(2).toString() + " " + misty.Get("lastDockerUpdate"));
return 0;


Update of the sensory services software seem to solve the problem but reliability of the sensor data is not good.