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,