Dan
Premium
- 15,396
- United States
That design looks incredible! I can't wait for the series to start.
Endurance racing was to test the reliability of cars. Formula 1 was to innovate as much as possible. Racing was always about trying to make the car more efficient than everyone else (and then regulations came and balance is performance etc but that's a different story).
Formula E is about trying to innovate in batteries and electricity which is definitely our next power source especially after "dieselgate". This is about trying to innovate autonomous vehicles and considering there's already autonomous vehicles being tested on the road, it's about time we see who can make theirs the fastest and most efficient. It's the future. Time moves on.
The first semi-autonomous cars are out on the road already so I guess it's human nature to race them too.The first race ever happened when the 2nd car was built, it's just human nature.
Hi all, I am one of the engineers from the SIT autonomous team (its our car that crashed in the video). I want to address the crash and clarify a bit what happened.
The actual failure happened way before the moment of the crash, on the intialization lap. The initialization lap is there to take the car from boxes to the start/finish line and the car is driven by a human driver during the lap. The intialization lap is a standard procedure by roborace.
So during this intialization lap something happened which apparently caused the steering control signal to go to NaN and subsequently the steering locked to the maximum value to the right. When our car was given a permission to drive, the acceleration command went as normal but the steering was locked to the right. We are looking at the log values and can see that our controller was trying to steer the car back to the left, but the car did not execute the steering command due to a steering lock. The desired trajectory was also good, the car definitely did not plan to go into the wall.
We are not yet sure what was the actual cause, but it seems that its an extremely rare event during which there was a short spike in the inputs to the controller. Normally, this spike would have been filtered out, but apparently there exists a configuration under which this spike is allowed to propagate through the system and we were "very lucky" to collect it during the competitive run. We had testing days before and had never experienced this.
We are putting a lot of effort atm into investigation and hopefully will be able to fix it before the second round tomorrow. So if you have any questions, feel free to ask them here in the thread, I will try to address them when I'm available.
UPDATE: spelling and added more info
UPDATE 2: A lot of people are asking about failure modes checking, so I want to address that additionally. We do have a failure modes system in place, and the intended scenario is to put the car into emergency braking once one of the system becomes nonfunctional or stops producing any output. This also shows as a big red NO-GO on the telemetry screens so that Roborace operators could also take action.
But what happened in the video is that the system somehow managed to produce a NaN (not a number) value and all verification logic was designed to work only with numbers. Due to this and partially due to how these NaNs are handled by MATLAB, the verification layer just let the value through and it locked the steering.
What additionally caused the confusion is that the output values are transferred via control area network (CAN) to the actuators, but there is no definition for a NaN in the CAN specs, so it just transformed it into a normal number, albeit a very large one.
UPDATE 3: So we spent a lot of time investigating and making fixes and hopefully will be able to mitigate this issue if it occurs again. The round 2 should start soon and hopefully this time we will avoid driving into the wall Head over to roborace twitch if you want to see the action live. Unfortunately our car had to be sent to the factory for repairs, so we will run on a default Roborace car today.
UPDATE 4: We did it! Round 2 went smoothly and our car drove straight without any significant problems! We went straight to take the 2nd place Here's a link to our run if anyone's interested
I absolutely agree with you from the analysis/verification process standpoint.
We did implement checks for what seemed to us as more common failure scenarios, but the devil here was that this one first appeared during the run and we did not cover it at the analytical analysis stage. In other words, we did not expect a NaN value to appear there and put too much confidence in our decision.
We are a team of 4 engineers, our backgrounds are in computer science, software engineering, control engineering and machine learning.
Ironically, it did show up on telemetry monitors, but it showed up along with 1.5k other telemetry values. Usually the operators would look only at the indicator flags that there were no failures, and in our case all indicator flags were green