Autonomous vehicle development in Malaysia: what we have learned since 2016

By Muhammad Haziq Faris, Co-founderTopic Autonomy and mobilityPublished Read 8 min
Contents
Inside CRETA on the PLUS Highway in 2016: a laptop on the dashboard and a steering motor fitted to the wheel
Inside CRETA, a retrofitted Proton Waja, on the PLUS Highway in 2016. REKA archive photograph.

Most writing about self-driving cars starts with the vehicle. Ours starts with a question REKA asked itself in 2016: can you engineer reliable autonomy with what you actually have, in conditions you actually face, on a budget that makes commercial sense?

This is our account of what that question has taught us over a decade of autonomous vehicle work in Malaysia, and of what we now ask any organisation that wants to start. It is written for engineers, operators and decision-makers. It is specific about what we did, and careful about what it cannot show.

Where REKA's autonomy work started

In September 2016 REKA began building its own self-driving technology: a retrofit kit for an ordinary car, a Proton Waja, which the team called CRETA. The first car saw the road through a single webcam. It was not built for drive-by-wire, so motors, servos and REKA’s own electronics, including RIG (REKA Innovation Gear), one of REKA’s own boards, turned the wheel and worked the pedals. By the end of that year it drove from Melaka to Kuala Lumpur on the PLUS Highway with no one in the driver’s seat: Malaysia’s first self-driving car, and the first in Southeast Asia on public highways. The full record, with photographs and the press coverage of the time, is in the CRETA self-driving car case study.

Two more generations followed. MK II (mid-2017), a Proton Inspira courtesy of MIDA, carried one puck LiDAR and two webcams. MK III was two Proton Perdanas, a maroon one lent by NanoMalaysia Berhad and a white one from MARA, each with at least two puck LiDARs, two side radars and three cameras. None of the cars was drive-by-wire capable; on MK III, REKA reverse engineered the braking and acceleration with digital signal processing and its own algorithm, and the steering stayed mechanical. Partners made the work possible: IMBiG with metal fabrication, motors and actuation; Kolej MARA Masjid Tanah with workshop space, tools and expertise from its automotive department; Elmlab with GPU computing and its electronics maker lab in Beranang.

In 2017 the work went public. Members of the public rode in the car at the Malaysia Autoshow 2017 with MARii, and REKA showed it at NICE Expo 2017, where MARA and MARA Corp secured the space for the showcase.

Define the operating domain before the vehicle

SAE J3016, the standard taxonomy for driving automation, uses the term operational design domain (ODD) for the conditions an automation feature is designed to work in: road types, speeds, time of day, weather, traffic and geography among them. The same standard defines six levels, from Level 0 (no driving automation) to Level 5 (full driving automation). The levels describe who performs the driving task and who deals with a failure, not how clever the software is.

  • Level 2: the system steers and controls speed, but the driver supervises at all times.
  • Level 3: the system drives within its ODD, but a person must be ready to take over when asked.
  • Level 4: the system drives within its ODD and must reach a safe condition on its own if something goes wrong.
  • Level 5: the system performs the whole driving task, and its own fallback, with no ODD limit.

That is why we stopped asking “which level?” and started asking “which domain?” A fenced yard, a port terminal, a plantation road or a fixed shuttle route has fewer kinds of road users, lower speeds and predictable layouts. A system can be engineered, tested and argued safe inside a domain like that long before it could cope with an unrestricted public road. The Autonomous Lab shows how quickly the difficulty grows as the domain widens.

Sensor fusion is an integration problem first

Each sensor sees the world differently. Cameras capture colour, texture, lane markings and signs, but struggle with glare, darkness and heavy rain. Radar measures range and closing speed directly and copes with poor weather, but with coarse angular resolution. Lidar returns a precise three-dimensional point cloud, at a higher cost and with its own weaknesses in rain and on dark or shiny surfaces. Satellite positioning (GNSS) degrades under bridges, in tunnels and between tall buildings, so it is combined with an inertial measurement unit (IMU) and wheel odometry.

Sensor fusion combines these inputs into one consistent picture of what is around the vehicle and where the vehicle is. Most of the work is not the fusion algorithm. It is time synchronisation, so that a camera frame and a lidar sweep describe the same instant; calibration, so that every sensor agrees where it sits on the vehicle; and monitoring, so that the system notices when one input degrades and leans on the others. Going from one webcam on MK I to LiDAR, radar and cameras on MK III meant owning that work end to end.

Localisation is the other half. On our current stack the vehicle estimates its position by matching live lidar scans against a prepared point-cloud map (normal distributions transform, or NDT, scan matching), fused with GNSS and inertial data. A good map makes localisation reliable where GPS alone is weak. It also turns the map into an asset that has to be maintained: when the road changes, the map must change too.

Build on an open, inspectable stack

REKA has built on Autoware since 2021 and joined the Autoware Foundation as a member in 2024. Autoware is open-source autonomous driving software built on ROS 2 (Robot Operating System 2). It is organised into modules for sensing, perception, localisation, planning and control, with an interface to the vehicle's drive-by-wire system.

An open stack matters to us for three reasons. The first is auditability: when a regulator, an insurer or an operator asks why the vehicle did something, every layer can be inspected and its decisions logged. The second is replaceability: a team can change a perception model or a planner without rebuilding everything else. The third is shared effort: what is learned on one country's roads, weather and traffic can flow back into a common codebase instead of being rebuilt by every company.

An open stack is not a safety case on its own. Functional safety (ISO 26262) and the safety of the intended functionality (ISO 21448, often called SOTIF) still have to be addressed for the specific vehicle, sensors and domain, and the evidence built through simulation, hardware-in-the-loop testing, closed-course runs and supervised operation on the road.

Design the human in the loop on purpose

No bounded system meets only the situations it was designed for. What matters is what happens at the edge of the domain. We design for three states: inside the domain, the machine drives and logs every decision; at the boundary, control passes to a person, increasingly a remote operator over a teleoperation link; outside the domain, the machine brings itself to a controlled stop.

Teleoperation brings engineering questions of its own: network latency and coverage along the route, what the operator can see, how quickly they can take control and what the vehicle does if the link drops. Connectivity and teleoperation were the subject of REKA's 2022 memorandum of understanding with Elmlab to co-develop autonomous vehicle technology.

Sensors mounted on the roof of REKA's autonomous test bed at the Malaysia Autoshow 2023
Roof-mounted sensors on REKA's autonomous test bed at the Malaysia Autoshow 2023. REKA archive photograph.

In 2023 REKA showed an autonomous test bed with MARii at the Malaysia Autoshow, after testing it on a dedicated route in Cyberjaya. Our 2023 article on the Autoshow test bed has the details as we published them at the time.

The road is not the only roadblock

The car worked. Taking it to market was a different problem. From 2018 REKA put its main effort into software automation while the autonomy work carried on, because the roadblocks across the region were commercialisation, regulation, road and network infrastructure, market adoption and culture.

Those roadblocks have not gone away, and an autonomy programme that ignores them is a demonstration rather than a deployment. Regulators need evidence before they authorise testing. Operators need a business case that survives the cost of safety operators or remote supervision. The public needs to understand what the vehicle will and will not do. We look at the regulatory side in a companion article, autonomous vehicle regulation in ASEAN.

What to ask before starting an autonomy project

A useful autonomy programme begins with an operational problem, not a vehicle demonstration. These are the questions we work through first:

  • What task should be automated, and what does it cost today? A repetitive, well-bounded movement of goods or people is a better first target than general driving.
  • What is the operational design domain? Write it down: routes or areas, speeds, hours, weather, other road users, and what counts as leaving the domain.
  • What already exists? Maps, network coverage, fixed infrastructure, vehicles that support drive-by-wire, and data from current operations.
  • What supervision is acceptable? A safety operator on board, a remote operator watching several vehicles, or neither inside a fenced site.
  • How will safety and success be measured? Agree the evidence before the first test: scenario coverage in simulation, closed-course results, supervised hours on the road, and every intervention with its cause.
  • Who has to approve it? Site owners, insurers and, on public roads, the relevant authorities.

If the answers point to a bounded domain with a clear operational payoff, the next step is a feasibility study, not a vehicle purchase. If they do not, that is a useful answer too.

Further reading

References

Questions people ask

What is an operational design domain (ODD)?

SAE J3016, the standard taxonomy for driving automation, uses the term for the conditions an automation feature is designed to work in, such as road types, speeds, time of day and weather. Defining it first keeps an autonomy project bounded.

Why build on an open stack such as Autoware?

An open, inspectable stack lets a team see and test what the software does. REKA has built on Autoware since 2021 and joined the Autoware Foundation as a member in 2024.

Where should an autonomy project start?

With an operational problem, not a vehicle demonstration.

← All articles

Keep reading