Mobile robots for charging electric cars: what to verify before deployment

In a conventional charging system, the vehicle is parked beside a fixed charging point and a person connects the cable. A mobile robot partly reverses that arrangement: the vehicle stays parked while an autonomous or guided unit brings the charging equipment to it. The idea could be useful where installing a socket in every parking space is difficult, but it does not remove the need for an electricity supply, nor does it prove by itself that more charging capacity is available.

The proposal should be distinguished from wireless charging. In wireless charging, energy is transferred without a conventional connecting cable between the vehicle and the equipment, using compatible components installed in both the vehicle and the infrastructure. A robot that transports a cable still relies on a physical connection: it changes who brings the charger and where it is located, not the principle by which energy is transferred.

The practical question is not simply whether a robot can travel to a car. Operators need to know how much space it occupies, how many vehicles it can serve, how long each service takes, how much power it delivers and how easily it can be recovered after a fault. Its value depends on the whole system: the robot, charger, electricity supply, management software, vehicles and parking-facility rules.

The information provided about ZiGGY comes from EV Safe Charge press releases collected in the company’s own news section. They describe it as a mobile charging robot and announce that the company was selected for an accelerator programme in November 2023. This supports the claim that the company announced development and its participation in the programme; it does not establish commercial deployment, the number of units in service or measured results at a parking facility.

A funding announcement, image, demonstration video or selection for an accelerator is a different kind of evidence from real-world operation. To support a claim that the system works at scale, data from the operator or manufacturer would need to identify the location, dates, vehicle types, completed sessions and incidents. An independent assessment using an explicit method would also be relevant. The absence of those data limits what can be concluded: it does not show that the solution is unworkable, but it also does not justify presenting it as available or proven under ordinary conditions.

The documentation assembled here does not provide a complete technical dossier for ZiGGY or independent validation of its navigation, connection and safety functions. The useful approach is therefore to set out verifiable criteria, rather than make claims about the robot’s performance. The comparison must be balanced: a demonstration can show that a task was completed under specific conditions, but does not necessarily show that the product is safe, interoperable or economically worthwhile in other settings.

Safety must cover the entire sequence, not just whether the robot avoids a collision while moving. Documentation should explain how it detects pedestrians, wheelchair users, carts, vehicles and low obstacles; what it does if someone enters its path; and whether it can stop in a controlled way if it loses its position, communication or power. A navigation video without incidents is no substitute for a risk assessment or test records.

The second critical stage is the electrical connection. The dossier should describe how connector positioning is controlled, how the cable is prevented from snagging or being pulled tight, and what conditions prevent it from being energised if the connection is incorrect. It should also explain how charging is interrupted if an anomaly occurs and who can release the connector if the robot becomes immobilised. Safe stopping must cover the complete system, including the charger and vehicle, not just the drive motors.

Tests should specify scenarios and results, including deliberately induced faults. For example, someone might cross in front; an object might obstruct the route; a parking space might become blocked; or the robot might lose its connection to the management system. It is not enough to list a safety feature: readers need to know which risk it addresses, how it was tested and what result it produced. The documentation available here does not allow us to attribute a specific certification or incident rate to ZiGGY.

The fact that a robot can physically reach a vehicle does not guarantee that it can charge it. The manufacturer or operator would need to publish which connectors it supports, what power it supplies, which vehicle types have been verified and whether connection depends on adapters or a specific configuration. For each relevant combination, it is useful to distinguish physical compatibility, communication between charger and vehicle, and authorisation of the charging session. A connector list is not proof of interoperability across all makes and models.

Integration with the parking facility also matters. The system needs to know which spaces are occupied, which vehicles have requested service and how to assign the robot when several requests arrive. If an app or management platform is used, the documentation should clarify who administers the data, what happens if the network goes down, and how payments, cancellations and errors are handled. Without that information, it is impossible to judge whether the robot simplifies operations or adds another point of failure.

Accessibility requires assessment of manoeuvring space and interaction with people who do not use an app. A service may work technically and still be impractical if it blocks aisles, depends on a particular space or leaves the cable across a pedestrian route. Usage rules and assistance instructions should be available before installation. At present, the sources provided do not confirm a public compatibility matrix or ZiGGY’s operating conditions.

A fair comparison should assess the robot against the alternative the site would actually use: fixed chargers, expansion of the electrical installation, parking-space management or, where technically applicable, another charging method. The metric cannot be reduced to the robot’s speed. It should also include the time from request to charging start, completed sessions, interruptions and recovery time when a fault occurs.

At a minimum, each data point should include its context and unit of measurement: duration per session, energy delivered, effective power, percentage of tasks completed, trips without service, human interventions and availability over the observation period. To compare with fixed chargers, measurements should come from the same parking facility, or differences in demand, contracted power, number of spaces and operating hours should be explained. Without denominators and comparable conditions, an isolated figure can mislead.

An economic assessment must include more than the robot’s price. It needs to account for installation and connection, maintenance, software, support staff, insurance and possible changes to the site, as well as energy costs and the effect on the number of spaces served. Savings or profitability cannot be calculated from the evidence received: there are no verifiable tariffs, costs or operating results to support a responsible estimate.

The most useful information for judging how mature this category is would come from the manufacturer and site operator: a technical data sheet, operating limits, a vehicle-and-connector matrix, risk assessment, emergency instructions and session logs. If the product is offered commercially, its availability, support and service terms in the relevant market should also be verifiable. Safety or certification claims should link to identifiable documents rather than remain marketing adjectives.

Independent assessment should specify who conducted it, which configuration was tested, for how long and what results were observed. A technical study may examine a particular function without validating the complete system in a real parking facility. Likewise, a news story that repeats a company announcement is not independent confirmation of performance. The origin of each data point is part of the evidence, especially when safety and availability are at issue.

Based on the verifiable material assembled, the prudent conclusion is limited: a company has proposed a mobile charging robot, and the company has reported development progress, but there is not enough evidence to say that ZiGGY operates as a proven commercial service or to quantify its advantages. Before recommending it to a parking facility, traceable evidence should be requested for safety, compatibility, integration and results under real-world conditions. This lack of information is a limitation of the analysis, not proof that the system does not exist or cannot work.