This site is best viewed in a modern browser with JavaScript enabled.

Pacer Development Thread

ConstantinColac

We believe in modular technologies in terms of both software and hardware.

Pacer is a development platform for lightweight electric vehicles.

The new Hyperboard will be the first lightweight electric vehicle running Pacer.

Pacer covers 3 areas of development:

Modular Hardware Components

A set of hardware modules that are essential for creating a lightweight electric vehicle.
In its simplest form it will include:

Battery and BMS
Motor Controllers
Brain (MCU)
Motors
Controller

@SunePedersen is pushing the development of a modular component that will house all the electronics.
Check it out here: http://forum.faradaymotion.com/d/9-modular-rails-and-electronics-system

On Board SDK

A C++ set of libraries that makeup the firmware of the lightweight electric skateboard.

I am working on it here: http://forum.faradaymotion.com/d/4-refactoring-the-faraday-motion-core-software

Mobile SDK

We are still to develop this component. With it we want to enable developers to easily create apps for lightweight electric vehicles running on Pacer.

Being a web developer I am prone to use the React Native for developing it. But we are open for discussions on wether it should be native.

We have not openly announced Pacer yet. We would like to hear what you guys think first.

ConstantinColac

Hey all!

I will intrigue you a bit.. We have the first stable version of the Pacer software running

ConstantinColac

Yet another update. It seems we are getting closer to a stable version.

We had someone help us out with some visuals.

Here's Pacer in images. Let us know what you think

image faraday-pitch-deck-02.jpeg

image faraday-pitch-deck-01.jpeg

ConstantinColac

I will just leave this here...

https://github.com/faraday-motion/pacer

Documentation coming up!

ThierryGTLTS

Waiting eagerly your documention, because I wanna develop a very light and silent MTB using a Tmotor U8.
This motor seems hard to drive, and need high speed ESC, and most can't cope with high erpm.
That's why I've choosen the VESC, 60000 erpm possible if I've well seen.
But I need to implement a throttle or perhaps a new kind of pedelec that doesn't cut assistance abruptly!
So I will need some help in a near future :-)
Thierry

ConstantinColac

ThierryGTLTS This sounds really cool!

Actually in the current setup, Pacer supports a very simple assistive control based on the inputs of an accelerometer.

I've spent one weekend to implement it but I did not have time to dig into details.

For now the use case is like this:

You start pedaling. The accelerometer picks up the acceleration rate and tries to assist you by pushing power to the motor. As soon as you brake, the accelerometer detects the deceleration and tells Pacer to disengage the motor.

I think it's a bad ass method of controlling, but much more work and testing needs to be done in the way we process the inputs from the accelerometer. For now we only sample the x-axis. There's potential in getting the heading and other samples to get a more sophisticated algorithm. But time.. god damn time..

Alternatively Pacer supports a wired analog joystick or a radio Nunchuck that we made (using the NRF24 module).

I am planning to write some setup UI for pacer so that people can download, flash the nodemcu and setup Pacer (e.g. control type, max amps etc) from a web interface

Maybe I will even get time to film some video tuts

Super excited about your project! Would really appreciate if you created a thread for the world's first project of a bike powered by Pacer in the Pacer Category.

Cheers!

TL;DR

You can use accelerometer input instead of pedal assist or use a wired/wireless analog joystick.

ThierryGTLTS

ConstantinColac

Good idea the accelerometer to detect start of the bike.
Will inquire much in that direction.
Thanks for your quick reply.

ConstantinColac

Update

Today I finally got the web app configurator to work via websockets.

No more time will be waisted on uploading the new configurations to the ESP8266 via the USB cable. For those who don't know it takes ages for it to upload..

I will upload the code and a demo video today.

Cheers!

EDIT1 Pushed the code to GitHub
EDIT2 Video Demo and GituHub Link to Web App

ConstantinColac

New small update.

Now we will support configuration of modules. A module is basically a functionality block.

The cool part is that we can do this at runtime (well.. almost, rightnow we have to restart the ESP8266 once we change the cofnig).

For now I've pushed the code that will let users to enable/disable the nRF24 connection. We use the nRF24 for our custom nunchuck that we did not release yet.

ConstantinColac

Good news everyone!

Pacer is getting some organic free publicity . I think it's the result of me posting the GitHub repo on reddit. It's good but still premature I think . Link

But I actually need your help with something.

I have a riddle for you guys!

Now pacer supports wired controllers (e.g. a wired joystick, sensor pads) and wireless controllers (e.g. phone, wireless joystick).

Initially I thought that the pacer vehicle should only have on active controller at a given time. Now I am thinking that maybe I would like my skateboard to have sensor pads and wired joystic connected and active at the same time.

Question: How would you like to enable/disable or switch between these controllers?

There are a couple of ways that I imagine:

Give priorities to controllers. The highest in priority cancels out the lower in priority.
On startup of the vehicle the first controller that sends commands is activated. Then we can switch by getting some user input (e.g. tapping on the sensor pads or clicking on a button on the nunchuck)
Have both of them active with the same priority Basically the last one giving instruction is always listened to.
Your idea comes here

Just to make sure that you guys will see this post I will mention a few of you
(If you find this annoying, let me know and I'll stop doing that ).

I would really appreciate your opinions on this one guys

@TobyBurkill @Robin @SunePedersen @tclarke @Krocan @Dazkeirle @Albert @Tibor @johnvanesch @ThierryGTLTS

P.S. Wondering how many of you are online and reading Faraday Motion posts on a Friday night

Albert

ConstantinColac
Hi Constantin!
In my opinion, the best option is the option two, because is the simple one for the user, no config needed, but with a change:
Several controllers may be supported and the first one detected will be activated, linked. But after that moment, system won't allow a new controller! As other commented in the post, for security, and additionally, in my opinion, it's not a requested user case.
Let me put an example, if user is running with a controllers, is strange he would like to change it during a ride... And if he wants to do so, he will be able to do it, but securely, because he will be forced to stop and restart the system with the new controller. (That's the aproach I implemmented in the spinner to suport my Nunchuck controller, mobile or nunchuck, the first transmitting is the winner )

I hope my opinion helps!

TobyBurkill

Haha I got the email notification but will read properly in the morning and let you know my thoughts

ThierryGTLTS

Security is the most important thing for me and for my collegues.

Thay's why a wired controller should always have max priority to protect the user from external "corruption".
In those days of "connected objects", we see everyday that a lot of objects are hacked and completely out of control of the user!

For a vehicle it's not possible to accept such possibilities.

So a wired controller should always be usable with the first priority.
That's my point of view, and I hope it's also yours.

Thierry

Robin

As Thierry said. Security is the most important thing. With that said. Having multiple controllers activ at the same time sound like an accident is most likely to happen.
I would like to see an app where you can chose what controller is active with a simple click.
Also would be awesome having different performance modes a button away. But that's another topic.

ConstantinColac

First of all, big thanks to you guys for participating in the discussion related to the controller management.
My thoughts on your suggestions will follow in another post.

Let's get to the juicy stuff.

Update No. "I don't remember which one "

I've been a bit slow as I got a really bad flue and could not do anything over the weekend.

Today however we've hit another big milestone: We are logging stuff! (and we do it properly now )

I have updated the Log class and now we support the following features:

1.The Logger has targets now

For now we plan to support 3 logging targets: "Serial Monitor", "WebSockets" and "SPIFFS Files".
The thing I consider really cool is that we can log to multiple targets at the same time. For now I have limited the concurrent target count to 3.

Note: I did not write the implementation for SPIFFS as there's no real application for it yet.
We have limited flash space and need to choose wisely what king of things we want to log there.

2.The Log has Levels of Severity now.

Now when logging we are able to flag/categorize logs according to the following specs:
DEBUG
INFO
NOTICE
WARNING
ERR

A user/developer can choose what log levels should be printed/sent/written to all the targets.

3.Add/Remove Log Targets via Websockets & Set the Log Levels

In one of the previous updates I have wrote a simple web app that can send commands to PACER.
With that in place we can now interact with the Log class.

Enable/Disable Logger
Add/Remove a Log Target
Change the level of the logger.

This is pretty much it. I expect this to be very helpful for developers/users when trying to debug issues.

Thanks for reading! Feel free to ask questions or suggest things

If you feel like contributing just ping me

P.S. I've setup a small project board on github so that you guys can see what I am working on

https://github.com/faraday-motion/pacer/projects

Cheers!

ConstantinColac

I wish I had the time to do a proper update..

Here are some cool things that I've implemented.

Faraday Motion Vehicle Setup Wizard
Interacting with Pacer through commands.
Configure what types of controllers are authorized for your Faraday Motion Vehicle (some day we should have a proper thread about how to handle these most securely)
Have the base for default/registered/authorized controllers (each having private IDs).
Refactored the config json object and some other minor things here and there.

Things that stop us from proper release.

Benchmark test for reliability
These tasks
Documenting all of pacer )

We're getting closer guys.

As always if you feel like contributing please feel free to dig in and ask questions

Cheers!

Robin

I don't understand this yet to 100%.
But will pacer replace bldc tool?

ConstantinColac

Robin not necessarily. The objective with Pacer is to make it into a universal Vehicle Control Unit that support different control, communication and sensor interfaces.

The VESC is a briliant esc but pacer will support different kinds of motor controllers.

Being open source we have access to the vesc via the BLDC tool interface. We will use it to configure and interact with the vesc programatically but have no objective to replace it .

Did not get to push the code yet but this morning I made the web app be served from the esp8266.

This enablels us to make it really quick to get started with Pacer

ConstantinColac

Hey folks!

So now I am hitting a bit of a dilemma.

Problem Context

Currently Pacer not only handles controller inputs but also has connectivity services such as Radio, WiFi, Websockets and a Webserver. These are used for configuration, connectivity of new controllers, logging etc.

The Goal

The goal is that we want to disable all these services while the vehicle is in motion (as in it is physically moving).

Question:

How can we detect that the vehicle is in motion, without relying on the RPMs of the motor or accelerometer?

Initial fix that will be implemented

If the current active controller is sending signals that convert to neutral power (no acceleratio AND no braking) for at least 10 seconds we enable the connectivity services.

Problems with the initial fix

When you are cruising down the road without braking or accelerating for more the 10 seconds, Pacer will think that the vehicle is not in motion and will run the connectivity services.
When you as a developer want to log the activity of Pacer while in motion you will not be getting the data as the services will be disabled.

What do you guys think?

EDIT

After some more investigation and prioritisation I decided that we will keep the services running and will be disabling them based on a different setting. I did implement another feature though.

Restrict unsetting the active controller unless we're receiving neutral signal for at least 15 seconds

Robin

On your question. Sensors is the only thing I can think about for the moment.