Decision making : how many tasks , response times?

Kernel
21

Thank you for the helpful tips on RTOS systems.

Avoiding fixed-time polling and using an event-driven approach.

Blocking mechanisms to save CPU and boost system responsiveness.

Using queues for efficient data exchange.

Prioritizing tasks based on importance and deadlines.

22

or even more efficient FreeRTOS streambuffers as next level optimization. But the principle is the same.

23

I am very thankful for your valuable assistance in helping me understand essential concepts like , resource sharing, and scheduling.

I plan to apply these concepts to a remote-controlled car project to enhance my understanding. However, I want to clarify that I’m not delving into deep technical specifics regarding like motor types, remote transmitter-receiver circuits, network protocols, or communication interfaces etc . I’ll keep it simple, assuming basic components like motor-controlled wheels, data transmission to a remote server.

Here’s my approach: I’ll hypothetically assume conditions, create a list of project operations, and assign them priorities. I’d appreciate your guidance to validate whether my approach is correct. The same will apply to resource sharing, particularly using mutex, semaphores, and queues. Your expertise will be invaluable in this learning process

I know project is complex, and I believe it will provide insights into aspects of RTOS project design that I’m still learning. If you’re ready to continue helping, I’m committed to giving my 100% effort.

Any feedback is much appreciated

24

One quick comment, the “Remote Control Car” task is perhaps too simple in the simplest implementation, since they can be built without any computer at all, but can be just a simple radio receiver that picks up two analog signals that get applied to the drive motor voltage, and the steering angle.

The parts that might actually need computer processing, are the things that you begin by abstracting out, the Radio Receiver, and the low level motor control loop.

The first step of any such project is to define the actual system requirements (first without thinking about how you might implement them)

1 Like
25

I’ve put together a set of hypothetical requirements for a remote-controlled toy car:

  1. Video Data Transmission (High Priority):

    • The car collects and processes data from the front and rear video cameras for real-time position tracking and obstacle avoidance. The collected video data is transmitted to a remote control unit for real-time monitoring and control.
    • Priority: High priority due to its direct impact on real-time user experience and control.
    • Deadline: Video data transmission should have minimal latency to ensure real-time control. It is not acceptable if there is a delay of more than 100 milliseconds, as this would impact the user’s ability to control the car effectively.

  2. Receive Command and Control Car (High Priority):

    • The car collects input from the remote control, translates it into motor control actions, and ensures the car can move left, right, forward, and backward based on the commands received. It also responds accurately to the commands received from the remote control. This task also includes controlling front and rear LED lights for improved visibility and activating a horn for audio alerts.
    • Priority: High priority as it directly relates to user control and functionality.
    • Deadline for Received Command Acceptance and Action: The car must accept received commands from the remote control unit within a maximum time of 50 milliseconds from the moment they are received. Furthermore, the car should respond to accepted commands with actions (movement, lighting control, horn activation) within a maximum time of 100 milliseconds. Quick response times are crucial to ensure a seamless and responsive user experience. If a command is not received within 50 milliseconds or is corrupted, it should not be accepted for action.

  3. Battery Monitoring (Medium Priority):

    • The car continuously monitors the battery to prevent abrupt shutdowns.
    • Priority: Medium priority as it ensures reliable operation but may not directly impact user experience.
    • Deadline: The monitoring of the battery should be continuous and in real-time, ensuring that battery status is checked at intervals no longer than every 5 minutes. Delays in battery monitoring beyond 5 minutes are not acceptable.

  4. Server Transmission (Lower Priority):

    • The car sends data on distance, time, temperature, and humidity to a remote server for analysis and storage.
    • Priority: Lower priority as it’s important for data analysis but not as time-sensitive as real-time control and monitoring.
    • Deadline: Data should be transmitted to the server within a reasonable time frame, aiming for an average delay of no more than 2 minutes for the data to reach the server for analysis. This timeframe ensures that data is available for analysis without significant delays.

I would add new features but for now I would consider these only

Any feedback suggestions much appreciated

26

@richard-damon

Are these the requirements you wanted me to define first?

27

Hi @Mtech,
It’s been a while since last post. Do you get the answer you want from this post?
Or do you need more help on it?

Thanks.

28

@ActoryOu

I was looking more help because I invested a significant amount of time creating requirements based on members’ advice.

29

Hi @Mtech,
You’ve well defined requirements with @richard-damon help here.

I believe you can try to design a high level architecture. For example, to define main job of each task, how they communicate, and the interface you’re going to use. Then continue to implement it and enjoy the FreeRTOS world!

Remember the suggestion provided in this post. Feel free to post your question in this forum to let people help! I’ll suggest to create new post instead of keeping discussion here because this post is going too long to track.

Anyway, welcome to FreeRTOS!